Your Site Got Hacked: A Step-by-Step Recovery Guide
Table of Contents
- 1. Signs Your Site Has Been Compromised
- 2. Don't Panic: Immediate First Steps
- 3. Assess the Damage
- 4. Take Your Site Offline Safely
- 5. Clean Up the Infection
- 6. Restore from Backup
- 7. Harden Your Defenses Post-Recovery
- 8. Notify Affected Users
- 9. Prevent Future Attacks
- 10. When to Call a Professional
Signs Your Site Has Been Compromised
Recognizing a compromise early minimizes damage. Not all hacks are obvious defacements. Many attackers prefer to stay hidden, using your server for spam, cryptocurrency mining, or redirecting your visitors to malicious sites. Watch for these warning signs:
- Unexpected redirects to unfamiliar websites
- Google Search Console security warnings or manual actions
- Browser warnings ("This site may be hacked" or "Deceptive site ahead")
- Unfamiliar user accounts in your CMS admin panel
- Modified files you did not change (check timestamps)
- Unusual server resource usage (CPU spikes, bandwidth increases)
- Spam emails being sent from your domain
- New pages or posts you did not create (often in foreign languages)
- Your site loading significantly slower than normal
- Customers reporting strange behavior or phishing attempts from your domain
If you notice any combination of these signs, treat it as a confirmed compromise and proceed with the steps below immediately.
Don't Panic: Immediate First Steps
Your instinct may be to delete everything and start over. Resist that urge. Hasty actions can destroy evidence needed to understand the attack and prevent future compromises. Follow these immediate steps in order:
- Document everything. Screenshot any visible signs of the hack. Note the exact time you discovered the issue. Record any recent changes you made to the site (updates, new plugins, configuration changes).
- Change all passwords immediately. Start with hosting account, FTP/SFTP, database, CMS admin, and email accounts. Use a different device if possible, in case your computer is compromised.
- Revoke all active sessions. Log out all users from your CMS. Invalidate any API keys or tokens that may have been exposed.
- Contact your hosting provider. Notify them of the compromise. They may have additional server-level logs, can help isolate the attack, and can check if other sites on the same server are affected.
- Do NOT delete files yet. You need them for forensic analysis to understand how the attacker got in and what they accessed.
Assess the Damage
Before you can clean up, you need to understand the scope of the compromise. This assessment determines your recovery strategy.
Check files: Compare your current files against a known-good backup or the original source. Look for recently modified files, new files in unexpected locations, and files with obfuscated code (base64-encoded strings, eval() statements, long strings of random characters).
# Find files modified in the last 7 days
find /path/to/site -type f -mtime -7 -ls
# Search for common malware indicators
grep -r "eval(base64_decode" /path/to/site/
grep -r "exec(" /path/to/site/wp-content/
Check the database: Look for unfamiliar admin accounts, modified content, injected scripts in posts or pages, and changes to the site URL or admin email settings. Check the wp_options table for suspicious values.
Check user accounts: Review all user accounts, especially those with administrative privileges. Attackers often create backdoor accounts with admin access using non-obvious usernames.
Take Your Site Offline Safely
Taking your site offline prevents further damage to visitors and stops the attacker from using your site for ongoing malicious activity. There are several ways to do this safely:
Maintenance mode: Put up a simple maintenance page that does not load any CMS code. A static HTML file with a message like "We are performing scheduled maintenance" prevents visitors from encountering malicious content.
.htaccess method: You can redirect all traffic to a maintenance page while you work on cleanup:
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR.IP.ADDRESS$
RewriteRule .* /maintenance.html [R=503,L]
DNS redirect: Point your domain to a temporary holding page while you clean the actual server. This completely isolates the compromised environment from public access while you work on it.
Clean Up the Infection
Once you understand the scope, systematically clean the infection. Work methodically through each component:
- Replace core files. Download a fresh copy of your CMS from the official source and replace all core files. Do not overwrite wp-config.php or your wp-content directory yet.
- Remove unfamiliar files. Delete any files that do not belong. Pay special attention to files in uploads directories (attackers often hide malware in image folders), theme directories, and plugin directories.
- Clean the database. Remove unauthorized admin accounts. Check all posts and pages for injected scripts. Reset the site URL and admin email if they were changed. Remove any suspicious scheduled tasks (cron jobs).
- Update everything. After cleaning, update WordPress core, all plugins, and all themes to their latest versions. These updates close the vulnerabilities the attacker likely exploited.
- Remove unused components. Delete all inactive plugins and themes. Even deactivated code can contain vulnerabilities and backdoors.
Restore from Backup
Sometimes manual cleanup is too complex or the compromise is too deep. In these cases, restoring from a clean backup is the better option. Here is when and how to do it effectively:
When to restore: Choose restoration over manual cleanup when the malware is extensively spread across many files, when you cannot determine the full scope of changes, or when the time to manually clean exceeds the time to restore and re-apply recent legitimate changes.
Choosing the right backup: You need a backup from before the compromise began. This may not be your most recent backup if the attacker maintained access for a period before being discovered. Review backup dates against your access logs to determine when the initial breach occurred.
After restoration: Immediately change all passwords, update all software, and apply the security hardening measures in the next section. The vulnerability that allowed the original attack still exists in your restored backup and must be patched before bringing the site live again.
Harden Your Defenses Post-Recovery
Recovery without hardening guarantees you will be hacked again. The attacker now knows your site is vulnerable. Apply these measures before bringing your site back online:
- Install and configure a web application firewall
- Enable two-factor authentication on all admin accounts
- Change all database prefixes if they were the default (wp_)
- Set proper file permissions (755 for directories, 644 for files)
- Disable file editing in wp-config.php
- Implement login attempt limiting
- Set up file integrity monitoring for immediate alerting
- Configure automated off-site backups
- Review and restrict user account permissions
- Implement security headers (CSP, X-Frame-Options, HSTS)
Notify Affected Users
If user data may have been exposed, you have both an ethical and potentially legal obligation to notify affected parties. Many jurisdictions have breach notification laws with specific timelines.
When notification is required: If your site stores personal information (names, emails, passwords, payment data, addresses) and the attacker had database access, assume data was exfiltrated. Notification is required under GDPR (72 hours), CCPA, and many other regulations.
What to communicate: Be transparent about what happened, what data may have been affected, what steps you have taken, and what users should do (change passwords, monitor accounts). Avoid minimizing or obfuscating the situation.
Force password resets: If your site has user accounts, force all users to reset their passwords on next login. Many users reuse passwords across sites, so a compromised password on your site may put their other accounts at risk.
Prevent Future Attacks
Use this incident as a catalyst for building a sustainable security practice. Address the root cause, not just the symptoms:
Identify the entry point. Review server logs to determine exactly how the attacker gained access. Was it a vulnerable plugin? Stolen credentials? An outdated PHP version? You cannot prevent recurrence without understanding the initial vector.
Establish update procedures. Create a schedule for applying updates. Automate where possible. The majority of WordPress hacks exploit known vulnerabilities with available patches.
Implement monitoring. Set up continuous security scanning, uptime monitoring, and file change detection. These tools catch future compromises in hours instead of weeks.
Document and train. Document what happened, how you responded, and what you changed. If you have a team, train them on security awareness and the incident response procedure.
When to Call a Professional
Not every hack requires professional help, but some situations warrant expert intervention. Consider calling a security professional when:
- You cannot identify the entry point or the full scope of the compromise
- The malware keeps returning after cleanup (indicating a missed backdoor)
- Sensitive customer data (payment information, personal records) may have been accessed
- You are facing legal notification requirements and need forensic documentation
- The attack is sophisticated (targeted, persistent, or involves zero-day exploits)
- Your business cannot afford extended downtime while you learn the recovery process
- Multiple sites on your hosting account are affected
Professional incident response teams have the tools, experience, and forensic expertise to handle complex compromises efficiently. The cost of professional help is almost always less than the cost of prolonged downtime, repeated infections, or regulatory penalties from mishandled breach notifications.
Need Emergency Incident Response?
Our incident response team provides rapid malware removal, forensic analysis, and post-recovery hardening. We respond within 24 hours and get your site back online safely.
View Incident Response Service