Hacked Website Recovery

When recovery is the right call

Some incidents leave a site that technically still loads but cannot be trusted. Others leave nothing usable at all. Recovery is the better choice when any of these apply:

• the home page has been replaced or defaced and the admin area no longer opens;
• the attacker created administrator accounts weeks or months ago, so there is no way to know everything they changed;
• the theme or plugins were written for you and cannot be compared against a clean public copy;
• the database contains thousands of spam pages, injected scripts in many posts, or altered settings throughout;
• a failed update, a deleted folder or a host migration has left the site broken, even without a hack.

In each case, repairing the existing site line by line would cost more and still leave uncertainty. Restoring known good files removes that uncertainty.

How a recovery works

1. Preserve the damaged site. We copy the files, database and any logs before making changes. The copy is evidence, and it holds recent orders, enquiries and content that may not be in any backup.
2. Establish a timeline. File dates, new accounts and log entries usually show roughly when the break-in began. That date decides which backups are worth using.
3. Choose the starting point. If a backup predates the break-in and passes our checks, we restore it to a separate, private location. If not, we install fresh WordPress, a clean copy of your theme and plugins from their source, and move content across.
4. Bring recent data forward. Posts, pages, products, orders and form entries created after the backup are exported from the preserved copy, checked for injected code, and imported.
5. Harden before reopening. All passwords and security keys are changed, unused plugins are dropped, software is updated, and the hardening steps in the WordPress guide are applied ^[1].
6. Test, then switch. We test forms, logins, checkout, search and the pages that bring in the most visitors. Only then does the domain point at the recovered site.

Customer data and your obligations

If the site stores customer details, such as accounts, orders or enquiry form entries, a hack can also be a data breach. For organisations covered by the Privacy Act, the OAIC's guidance sets out four steps: contain, assess, notify and review. If you only suspect an eligible breach, you must take all reasonable steps to complete an assessment within 30 calendar days ^[2].

We are not lawyers and we do not make that assessment for you. What we can do is record what the attacker could reach, when, and what evidence exists, so that you or your adviser can assess it properly. Our guide to data breaches and hacked websites explains who the scheme covers.

After the site reopens

If Google flagged the site, we confirm the cleanup and request a review through Search Console. Warnings come off once Google is satisfied, and our guide to Google review requests explains the stages and the timings Google publishes. We also recommend a period of closer monitoring, because a recovery removes what was there but cannot stop a fresh attempt using the same stolen password if one was missed elsewhere.

If the restored site loads slowly because of leftover spam data or plugins added during the incident, see speed fixes after an incident.

Your report covers the timeline, the chosen starting point, the data brought forward, the hardening steps and anything that still needs your attention, such as changing an email password or telling a payment provider.

What you receive at the end

A recovery is not finished when the site loads again. You should be left with enough information to understand what happened, to answer questions from customers or your insurer, and to stop it happening again. At the end of a recovery we provide a written report in plain English that covers:

• how the site was affected, as far as the evidence shows, and the files, accounts and database entries that were changed;
• what we removed, replaced or restored, and from which backup, if any;
• every password, key and account that was changed or removed, so you can confirm nothing was missed;
• the hardening changes we made, and any we recommended but did not make, with the reason;
• the status of any warnings from Google, your host or others, and what is still pending;
• a short list of what to watch over the following weeks.

Where the evidence does not show how the attacker got in, the report says so plainly rather than guessing. That uncertainty matters for your own decisions, including whether customer data may have been involved, and it is better to know about it than to be falsely reassured.

We also give you the copy of the site taken before cleanup, so the original evidence stays with you.

How to prepare

You can save time by gathering a few things before you contact us: the name of your host, any backup service you pay for, the date you first noticed a problem, and the people who have had admin access. The incident checklist turns that into a short text file you can attach to your email. Please leave passwords out of it.

If the site is still online and redirecting visitors, you may want to put up a maintenance page first. Our guide to the first steps after a hack explains how to do that without destroying evidence.