Case Study 1 — The Extension That Named the Ransom

A six-person accounting firm woke to every working file renamed with a four-character extension and a ransom note in each folder. There was no current backup and a five-figure demand. What saved the quarter was not a payment — it was twenty minutes of malware forensics that identified the family, because the family it turned out to be had a flaw an entire research community had already turned into a free decryptor.

Background

The firm — call it the client — ran QuickBooks files, client tax returns, and a decade of correspondence off one Windows workstation that doubled as a "server," with an external drive that was supposed to be rotated weekly and was, in practice, last connected eleven weeks earlier. On a Monday a bookkeeper found documents would not open; each filename had grown a .kkll-style four-letter suffix, and every folder held a _readme.txt demanding payment in cryptocurrency, with a "discount" if they paid within 72 hours. This is the same shape as the book's third anchor case — the small business with no current backup — whose recovery is treated in full in Chapter 12 — Ransomware Recovery. The firm's IT contractor had already done the most important thing right: he had isolated the machine and not paid, and he sent the dropper he found in %LOCALAPPDATA% to an examiner before touching anything else.

The examiner's instinct was the chapter's first principle. The sample was a live weapon; it went onto an isolated FLARE-VM, on a working copy, hashed and chain-of-custody'd against the original the contractor had preserved. The temptation in a ransomware job is to skip straight to "can we decrypt?" The discipline is to analyze first, because the analysis is what tells you whether decryption is even possible.

The investigation

Static triage moved fast, and most of the answer came from the cheapest steps. file confirmed a 32-bit PE. The hash, looked up — not uploaded; even a "commodity" ransomware case gets hash-only treatment by default — came back as a known sample family across dozens of engines, all assigning variants of one name: the STOP/Djvu lineage, by volume the most prolific ransomware family in the world, the one that overwhelmingly targets exactly this kind of small, under-backed shop.

strings and the import table filled in the behavior. The sample reached out before encrypting:

STRINGS (dropper) — the lines that decided the case
  https://api.<redacted>.<tld>/<path>      <- "get the online key" callback
  \_readme.txt                              <- ransom-note template name
  PersonalID:                               <- victim ID written into the note
  Global\<guid-style-mutex>                 <- single-instance mutex (Djvu signature)
  .kkll                                     <- the appended extension
  SystemID/PersonalID/                      <- key-management path

The crucial finding was how the family manages keys. STOP/Djvu tries to contact its server to fetch a unique online key per victim; if it cannot — no network, server down, isolated at the wrong moment — it falls back to a hardcoded offline key shared across many victims of that build. That fallback is the flaw. Because Emsisoft and the No More Ransom project have recovered offline keys for many Djvu builds, files encrypted with an offline key are decryptable for free; files encrypted with a per-victim online key are not. The entire recovery now hinged on a single question the analysis could answer: did this infection use the online key or the offline key?

DECRYPTABILITY DECISION (STOP/Djvu)
  online key  (unique, server-issued)  -> NOT decryptable (no flaw to exploit)
  offline key (hardcoded fallback)     -> decryptable IF the key is in the
                                          Emsisoft / No More Ransom database
  Tell: offline-key victims share an identical "PersonalID" suffix ("...t1")
        and produce byte-identical key material across machines

The _readme.txt PersonalID carried the suffix associated with offline encryption, and a spot check of two encrypted files against Emsisoft's STOP/Djvu decryptor confirmed it: the offline key for this build was in the database. The decryptor restored the .kkll files on a copy of the data, validated against a handful of known-good originals the bookkeeper could still recognize. Combined with the eleven-week-old backup for the oldest material, the firm recovered essentially everything without paying.

Recovery vs. Forensics. This is the chapter's signature lens at its most concrete. The 💾 recovery reader needed exactly one deliverable from the analysis — family attribution — because it answered the only question that mattered: does a free decryptor exist? The 🔍 forensic examiner read the same sample for a different deliverable. STOP/Djvu builds frequently drop a second-stage information stealer (harvesting browser credentials, crypto wallets, and documents) before encrypting — which the examiner confirmed from the dropper's staged download and a temp-directory archive. That finding turned a "we got our files back" recovery into a data-breach with notification obligations: client tax data may have been exfiltrated, which counsel had to assess under state breach law. One binary, two jobs — the recovery technician got the decryptor, the examiner got the breach scope.

Limitation. The happy ending was a property of this family, not a property of ransomware. The book's anchor ransomware case in Chapter 12 — the small business whose files carried the .eking extension of the Phobos lineage — had no such gift: Phobos uses sound per-victim key handling, no free decryptor exists, and that recovery came down to shadow copies, slack, and a stale backup. Family attribution is the deliverable either way; sometimes it tells you "download the free decryptor," and sometimes it tells you, honestly, "this is unrecoverable without the key — restore from backup or accept the loss." Knowing which is itself the value.

The analysis

1. Family attribution is the highest-leverage deliverable in ransomware forensics. Identifying the lineage from the note template, the appended extension, the mutex, and the key-management routine answered the recovery reader's first question — does a decryptor exist? — before anyone discussed paying. The analysis paid for itself in the first twenty minutes.

2. The recovery hinged on a key-management flaw, not on cracking encryption. Nothing here broke AES. The offline-key fallback meant many victims shared key material that researchers had already recovered. Reading how the malware handles keys — online versus offline — is what separated "free restore" from "unrecoverable," and only analysis surfaced it.

3. Analyze before you try to decrypt. The instinct to run a decryptor first wastes the one chance to characterize the sample cleanly and can miss the second-stage stealer entirely. Static triage on a working copy, hashed against the original, cost minutes and produced both the recovery answer and the breach finding.

4. Ransomware is increasingly a data breach, not just an outage. The bundled information-stealer meant client data was likely exfiltrated before encryption — an obligation the firm would never have known about if the examiner had stopped at "the files are back." The forensic read of the same weapon protected the firm legally as well as operationally.

5. The real lesson was prevention. A current, tested, offline backup would have made the whole episode a Tuesday-morning restore. The firm was rescued by a flaw in this particular family and a community decryptor — neither of which is a backup strategy. The examiner's report said so plainly, because theme six (the human cost is real) includes telling a small client the truth about how close they came.

Discussion questions

1. Walk through the static-triage steps the examiner used to attribute the family, in order, and state which single finding (note template, extension, mutex, or key-management routine) you would weight most heavily and why.

2. Explain, to a non-technical business owner, why "the analysis said it used an offline key" was the difference between a free recovery and a five-figure ransom — without implying that encryption was "cracked."

3. ⭐ The same sample carried an information-stealer that ran before encryption. Lay out the breach-notification questions this raises (what data, whose, exfiltrated when) and how you would prove or bound exfiltration from the malware analysis plus the network artifacts. Where does the legal duty get decided, and which chapters own that? (See Chapter 25 and Chapter 28.)

4. Contrast this outcome with the .eking/Phobos case from Chapter 12. What about Phobos's key handling removes the option that saved this firm, and how would you frame the "this is unrecoverable" finding to a client without it sounding like you simply failed?

5. The IT contractor isolated the host and preserved the dropper before calling the examiner. Identify two further things he did right and one thing that, had he done it (e.g., paid quickly, or "cleaned" the machine with an AV scan first), would have destroyed the path to free recovery.