Module 7 · 7.5

English

Nederlands English Deutsch Français

Hacked: recognise, recover and prevent

Module 7: Security · Reading time: 10 minutes

Learning objective: After this lesson, you can recognise a hack, recover from it in the right order and prevent it from happening again.

Key concepts: signs of a hack, recording evidence, isolating, replacing all passwords and salts, finding the entry point, logs, clean backup, clean reinstall, checksums, unknown administrators, PHP in uploads, mu-plugins, Search Console, reporting a data breach

What a hack is

A website is hacked when someone gains control over (part of) your website without permission: they can change files or the database, or run code. They often stay in through a backdoor: a hidden file or piece of code that lets them come back later, even after you close the original vulnerability.

That last point is the core of this lesson: removing just the visible damage is not enough. As long as the backdoor exists, or the vulnerability they got in through is still open, it will happen again. Often within days.

Recognising a hack

Signs (some you'll see, some you need to look for):

Google reports "This site may be hacked" for your website, or Search Console reports a security issue.
Search results (site:example.com) show pages you don't recognise, often in another language or about medication, gambling or fake shops.
Visitors are redirected, often only when they come from Google or use a phone. You don't see it yourself, because you're logged in or arrive via a bookmark. Test in a private browser window via a search result.
There's an administrator under Users that you don't recognise.
There are PHP files in wp-content/uploads, or files with odd names in the root directory or in wp-content/mu-plugins.
Your hosting provider or a malware scanner reports infected files; your mail is rejected or your package sends spam.
The website suddenly runs slowly or your storage fills up.

The step-by-step plan

1. Stay calm and record evidence

Don't throw everything away straight away. Note what you see and since when, take screenshots, and make a copy of the current state (files and database, or an extra backup through your hosting provider). You'll need that copy to find the entry point, and as evidence. Don't store it in the web directory.

2. Stop the damage to visitors

Temporarily take the website offline or put it behind a maintenance page, especially if visitors are being redirected to malware or phishing. In DirectAdmin you can suspend the domain; elsewhere, a password on the whole website or a temporary index.html with a notice will do.

3. Replace all passwords and keys

Assume the intruder knows every password that could be found on or through the website. Replace the following, preferably from a different (clean) computer:

the password for your hosting panel and for all FTP and SFTP accounts (remove accounts you don't use);
the password of the database user, and update it in wp-config.php;
all WordPress administrator passwords, and remove accounts you don't recognise;
the keys and salts in wp-config.php (lesson 1.3). This invalidates all login cookies, including the intruder's;
application passwords (lesson 3.3) and API keys for integrations;
email passwords, if spam was sent through a mailbox.

Then turn on two-factor authentication everywhere (lesson 7.3).

4. Finding the entry point

Without knowing the entry point, you can't be sure it's closed. The most common causes (lesson 7.1), and where to look:

An outdated plugin or theme: which components were behind? Look up the names in a vulnerability database (lesson 5.3).
A leaked password: check the login history of your hosting panel and of FTP.
The web server logs: search around the time the first odd files appeared for POST requests to unknown files or to plugin files, often from the same IP address.
Files by date: sort by modification date in File Manager or via SFTP. Files that were changed at the same time, especially outside an update, deserve attention.

5. Cleaning up

Two routes, and often a combination:

A. Restore a clean backup from before the hack (lesson 8.2). Choose a backup from well before the first signs, as intruders sometimes wait weeks. Restore completely, so that added files disappear too. Update everything straight away afterwards (otherwise the vulnerability reappears). Downside: everything after the backup (posts, orders) is lost.

B. Rebuild cleanly using the existing content:

Replace WordPress itself with a fresh copy from wordpress.org (wp-admin, wp-includes and the loose files; not wp-content and wp-config.php). With WP-CLI you can first check what has changed:

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

These compare your files with the official versions and report any changed or extra file (the second command only for plugins from the plugin directory on wordpress.org).

Remove all plugins and themes and reinstall them from the source, in the latest version. What you don't need doesn't come back.
Check wp-content/uploads for PHP files and other non-media files, and wp-content/mu-plugins.
Check .htaccess for odd redirect rules, and wp-config.php for lines you don't recognise.
Check the database: unknown administrators, the siteurl, home and active_plugins options in wp_options, and search posts for injected scripts (<script with odd addresses).
Check scheduled tasks: cron jobs in your hosting panel and WP-Cron (with a plugin or wp cron event list).

A malware scanner (from your hosting provider or a plugin) helps you find things, but don't trust it blindly: what it doesn't find may still be there.

6. Locking down and checking

Update everything, harden (lesson 7.4) and turn the website back on.
Is your website flagged as unsafe by Google? Ask for a new review under Security issues in Search Console, but only once everything is clean.
Keep an eye on things in the following weeks: new files, new administrators, alerts from your scanner. If it comes back, the entry point or a backdoor hasn't been found yet.

Personal data: reporting a data breach

If intruders could access personal data (customer data from an online shop, form submissions, membership lists, your website's users), this counts as a data breach under the GDPR. In that case, you must report it within 72 hours of discovering it to the supervisory authority for privacy in your country, unless it's unlikely to pose a risk to the people involved (article 33 GDPR). If the risk is high, you must also inform those people directly (article 34). In any case, record what happened and what you did, even if you don't report it. If you're unsure, check the website of the supervisory authority for privacy in your country (lesson 9.3).

Asking for help

Cleaning up a hack takes time and experience. If you're not sure you've caught everything, ask for help: your website builder, a specialised company, or your hosting provider (some hosting providers, including WebOké, offer this, usually for a fee). Give them the copy from step 1, what you saw and when, and what you've already done.

Summary

A hack often leaves a backdoor behind; removing just the visible damage is not enough.
Order: record evidence, protect visitors, replace all passwords and salts, find the entry point, clean up, lock down and check.
You can clean up with a clean backup from well before the hack, or by freshly installing WordPress, plugins and themes and checking uploads, mu-plugins, .htaccess and the database.
wp core verify-checksums shows which WordPress files have been changed.
If personal data was involved, report the data breach within 72 hours to the supervisory authority for privacy in your country, unless a risk is unlikely.

Quiz

Exercise

Exercise D7.5: Your emergency plan for a hack. Fill in the emergency plan for your own website, so you don't have to figure it out when it happens: where are your backups and how far back do they go, who has which passwords and how do you replace them all (list), where do you find your hosting logs, who do you call for help, and what personal data is on your website (for the question of whether you need to report a data breach). Then do the exercise: which five steps do you take in the first hour after receiving the message "This site may be hacked", in what order, and why that order?

Exercise D7.5: Your emergency plan for a hack

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

Where my backups are stored and how far back they go
A list of all passwords I need to replace
Where the logs are stored
Who I call
Which personal data is on the website

The five steps for the first hour, in order, with the reasons why

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing