Case Study 2 — Restored by Lunch, Re-Encrypted by Friday

A small business actually had a usable offline backup — better off than the chapter's accounting firm — and still ended the month worse than they started it. The data was not the problem. The first hour was the problem, and so was restoring into a trap with the front door still wide open. This is the cautionary mirror of Case Study 1: how good intentions and a good backup can be squandered in the gap between "found it" and "thought it through."

Background

A custom-cabinetry shop — twelve people, one owner-operator who is also the de-facto IT department, and a nephew who "is good with computers" and helps out on weekends. A single Windows file server, built on traditional 7,200-RPM hard drives, held the QuickBooks company file, years of CAD drawings, customer measurements, and the photo library the shop used for its portfolio. Their backup situation was genuinely better than the accounting firm's in the chapter: yes, there was a nightly job to an external USB drive left permanently connected to the server — but there was also a second external drive that the owner swapped weekly and kept in his truck. At the moment of the attack, that rotated drive was about five days stale and, being in the truck, completely disconnected.

By the chapter's own logic, that offline drive should have made this a one-day restore with a week's worth of loss at most. It did not. The reason is everything that happened before anyone thought to look for it.

What happened

The intrusion vector was the one the chapter names first: Remote Desktop, exposed to the internet so the bookkeeper could work from home, protected by a reused password. The attacker brute-forced it over a weekend, and on Monday morning the shop opened to renamed files and a ransom note in every folder.

The owner called his nephew, who arrived wanting to help and, in the space of two hours, made three textbook mistakes — each one a line item from the chapter's "Common mistakes":

  1. He rebooted the server "to see if that clears it." That single action discarded the contents of volatile memory — the live malware process, its connections, and any chance that a flawed family's keys could have been recovered from RAM by an analyst. It also rotated logs and erased the cheapest path to evidence. The machine that came back up was a crime scene that had been swept.

  2. He ran a full antivirus scan and clicked Remove All. The AV quarantined and deleted the ransomware binary and a handful of the encrypted files it flagged. He felt productive. In fact he had destroyed the malware sample — the one artifact needed to identify the family precisely and to check whether a free decryptor existed — and he had thinned the very encrypted files that might later have been decryptable or carvable.

  3. He found the truck drive, and restored it straight onto the same server. This is where a recoverable situation became a disaster. The restore worked. Five days of loss, everything else back. By lunch the shop was running and everyone was relieved. Nobody had closed the exposed RDP port. Nobody had rotated the bookkeeper's password. The attacker's access was untouched.

Then came Friday. The operators still had a valid login and an open door, and they simply walked back in. They re-encrypted the server a second time — and this time the truck drive was no longer in the truck. After the Monday restore, the nephew had left it plugged into the server "in case we need it again." It was online. It was encrypted along with everything else. The offline backup that had saved them on Monday had been converted, by a single careless cable, into just another casualty.

Now, and only now, the owner called a professional recovery and IR firm. The picture they inherited was grim by self-infliction:

Memory evidence:     gone (server was rebooted Monday)
Malware sample:      mostly gone (AV "Remove All")
Family ID:           uncertain (note text only; no clean sample)
Offline backup:      gone (reconnected drive encrypted in the 2nd hit)
Always-on USB drive: encrypted (both times)
Shadow copies:       deleted by the malware (vssadmin, Event ID 4688)

The partial recovery, and the unearned mercy

One thing, and only one thing, broke in their favor: the medium. The server was HDD-based, and the strain had used copy-encrypt-delete, so the original plaintext of many files still lingered in unallocated space, never overwritten. The firm imaged the server's drives — now, properly, with hashes and a chain-of-custody form started far too late to cover the first week — and carved:

foremost -t jpg,pdf,docx,xlsx,qbw -i /evidence/shop-server.dd -o /evidence/out
  jpg:=   4,031
  pdf:=     612
  docx:=    488
  xlsx:=    150
  -> ~5,300 files carved, filenames and folder structure lost

Roughly five thousand files came back — many CAD exports, portfolio photos, and client PDFs — but as 0001.jpg, 0002.pdf, with no names and no folders, requiring days of human sorting. Had the server been SSD-based, TRIM would have zeroed those deleted originals within seconds of encryption and this last mercy would not have existed; the shop survived on a property of their aging hardware, not on anything they did right. The owner spent the following weeks closing the RDP exposure, putting remote access behind a VPN with MFA, and — the lesson finally landing — buying two new external drives to rotate offline and never leave connected.

The honest accounting: a business that began the week with a perfectly good offline backup ended it having lost that backup, destroyed its own evidence, forfeited any decryptor option, suffered two encryption events, and recovered only a partial, unsorted slice of its files through the luck of spinning rust. Almost none of it was necessary.

The analysis

  1. The first hour did more damage than the malware. The reboot and the antivirus "Remove All" — both well-intentioned — destroyed the volatile evidence, the malware sample, and some encrypted files. Isolate from the network and leave it alone until someone who knows what they are doing arrives; "doing something" is not the same as helping.

  2. Restoring onto a still-compromised environment is restoring into a trap. The same exposed RDP and the same valid stolen credentials guarantee the same outcome. The vector must be closed and every credential rotated before the restore, or you are simply scheduling the next encryption — here, for Friday.

  3. An offline backup left connected is no longer an offline backup. The truck drive saved them on Monday and died on Friday for one reason: it was plugged in. "What is not connected cannot be encrypted" is a discipline, not a one-time act; the second the drive came back online it joined the blast radius.

  4. Destroying the sample destroys your options. The AV cleanup erased the malware binary needed to identify the family and check No More Ransom. You cannot ask "is there a decryptor for this?" once you have deleted the evidence of what this is.

  5. Carving on an HDD was an unearned mercy. The partial recovery existed only because the server used hard drives and the family used copy-encrypt-delete. On an SSD, TRIM would have left nothing. The shop's survival rode on a hardware accident — exactly the kind of luck no professional plans around.

Discussion questions

  1. Rank the nephew's three actions — the reboot, the antivirus "Remove All," and the restore-onto-a-compromised-network — by the amount of damage each caused, and defend your ordering. Which one converted a recoverable incident into a near-total loss?

  2. This shop had a usable offline backup, putting it ahead of the accounting firm in the chapter's anchor case. Explain how it nonetheless ended up worse off, and what that says about the relative importance of having a backup versus handling the incident correctly.

  3. Write the decision gate that should have sat between "we found the truck drive" and "we restored it." What conditions must be true before a restore begins, and who signs off?

  4. The Friday re-encryption consumed the reconnected backup drive. State the backup rule this violated, and name the immutable-backup property from Case Study 1 that would have protected the copy even if it had been reachable.

  5. ⭐ The nephew acted in good faith and is the owner's family. As the professional brought in afterward, how do you document the first-hour mistakes in your report factually and without assigning blame — and why must the report record them at all, given the audiences (the cyber-insurer assessing the claim, the owner planning prevention, a possible subrogation dispute)? Cite the chapter that owns forensic report writing.