知識庫

Discovering that your website has been hacked is stressful, but the situation is almost always recoverable. This article walks through how to spot a compromise, how to triage damage, and how to restore a clean site without making the problem worse. If you're mid-incident right now: the most important thing is to not delete logs or backups, and open a ticket with us — we've handled thousands of incident recoveries and won't bill for triage time.

Common signs your site is compromised

• Browser warnings: Chrome, Firefox, or Safari shows "Deceptive site ahead" or "This site may harm your computer." This means Google Safe Browsing or a similar service flagged you.
• Search results full of pharma/casino/spam keywords: Google's "site:yourdomain.com" returns pages you didn't create, often in foreign languages or about prescription drugs.
• Mail server blacklisted: outbound email starts bouncing with "blocked due to spam." Hackers often use compromised hosting to send phishing.
• Site redirects to a different domain: visitors land on your site but get bounced to gambling or porn sites. Often happens only on mobile or only on certain referrers.
• Unfamiliar admin users in WordPress: wp-admin → Users shows accounts you didn't create, often with admin role.
• Files modified you didn't touch: in cPanel's File Manager, sort by Last Modified. Look for recent changes to wp-config.php, .htaccess, or files in wp-content/uploads/.
• Sudden traffic spikes from one country: Google Analytics shows 10,000 visitors from Russia overnight on a small business site. The site is being used as part of a botnet.
• cPanel emails about high CPU/memory: hackers often install crypto-miners that pin a CPU core to 100%.

Step 1: Don't panic. Don't delete anything.

Logs and modification times are evidence. If you delete files randomly trying to "clean up," you destroy the audit trail and may make our recovery harder. Take a deep breath.

Step 2: Take the site offline, but keep it accessible

You don't want visitors hitting infected pages, but you need to be able to fix the site:

1. In cPanel's File Manager, navigate to public_html.
2. Create a file called maintenance.html with a "We'll be back shortly" message.
3. Edit .htaccess at the root of public_html. Add at the very top:

   RewriteEngine On
   RewriteCond %{REMOTE_ADDR} !^YOUR.IP.GOES.HERE$
   RewriteCond %{REQUEST_URI} !^/maintenance.html$
   RewriteRule ^(.*)$ /maintenance.html [R=302,L]

   Replace YOUR.IP.GOES.HERE with your actual IP from api.ipify.org. This sends every visitor except you to the maintenance page.

Step 3: Change every credential

Assume everything has been read by the attacker. Reset:

• cPanel password (cPanel → Password & Security)
• WordPress admin password (wp-admin → Users → your profile)
• FTP account passwords (cPanel → FTP Accounts)
• Database passwords (cPanel → MySQL Databases → reset password for each user, then update wp-config.php with the new password)
• Email account passwords if mailboxes were involved (cPanel → Email Accounts)

Now is also the time to enable 2FA on your cPanel and WHMCS accounts if you haven't.

Step 4: Identify what was changed

Use cPanel's File Manager to sort files in public_html by Last Modified date. Anything modified during a window when you didn't deploy is suspect. Common attack patterns:

• Backdoor files in /uploads: e.g., wp-content/uploads/2024/eval.php. Hackers drop PHP files in directories that should only contain media.
• Modified core files: wp-includes/load.php or similar with extra code at the top. Compare against a fresh WordPress download.
• Modified .htaccess: redirects or rewrites you didn't add.
• Modified wp-config.php: extra require or include lines pointing at suspicious files.

Step 5: Restore from a known-clean backup

If you have a backup from before the compromise, this is the safest recovery:

1. Determine roughly when the compromise happened (the earliest suspicious file modification gives a date).
2. Find a backup from before that date. Server backups go back 90 days — open a ticket with the date and we'll restore.
3. Restore public_html from the clean backup. Keep the database only if you're sure no malicious admin users were created during the compromise window — otherwise restore the database too.
4. After restore, immediately update WordPress core, all plugins, and all themes to the latest version. Whatever vulnerability was exploited is likely patched in current versions.

If you don't have a clean backup, we can usually still recover by manually scanning and removing malicious files — but it's slower and doesn't catch every clever backdoor.

Step 6: Scan with malware tools

Even after a restore, double-check with automated scanners:

• cPanel ImunifyAV (under Security): scans your account for known malware signatures. Free, takes 5-30 minutes.
• Wordfence (WordPress plugin): full WordPress-specific scanning. The free version is excellent.
• MalCare (paid, WordPress): cloud-based scanning, doesn't use your server resources.

Run all of them. Each catches things the others miss.

Step 7: Harden against re-infection

Hackers maintain lists of previously-compromised sites and re-attack them constantly. Once cleaned, you must close the door:

• Update everything. WordPress core, all plugins, all themes. Outdated software is the #1 cause of compromises.
• Remove unused plugins and themes. Code that isn't executing can still have vulnerabilities; deactivated isn't enough — delete.
• Install Wordfence or Solid Security with default settings.
• Enable 2FA on cPanel, WHMCS, and WordPress admin.
• Disable file editing in WordPress: add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. Prevents an attacker who gets a low-privilege account from editing theme/plugin code via wp-admin.
• Restrict wp-admin access via .htaccess if your audience is small enough — allow only specific IPs.

Step 8: Request review from Google

If your site was flagged in Google Safe Browsing or your search results were poisoned:

1. Go to Google Search Console.
2. Under Security & Manual Actions → Security Issues, check what was flagged.
3. Once you've cleaned the site, click Request Review.
4. Google typically responds in 1-3 days. Most reviews are approved on the first request if the site is genuinely clean.

The honest truth about full recovery

If a site has been compromised, restoring from a clean backup is always cheaper and more reliable than trying to manually clean an infected install. Hackers leave subtle backdoors in dozens of places and finding them all manually is error-prone. If you're not 100% sure your "cleaning" caught everything, restore from clean backup and rebuild what was lost.

If you're unsure whether your backups are clean, or you don't have backups going back far enough, open a ticket. We can pull from server snapshots that go back 90 days and find a clean restore point. We don't charge for incident response on shared and reseller accounts.