Isolate a Hacked cPanel Account Without Disrupting Other Sites

Running a shared‑hosting server with cPanel means you host many customers on a single machine. When one account is compromised, the priority is to stop the attacker while keeping the other sites online. This guide provides a clear, step‑by‑step response that isolates a hacked cPanel account without disrupting the rest of the server.

1. Initial Detection and Triage

Gather as much information as possible before making changes. A quick triage helps you gauge the urgency of the isolation and the resources you’ll need.

• Identify the compromised account: Look for unusual spikes in CPU, memory, or outbound traffic in WHM → Server Status → CPU/Memory Usage. Review the account’s Raw Access Logs for suspicious requests (e.g., POST /wp‑login.php from unknown IPs).
• Determine the attack vector: Common signs include a new cron job, a rogue PHP file in public_html, or a modified .htaccess. Use find to list recent changes:

  find /home/username/public_html -type f -mtime -2 -ls

• Check for lateral movement: Scan other accounts for similar files or processes. A quick ps aux | grep username can reveal processes running under the compromised UID.

Document everything—timestamps, file paths, IP addresses, and log excerpts. This record is essential for post‑incident analysis and client communication.

2. Immediate Containment – Suspend the Account

cPanel’s built‑in “Suspend Account” feature stops all HTTP/HTTPS requests for the user while leaving the filesystem untouched. This is the fastest way to cut off the attacker’s web access.

1. Log in to WHM as root.
2. Navigate to Account Functions → Suspend/Unsuspend an Account.
3. Select the compromised account and click Suspend. Add a brief note (e.g., “Compromised – under investigation”).

Suspending the account does two things:

• Returns a 403 error for any request to that domain, preventing further web‑based exploitation.
• Disables the user’s cPanel services (FTP, email, SSH) without terminating existing processes, giving you time to investigate safely.

3. Isolate System Resources – Use Linux Security Modules

Rogue processes may still be running under the compromised UID. Limiting their resource usage prevents impact on other accounts.

Debian/Ubuntu (apt) – Using systemd Slice

# Create a slice for the user
cat > /etc/systemd/system/cpanel-username.slice <<EOF
[Slice]
CPUQuota=20%
MemoryMax=500M
EOF

# Reload systemd to apply the new unit
systemctl daemon-reload

# Apply the limits to the running processes of the user
systemctl set-property --runtime --user cpanel-username.slice CPUQuota=20%
systemctl set-property --runtime --user cpanel-username.slice MemoryMax=500M

This limits CPU and memory for any process belonging to username, ensuring it cannot starve resources from other accounts.

AlmaLinux / Rocky / RHEL (dnf) – Using cgroups with systemd

# Create a systemd slice
cat > /etc/systemd/system/cpanel-username.slice <<EOF
[Slice]
CPUQuota=20%
MemoryMax=500M
EOF

# Reload systemd configuration
systemctl daemon-reload

# Assign the user’s processes to the slice
systemctl set-property --runtime --user cpanel-username.slice CPUQuota=20%
systemctl set-property --runtime --user cpanel-username.slice MemoryMax=500M

Both methods achieve the same goal: they cap resource usage without killing the processes, giving you a window to examine them safely.

4. Secure the Filesystem – Remove Malicious Files and Reset Permissions

With the account isolated, you can clean its files without risking cross‑contamination.

1. List recently modified files (last 48 hours is a good starting point):

   find /home/username/public_html -type f -mtime -2 -ls

2. Search for known web‑shell signatures (e.g., eval(base64_decode(...))):

   grep -RIl 'base64_decode' /home/username/public_html

3. Quarantine suspicious files. Move them to a safe directory for later forensic analysis:

   mkdir -p /root/quarantine/username
   mv /home/username/public_html/suspicious.php /root/quarantine/username/

4. Reset ownership and permissions to cPanel defaults:

   # Set correct ownership
   chown -R username:username /home/username/public_html
   
   # Directories → 750, files → 640
   find /home/username/public_html -type d -exec chmod 750 {} \;
   find /home/username/public_html -type f -exec chmod 640 {} \;
   

cPanel’s File Manager can also be used for visual inspection, but command‑line checks are faster for large sites.

5. Review and Harden Authentication – Passwords, SSH Keys, and API Tokens

Compromise often originates from stolen credentials. Reset everything linked to the account.

• cPanel password: WHM → Account Functions → Password Modification. Generate a strong password (≥16 characters, mixed case, numbers, symbols) and force a change at next login.
• FTP accounts: Delete all existing FTP users for the compromised account and recreate only the necessary ones.
• SSH access: If the user had SSH keys, remove ~/.ssh/authorized_keys and re‑add only verified keys. Consider disabling SSH for the user if it isn’t required.
• API tokens: Revoke any cPanel API tokens created by the user (WHM → Manage API Tokens) and generate new ones if needed.

6. Verify Neighboring Accounts and Restore Normal Operation

After containment and cleanup, confirm that other sites remain healthy.

1. Run a quick health check on a few random accounts:

   for user in user1 user2 user3; do
     echo "Checking $user"
     du -sh /home/$user/public_html
   done

2. Monitor server metrics (CPU, memory, network) for several hours using WHM → Server Status → Apache Status or the top/htop commands.
3. Unsuspend the cleaned account once you’re confident the threat is removed. In WHM, return to Account Functions → Suspend/Unsuspend an Account and click Unsuspend. Add a note summarising the remediation steps.
4. Communicate with the client: Provide a concise summary of the incident, actions taken, and any follow‑up steps (e.g., updating CMS plugins, enabling two‑factor authentication).

7. Post‑Incident Review and Future Prevention

Every incident is an opportunity to strengthen your security posture.

• Log analysis: Archive relevant logs (/var/log/apache2/access.log, /var/log/secure, cPanel’s /usr/local/cpanel/logs) and retain them for at least 30 days.
• Patch management: Keep the OS, cPanel, and all installed software (PHP, MySQL, WordPress, etc.) up to date. Use WHM’s Upgrade to Latest Version and the OS package manager (apt update && apt upgrade -y or dnf update -y).
• Security extensions: Consider installing ClamAV for malware scanning and ModSecurity with the OWASP Core Rule Set.
• Regular backups: Verify that daily backups are running and that you can restore an account within the agreed SLA.
• Client education: Send a short security checklist to all customers (strong passwords, regular updates, limited plugins, 2FA).

Conclusion

Isolating a hacked cPanel account balances rapid containment with careful evidence preservation. By suspending the account, limiting its resource usage, cleaning the filesystem, resetting credentials, and confirming the health of neighboring sites, you can stop an attacker without causing downtime for other customers. Follow up with a thorough review, keep software patched, and educate clients to reduce the likelihood of future breaches.