Public incident case studyReviewed 2026-08-24

01 · What it was

One account, seventeen websites.

A long-running web development company had kept every client site together in one hosting account. One break-in could reach all of them.

This is an anonymized account of a real incident involving real companies and real money. Direct identifiers and sensitive infrastructure details have been removed.

17client sites shared one account
Decadesin business before the incidentA long history did not make the setup safe.

The sites lived in one directory tree. Anything able to write to one site could write to every other site beside it. The account boundary that should have contained one failure did not exist.

02 · What was happening

The spam was the decoy.

Casino pages were the visible mess. Underneath, the account had become a machine for finding database passwords belonging to other customers of the same hosting company.

1,190other customer accounts targeted
1,177,495malicious links
28,963files built to install more malware
103hidden ways back in reported by the scanner

03 · Why cleanup failed

It rebuilt faster than anyone could delete.

Two snapshots, taken 28 hours apart, showed the footprint growing while the response was already under way.

Malicious links583,2991,177,495
Installer files16,58328,963
0of the 103 reported backdoors existed in the earlier snapshot
28 hoursfor all of them to appear

You cannot enumerate your way out of a system that rebuilds itself.

04 · The eviction

One line stopped it.

One account-wide rule denied the web server permission to run program files. Every confirmed active attacker request depended on code running through that server, so the rule stopped the observed execution route immediately.

115successful attacker requests on the final dayThen zero after execution was denied.

Known hosting passwords and control-panel credentials were rotated, and the account’s SSH and FTP access paths were removed in the same window. Nothing on the old server was deleted. The malicious files stayed in place as inert evidence.

  1. Earliest confirmed attacker-controlled session. The original entry route remains unproven.
  2. The hosting company’s own scanner reports 62,877 infected files. It offers a paid cleanup.
  3. Web execution denied account-wide and all known hosting access routes closed. No later attacker execution has been observed.
  4. First site rebuilt on isolated hosting.
  5. Four sites live on the new host.
  6. Nine of eleven rebuilt sites live; the estate-wide functional sweep begins.
  7. All eleven rebuilt sites live with valid HTTPS; the final migrated mail route is verified.

05 · The decision

What we chose not to do.

We did not clean the old server. We did not accept a quote that treated each site as a separate cleanup while leaving the shared structure unchanged.

Clean in place

The attacker was still writing new files. A successful cleanup could be undone before anyone finished checking it.

Pay $109 per site

That removed symptoms without fixing why one break-in reached seventeen sites.

Rebuild with isolation

One account per client on the new host, for roughly $20 more each month. A future failure is contained to one client.

06 · The method

How each site was rebuilt.

Content came from each site’s own database and media. Its program files never crossed the boundary into the new account.

  1. 01

    Create an isolated account for one client only.

  2. 02

    Install the publishing platform fresh from its maker. Copy no program files from the compromised server.

  3. 03

    Copy content only: images, documents, and media. Leave executable and configuration files behind.

  4. 04

    Import the site’s database and clean it.

  5. 05

    Reinstall add-ons from their official sources.

  6. 06

    Compare every installed file with the maker’s published digital fingerprints.

  7. 07

    Run the automated pre-launch check. It must report CLEARED.

  8. 08

    Only then point the public address to the site and issue its security certificate.

07 · Three findings

The evidence changed the response.

01

The backdoor inside the database.

A stored instruction watched for a particular phrase in a new comment, then silently created a new administrator. Deleting files, reinstalling the platform, or removing the rogue account would not stop it. The instruction also travelled inside a database export.

It was caught because the new database account was not allowed to create that kind of instruction. The import failed loudly instead of succeeding quietly. Five of thirteen exports carried it.

02

Dating the damage to a 28-hour window.

Two database snapshots were compared marker by marker. Six of eight databases were clean in the earlier copy and defaced in the later one. The defacement had happened during the response, not at the original intrusion. Several repair jobs became straightforward restores from the earlier copies.

03

Clean because empty.

One backup had been labelled as a copy from before a site was wiped. It had actually been taken afterward. It contained no malware because it contained almost nothing at all. Clean and intact are different properties; proving one says nothing about the other.

08 · Current status

Where it stands.

11live
0built
0to do

09 · Unfinished work

What is still open.

Last reviewed . This record will change when the evidence does.