Close the entry point before restoring, choose a copy from before the compromise rather than the most recent, and write down what happened between then and now.

Restoring first is the common mistake

The instinct on discovering a compromise is to get the site back, immediately, which is understandable and is the wrong order.

A restore returns the site to a working state and does nothing about how somebody got in.

If the entry point was an outdated plugin, restoring puts the outdated plugin back, and the same automated process finds it again within days.

Businesses go through this cycle two or three times before somebody asks why it keeps happening.

Close the hole first, then restore, even though that feels like leaving the site broken for longer.

The decisions you have to make

The first is the one that catches people. The most recent backup is the one most likely to contain the compromise, since it was taken after it happened.

Choosing which copy

The decision that determines whether the restore works.

Work out when the compromise started, as far as you can: the date of the first strange log entry, the modification date of an unfamiliar file, or when the host first noticed something.

Then choose a copy from before that, with margin, rather than the latest one.

Where you cannot establish a date, go back further than feels necessary, since restoring a compromised copy costs another cycle.

This is why retention matters and why a system keeping seven days frequently leaves nothing usable.

Check the copy before relying on it: look at the file dates and the plugin versions and confirm it predates whatever you found.

Restore somewhere else first

The step that removes most of the pressure.

Restore to a separate location, not over the live site, so you can examine it without a countdown running.

That lets you confirm the copy is clean, that it works, and that it contains what you expect, before anything is committed.

It also means the live site remains available as evidence, which matters if you need to work out what happened or report it.

Most hosts can provide a staging area, and where they cannot, a temporary subdomain does the same job.

Restoring straight over the live site removes both the evidence and the ability to reconsider.

Write down the gap

Because everything between the chosen copy and now is about to disappear.

List what happened in that period: orders, enquiries, bookings, new pages, price changes, customer accounts.

Some of it exists elsewhere, in your email or your accounting system, and can be reconstructed after the restore.

Some of it does not, and the people affected need to hear from you rather than discover it.

Do this before restoring, since afterwards you are working from memory about a period you can no longer see.

Ten minutes with the calendar and the inbox produces a list good enough to work from.

A worked example

A business discovered their site was serving unfamiliar pages and restored the most recent nightly backup within the hour.

The site looked normal for two days and the pages returned.

They restored again, from four days earlier, with the same result.

On the third attempt somebody looked at file dates and found the original modification had been six weeks earlier, before any backup they held.

The site was rebuilt from a copy taken before a redesign, the outdated component was identified and removed, and everything from the intervening period was reconstructed from invoices and email.

The whole episode took nine days, and the first two restores had cost three of them.

Restore or clean

A judgement worth making deliberately rather than by default.

Restoring is the right answer where you have a copy you trust from before the compromise, which is the usual case.

Cleaning, meaning removing the injected content from the live site, is right where no clean copy exists or where too much has happened since the last one.

Cleaning is harder than it looks, since you are relying on having found everything, and something missed brings the problem back.

Where you clean, plan on a rebuild afterwards anyway, treating the cleaned site as a temporary measure rather than a resolution.

For anything holding customer data or taking payment, get help rather than deciding this alone.

After the restore

The steps that stop the cycle repeating.

Change every password: site, hosting, registrar, email, and any connected service.

Remove accounts you do not recognise and reduce the rest to what they need.

Update everything before putting the site back in front of anybody.

Take a fresh backup immediately and store it somewhere out of reach.

Then check the search console for security notices, since a warning may be in place regardless of the site now being clean.

Keep a record while you go

Unglamorous, and it is what turns a bad week into something you can learn from.

Note the times: when it was discovered, what was found, what you did, and what changed after each step.

That record is what an insurer, a host, or somebody helping later will ask for, and reconstructing it afterwards from memory is unreliable.

It also tells you how long each stage actually took, which is the information that makes the next drill realistic.

Take copies of anything unusual before removing it: the injected file, the log entries, the unfamiliar account, since deleting the evidence is easy and permanent.

The counter-case

Speed sometimes matters more than method.

A shop losing sales by the hour has a genuine reason to get something working quickly, and a temporary holding page while you do this properly is better than either extreme.

Not every incident needs this treatment either, and a defacement on a brochure site is a smaller event than the language here suggests.

And where the business cannot afford to be wrong, particularly with customer data involved, the correct step is to stop and get somebody who does this for a living.

Close the hole, restore an older copy elsewhere, record the gap, then commit.

The order

  1. Take the site down or put up a holding page.
  2. Find and close the entry point.
  3. Establish when it started.
  4. Choose a copy from before that, with margin.
  5. Restore somewhere else and check it.
  6. Write down the gap before committing.
  7. Change everything, update, and back up again.

Step two is the one skipped under pressure, and skipping it is why businesses restore the same site three times in a fortnight.

Practising this calmly is covered in backups you have never restored.

Frequently asked questions

What is the common mistake?

Restoring first. A restore returns the site to working order and does nothing about how somebody got in, so the same automated process finds the same hole within days.

Which backup should I use?

Not the most recent, which is the one most likely to contain the compromise. Establish when it started and choose a copy from before that, with margin.

Why restore somewhere else first?

So you can confirm the copy is clean and works without a countdown running, and so the live site remains available as evidence if you need to work out what happened.

What about everything since that copy?

List it before restoring: orders, enquiries, bookings, price changes. Some exists in email or accounting and can be reconstructed; the rest needs telling people.

When should I clean rather than restore?

When no clean copy exists or too much has happened since. Cleaning relies on having found everything, so plan a rebuild afterwards regardless.

What comes after the restore?

Change every password including hosting and registrar, remove unknown accounts, update everything before going live, take a fresh out-of-reach backup, and check for security notices.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Site compromised and about to restore?

Find how they got in first. Restoring without closing it is why this happens three times in a fortnight.

Start a Conversation