Case Study 1 — The Backup That Turned a Crisis Into a Tuesday

A regional distributor was hit by the same class of human-operated ransomware that gutted the accounting firm in the chapter — but walked away with near-zero data loss and three days of downtime. The difference was not skill in the moment; it was a decision made eighteen months earlier. This is what the chapter's "calm sentence" looks like when it is actually available — and why even a clean restore does not close the case.

Background

A freight and logistics broker — about 120 employees across two sites, a fleet-dispatch operation that runs around the clock — had spent the prior year on an unglamorous security cleanup. A near-miss the year before (a phished credential caught by an alert dispatcher) and a renewal questionnaire from their cyber-insurer had pushed them into it. By the time the attack came, they had quietly done the things this chapter preaches: nightly backups to cloud object storage with Object Lock (immutable for 30 days), a weekly external drive rotated to a fireproof safe and disconnected between jobs, the backup system on its own network segment with its own credentials and MFA on the console, and — crucially — they had actually tested a restore two months earlier as part of the insurance audit.

None of that felt urgent at the time. It felt like overhead. Then, on a Thursday night, it became the only thing that mattered.

The incident and the recovery

The intrusion was textbook human-operated ransomware. The attacker exploited an unpatched VPN appliance (the perimeter-patching lesson, learned the hard way), dwelled in the network for roughly nine days, escalated to domain admin, mapped the file servers, staged and exfiltrated a customer database, then on a Sunday night ran the familiar destruction sequence and detonated:

Event ID 4688 (Sun 23:51):  vssadmin.exe delete shadows /all /quiet
Event ID 4688 (Sun 23:51):  wbadmin.exe delete catalog -quiet
  -> followed by per-file encryption of the file servers and the on-prem
     backup repository; ransom notes (.lockbit-style trailer) in every share.

The attacker did exactly what modern operators do: they hunted the backups first. They logged into the on-premises backup server with the stolen domain-admin account and deleted its jobs, then encrypted its volumes. Had that been the firm's only backup, this would have been the accounting-firm story all over again. But the immutable cloud copy could not be deleted or altered — Object Lock refuses mutation until the retention window expires, even for an administrator — and the offline drive in the safe had never been connected during the dwell period. The attacker reached everything they could reach. The two copies engineered to be unreachable survived.

The response ran the chapter's playbook without drama. The on-call manager isolated the affected segments — pulled the uplinks, disabled the VPN — but left the running servers powered, and called the number on the incident-response card (the insurer's panel firm, looped in from the first hour to protect coverage). On arrival, the IR team imaged first: a memory capture of each running server, then write-blocked disk images, each hashed inline and logged.

Evidence LOG-001  file-server-01 (RAID 5, SAS HDD)   dd image
  SHA-256: c41f8a07e93b2d65...7e0   (acquisition log == verify == MATCH)
Evidence LOG-002  backup-server (encrypted volumes)  E01 image
  SHA-256: 1b9d3c2af impossible-to-fake ...  (MATCH)

Family identification (ransom note plus a sample file to ID Ransomware) returned a current LockBit-affiliate variant with no public decryptor — which mattered not at all, because Option 1 was alive. The team did not rush the restore. They rebuilt the servers from known-good media, patched the VPN appliance, rotated every credential in the domain, and confirmed the initial-access hole was closed before a single byte was restored. Only then did they restore from the immutable cloud backup, verify the data, and bring dispatch back online. Total downtime: about three days, most of it spent on the rebuild-clean-and-close-the-door work, not on the data itself. Recent data loss: effectively zero, back to the last nightly job.

That is the calm sentence the chapter promises: we isolated, preserved evidence, rebuilt clean, restored from our offline copy, and lost almost nothing.

The complication: recovery is not absolution

Here the case earns its place beside the anchor rather than just echoing it. The forensic timeline — the very work a recovery-only mindset would have skipped to "save time" — answered the question that backups cannot: what did they take? Carving the unallocated space of the file-server image resurrected the attacker's staged exfiltration archive, a .7z built two days before detonation, and the firewall logs confirmed roughly 95 GB pushed to an external host. Inside that archive: a customer table with names, addresses, contact details, and a subset of stored payment data.

So despite near-zero data loss, the firm had a reportable data breach. The exfiltration started legal clocks — state breach-notification statutes and contractual obligations to several large customers — that a perfect restore did nothing to stop. They engaged counsel, filed the required notifications, and offered affected customers credit monitoring. They did not pay: there was no operational need (the data was restored), the OFAC exposure was real, and paying "for deletion" of the stolen archive would have bought only an unverifiable promise from a criminal. The leak site listed them anyway; they had braced their customers for it in advance, which blunted the blow.

The honest accounting: a mature firm turned what could have been an extinction-level event for a thin-margin logistics business into a bad three days and a manageable, if expensive, breach-notification process — and the single line item that made the difference cost a few hundred dollars a month in immutable cloud storage.

The analysis

  1. The decision that saved them was made eighteen months early. Nothing the team did in the moment was heroic; the heroism was the boring prior-year work — immutable backups, offline rotation, a segmented backup network, and a tested restore. The entire downhill slide from "routine restore" to "negotiate with extortionists" is decided before the attack, and this firm had decided well.

  2. Immutability beats an attacker with full admin rights. The operators did everything right from their side — stole domain admin, found the backup server, deleted its jobs, encrypted its volumes. It did not matter, because Object Lock and an air-gapped drive are not defeated by credentials. What cannot be mutated or reached cannot be ransomed.

  3. Preserve first even when you are sure you will restore. It would have been tempting to wipe and rebuild immediately given the confidence in backups. Imaging first cost a few hours and produced the timeline and the exfil archive — the evidence the breach response, the insurer, and the customers' lawyers all required. A wipe-and-restore would have erased the answer to "what was taken."

  4. Recovery is not absolution. Near-zero data loss did not end the incident, because the data had already been copied out. Exfiltration is a breach regardless of how cleanly you restore; restoring the files does not un-steal them. The firm understood this and ran the legal track in parallel with the technical one.

  5. Close the door before you walk back through it. They patched the VPN and rotated credentials before restoring. Restoring onto the still-vulnerable environment would have invited re-encryption within days — the exact mistake Case Study 2 makes.

Discussion questions

  1. This firm restored in three days with near-zero loss; the accounting firm in the chapter's worked example took a week and permanently lost its two busiest months. Identify the single difference in preparation that separated the two outcomes, and explain why every other factor was downstream of it.

  2. The firm notified customers and offered credit monitoring despite losing almost no data. What does the phrase "we restored everything" fail to capture, and why is exfiltration a breach even when availability is fully recovered?

  3. The attacker held domain-admin rights and deleted the on-premises backup repository, yet could not touch the immutable cloud copy or the offline drive. Explain specifically what stops a full administrator from deleting Object Lock storage, and why "offline" is a different protection than "encrypted" or "offsite."

  4. They chose not to pay even after being listed on a leak site. Walk the cost/benefit they faced, and state precisely what paying "for deletion" would and would not have bought them.

  5. ⭐ Reframe this as forensics-for-litigation: suppose affected customers later sue, alleging negligence. Which artifacts from the IR work — memory images, disk images, hashes, the intrusion timeline, the carved exfiltration archive — become evidence, and what specifically would have been unavailable if the firm had wiped and restored without imaging first? Cite the chapter that owns report writing and the one that owns the legal framework.