Emergency response to an attack on an online store

The situation

The WooCommerce store wasn't built by us. It takes orders and holds customer data. It was compromised in February and again in March 2026, and each time the breach was discovered weeks after it happened.

The host's backups only covered 14 days, so every restore point already contained the attacker's hidden access. They also lived in the same account as the site and would have disappeared with it.

First line of defence

We were called in after the attack and stepped in straight away, in the middle of the night:

• What the attacker compromised

  We first established what the attacker had compromised and how far they had got.

• Access regained

  We took back control of the site and found the backdoor the attacker had left behind: a file posing as an ordinary WordPress file. We removed it.

• Damage found, store recovered

  We identified what had been affected and brought the store back to a clean, working state.

Audit and report

Once the emergency was over, we ran an in-depth audit. How the attacker originally got in could no longer be established with certainty, so we closed every likely way in and put in place the security measures a store of this size and traffic needs. The client received a full report: what we found and when, what we removed, the weak points, and an action plan.

Measures put in place

• Encrypted off-server backups

  Nightly database and weekly file backups in Backblaze B2, in an EU data centre. They are encrypted before leaving the server, so the storage provider sees only opaque files and cannot read customer data.

• A backup an attacker can't destroy

  The server's storage key can add and hide backups but has no permission to delete them. Even someone with full control of the server can't wipe the recovery copies. We tested this: the delete attempt is rejected.

• A verified restore

  We restored the full site, database and files, into staging and checked cart, checkout, product pages and orders. Backups are only trusted after integrity checks, because a failed dump can silently produce a valid-looking empty file.

• A routine

  Monthly integrity checks, quarterly full restore tests, and a written decision trail for open items such as who holds the encryption key.

How we work on the client's store

• Every update goes backup, staging, test, and only then live.
• Named admin accounts, minimal roles and two-factor authentication.
• A runbook, a one-page architecture and access document, and a monthly note on what ran.
• The contract states who is responsible for what. Customer data is handled only as instructed, as a processor (GDPR art. 28).

Result

The store is back to a clean state and the client knows exactly what happened and why. Another attack no longer means weeks of lost data or a rebuild from scratch: there is a tested, tamper-resistant path back to a clean state.