WordPress website hacked? The first 24 hours

Maybe Google is showing “This site may be hacked” under your name. Maybe visitors from search land on a pharmacy. Maybe your host has emailed to say your account will be suspended. Whichever it is, the next few hours matter more than the next few weeks, and the order you do things in matters most of all.

The good news first. Most hacked sites can be recovered, content and all. When a non-profit in far west Texas called me about theirs, the host was about to ban the account. Moving quickly kept it open, and an older database archive let us recover everything and reinstall on a clean, hardened setup.

Here’s the order I work in.

In hour one, contain it and don’t delete anything

The instinct is to start deleting suspicious files. Resist it. Before you touch anything, take a complete copy of the site files and the database and store it somewhere other than the server. That copy is your evidence, and it’s also your safety net if a clean-up goes wrong.

Then stop the damage spreading.

• Put the site into maintenance mode at the server level, not with a plugin. If the attacker controls WordPress, a WordPress plugin can’t be trusted to keep them out.
• Reply to your host. Tell them you’re on it and roughly when you’ll be done. Hosts suspend accounts that go quiet, not accounts that are actively being cleaned.

In hours one to two, change every password, not just WordPress

Attackers rarely stop at one door. Change all of these, from a computer you trust.

• Your hosting control panel, and any SFTP or SSH accounts.
• The database password, then update it in wp-config.php.
• Every WordPress administrator, and the email inbox each admin account uses. Whoever controls that inbox can reset the password again.
• Your domain registrar account.

Then regenerate the secret keys in wp-config.php. This is the step most people miss. Changing a password doesn’t end a session that’s already logged in, but new keys log everyone out at once. With WP-CLI it’s one command.

wp config shuffle-salts

In hours two to six, find out what actually changed

You can’t clean what you haven’t found. Start by comparing WordPress itself, and every plugin from wordpress.org, against the official copies.

wp core verify-checksums
wp plugin verify-checksums --all

Anything reported as modified or unexpected gets a close look. Then check the places attackers like to hide.

• PHP files in wp-content/uploads. That folder should only hold images and documents. A PHP file there is almost always a backdoor.
• wp-content/mu-plugins. “Must-use” plugins load automatically and don’t appear in the normal plugin list.
• Recently modified files. find . -name "*.php" -mtime -14 lists PHP files changed in the last two weeks.
• Administrator accounts you don’t recognize. wp user list --role=administrator
• Scheduled tasks. wp cron event list can reveal a job that reinstalls the malware every hour.
• .htaccess files. Look for redirects, especially ones that only fire for some visitors.

That last point catches a lot of people out. A common hack only redirects visitors who arrive from Google, or only shows spam to Google’s crawler. You look at your site, it seems fine, and you conclude nothing’s wrong. Check the way Google sees it.

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://yoursite.com/
curl -sI -e "https://www.google.com/" https://yoursite.com/

If either returns a redirect you didn’t set up, you’ve found the cloaking. A clean result isn’t proof, though, because smarter hacks check for Google’s IP addresses rather than its name. Search Console’s URL Inspection tool fetches the page from Google’s own servers, so use it to see the real thing.

Clean it or rebuild it?

If you have a clean backup from before the hack, and you know when the hack happened, restoring it is often fastest. Just remember the backup contains the same weakness that let the attacker in, so update everything straight away.

If you don’t know when it started, rebuild. I reinstall WordPress, the theme and every plugin fresh from their official sources, then bring across only the content, meaning the database (after checking it for injected scripts and rogue users) and the media library (after removing anything that isn’t media). It takes longer than deleting the obvious files, but it’s the only way to be confident nothing is left behind.

In hours six to twenty-four, get Google to trust you again

• Open the Security issues report in Google Search Console. Once the site is clean, use Request review and explain what you fixed.
• Search site:yoursite.com for pages you didn’t create. Spam hacks often add thousands. Make sure each one now returns a 404 or 410, not a redirect to your home page.
• Check whether your server’s IP address or domain has been added to an email blocklist. Hacked sites are often used to send spam, and your normal email can quietly start landing in junk folders.

Afterwards, close the door they came in through

• Delete what you don’t use. A deactivated plugin is still a folder of code on your server, and it can still be exploited.
• Stop PHP running from uploads. On Apache, a .htaccess file in wp-content/uploads does it.

  <FilesMatch "\.(php|phtml|phar)$">
    Require all denied
  </FilesMatch>

• Turn off the built-in file editor with define('DISALLOW_FILE_EDIT', true); in wp-config.php, so a stolen admin login can’t be used to edit code.
• Add two-factor authentication for every administrator, and give everyone else the lowest role that lets them do their job.
• Keep off-site backups, and test a restore. A backup you’ve never restored is a hope, not a plan.

A week from now, the site can be clean, a little faster because you removed the plugins you weren’t using, and you’ll know exactly who holds which password. That’s a better position than you were in before the hack.

Do you need WordPress at all?

Before you rebuild, ask a bigger question. Does your site actually need WordPress? If it’s mostly pages about your business, some photos and a contact form, a static site built from plain HTML, CSS and JavaScript will probably work just as well. A static site has no database to inject, no admin login to steal and no plugins to exploit, so most of the attacks in this post have nothing to work with.

This site is static. That means no database, no PHP and no reliance on WordPress.org, so I don’t care who Matt Mullenweig is feuding with instead of maintaining what has become a too-big-to-fail technology that powers far too much of the Interwebs. Unlike with WordPress, I sit at my desk (or on the lanai with a G&T and my laptop), write posts, then set each one to publish automatically on its scheduled date, with no themes or plugins to keep updated.

If you’re running a WordPress website today, I can almost guarantee there is a static solution to what you’re doing. Unless you have some masochistic need to maintain an increasingly messy codebase, you should probably drop me a line. I’ll be sipping G&Ts.