Recovering a Clean, Secure Site

Once you've assessed the damage and identified the vulnerability, the focus shifts to restoring your site and removing any trace of the attacker. You'll need administrator-level shell or terminal access to your web, database, and file servers, a working knowledge of command-line tools, and enough storage for full backups of your files, database, and images.

Pre-Cleanup Considerations

Before you start deleting files, take a moment to review your situation. If the attack involved phishing or may have exposed users' personal information, you might have business, regulatory, or legal obligations to address first. The Anti-Phishing Working Group's document "What to do if your site has been hacked by phishers" is a useful starting point for those cases.

You should also decide how to handle the URLs the hacker created. If the attacker generated entirely new, user-visible pages that you never want surfacing in Google Search results, use the Remove URLs tool in Search Console to expedite their removal. This is optional—if you delete the pages and return a 404 status code, they'll drop out of the index naturally. Just remember that this tool is only for pages you want gone permanently, not for previously legitimate pages that were merely defaced. Those you'll restore and want indexed again.

Separately, for any new or updated clean pages, you can Ask Google to recrawl your URLs to speed up indexing. Skipping this doesn't hurt you; Google will find the changes on its own schedule.

Restoring Your Site's Content

Your cleanup strategy depends entirely on what backups you have. Before relying on any backup, confirm it was created before the compromise.

Case 1: Clean and Current Backup

This is the ideal scenario. Restore the backup, then install all available security updates and patches for the operating system and every application, including your CMS, plugins, and templates. Delete any software the site no longer uses. Address the root cause of the vulnerability and verify that every issue noted during your initial damage assessment is resolved. Finally, change every password associated with the site—FTP, database, system admin, and CMS accounts. On Unix-based systems:

passwd admin1

Case 2: Clean but Outdated Backup

Start by making a disk image of your current, infected site as a safety measure. Label it clearly as infected.

dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9 \
> /mirror/full-backup-20120125-infected.gz

Next, create a file system copy of the server, including any images and media files. If you have a database, back that up too.

tar -pczf full-backup-20120125-infected.tar.gz www/
mysqldump -u root -p --all-databases | gzip -9 \
> fulldb_backup-20120125-infected.sql

Now you can restore the clean but outdated backup, remove any software you no longer need, and upgrade everything to the latest secure versions. Correct the original vulnerability, then perform a diff between the clean restored site and your infected copy. This shows you exactly what content was changed or added.

diff -qr www/ backups/full-backup-20120124/

From the infected copy, upload only the new, clean content you want to preserve to the upgraded server.

rsync -avz /backups/full-backup-20120124/www/clean-file.jpg /www/

Check that each compromised URL from your assessment returns clean content, then change all passwords once more.

$passwd admin1

Case 3: No Backup at All

Make two backups of the still-infected site to protect yourself from accidental data loss during cleanup. Label both as infected. One should be a disk image for easy restoration in an emergency:

dd if=/dev/sda bs=1024 conv=noerror,sync | gzip -c -9 \
> /mirror/full-backup-20120125-infected.gz

The other should be a file system copy, including the database if you have one:

tar -pczf full-backup-20120125-infected.tar.gz www/
mysqldump -u root -p --all-databases | gzip -9 \
> fulldb_backup-20120125-infected.sql

If you can't create a disk image, make two copies of both the database and the file system.

Work on one of these backup copies—not the live server—to strip out the hacker's changes:

  1. Correct any overly permissive file permissions you found during your investigation.
  2. Clean all files that correspond to the compromised URLs you discovered, whether they're server configuration files, JavaScript, HTML, or PHP.
  3. Ensure any new files created by the attacker return a 404 response. If you chose not to submit them via the Remove URLs tool, this is essential to prevent them from lingering in search results.
  4. Fix the root cause vulnerability, whether it's in your code or due to weak passwords. Input validation libraries or a security audit can help.
  5. If your site has a database, clean up the hacker-modified records. Be thorough: check records beyond the obvious ones to confirm the database is genuinely clean.
  6. Change all passwords once more. On Unix-based systems:
$passwd admin1

Once this backup copy is clean, set it aside. It becomes your trusted source for the next step.

Final Server Cleanup and Restoration

Remove Unnecessary Software

Before proceeding, review and uninstall any applications, plugins, or widgets that your site doesn't actively use. Each piece of extra software is a potential attack surface. Removing them simplifies maintenance and hardens security.

Clean Installation on All Servers

Don't simply upgrade your existing server—perform a fresh installation. Upgrades can leave behind traces of the prior, compromised version. Any single infected file that survives can lead to a repeat compromise. Your fresh installation should cover the OS and all applications, followed by installation of every available security patch.

After the new installation, transfer only the known-good content and database from your clean backup copy to the new server. Be careful to maintain proper file permissions and avoid overwriting the fresh system files.

Finally, perform one last complete password change for all accounts.

passwd admin1

Staying Clean Afterward

Getting your site back online is only part of the job. A long-term maintenance plan prevents a repeat of this scenario:

  • Back up automatically and regularly.
  • Stay current on software updates. Apply security patches promptly.
  • Vet third-party software. Understand the security practices of any application or plugin before installing it, since a vulnerability in one can compromise your entire site.
  • Enforce strong passwords for every account.
  • Keep all sign-in devices secure with updated operating systems and browsers.

Before bringing your site fully back online, walk through this checklist and confirm you can answer "yes" to each question:

  • Have I taken the proper steps if the hacker obtained users' personal information?
  • Is my site running the latest, most secure version of software?
  • Have I removed all unnecessary or unused applications or plugins?
  • Did I restore my content and eliminate the hacker's content?
  • Did I fix the root cause vulnerability that allowed my site to be hacked?
  • Do I have a plan to keep my site secure?