Case Study 2 — The Key Still in Memory

A small firm's files were turning to ransomware ciphertext in real time. One on-call technician, fighting every instinct to "just pull the plug," isolated the bleeding machine and captured its memory while the malware was still running. That single decision — capture RAM before the process exits — turned a likely six-figure data loss into a near-complete recovery without paying a cent. This is the recovery mirror image of Case Study 1: there, a power-off destroyed the evidence; here, not powering off saved the data.

Background

A nine-person architecture studio ran its entire practice — drawings, contracts, a decade of project files — off one Windows file server and a handful of workstations, backed up to a single external drive that someone was supposed to rotate weekly and, in practice, rotated about every two months. (This is the third anchor case of the book — the small business with no current backup — whose recovery is treated in full in Chapter 12.) At 4:50 p.m. a designer noticed files on a network share renaming themselves to a .locked extension and a README_RESTORE.txt appearing in every folder. The firm's managed service provider (MSP) got the call at 4:58.

Two things were happening at once when the MSP's on-call technician connected. On WS-03, the designer's workstation, the ransomware process was still actively running and encrypting — the share was mounted there, and the encryption was crawling through it folder by folder. On WS-05, across the studio, a panicked employee had already done the "obvious" thing: held the power button until the machine died, "to stop it."

The recovery

The technician had read this chapter. Instead of yanking WS-03's power — which would kill the running process and any secret it was holding — they made a deliberate, documented sequence of moves, racing the encryption rather than the clock to a power switch.

LIVE-RESPONSE LOG  —  Case 2026-0511-RW   Host: WS-03 (10.10.1.23)
Tech: A. Nwosu       Authority: MSP MSA §3 + owner verbal+SMS consent 17:01
Clock note: subject clock = trusted NTP + 1.4 s   (recorded 17:03:10Z)

UTC time   Action                                          Tool / source      Output (SHA-256)
17:02:30   Photographed screen (ransom note, .locked)      phone cam          IMG_2207.jpg / 5c1a...
17:03:10   Recorded system clock vs. trusted NTP           Get-Date / NTP     skew = +1.4 s
17:03:55   Isolated WS-03: disabled NIC + blocked at FW    MSP RMM            (encryption of SHARE halted)
17:05:20   Acquired physical memory, 32 GiB (proc RUNNING) winpmem 3.x        WS03-mem.raw / 2f8b...
17:31:40   Captured volatile state (proc/net/handles)      triage_logger.py   MANIFEST.csv / a004...
17:38:02   Identified ransomware proc + open handles       handle.exe         handles.txt / 6dd9...
17:44:15   KAPE triage (registry/evtx/$MFT/prefetch)       KapeTriage         WS03.vhdx / b71e...

The order is the whole story. The technician isolated the host first — disabling the network interface and blocking it at the firewall through the remote-management agent — which stopped the spread to the share without killing the local process. This is the chapter's containment-versus-preservation tension resolved correctly: pulling the power would have served containment but destroyed the in-memory key, while isolation served both. Then, with the malicious process still alive in memory, they captured RAM, hashing it on completion. They deliberately did not try to kill the process, "clean" the machine, or run an antivirus scan first — any of which could have caused the malware to wipe its own key buffers. Only after the volatile evidence was safe did they collect process and handle state and run a triage container, and only then did the question of whether to power down even arise.

The technician also resisted a tempting shortcut: deleting the .locked files or restarting the machine to "stop the damage." On a live system that is still encrypting, the calculus is counterintuitive — the running process is simultaneously the threat and the single best chance at the key. The right move was to freeze its blast radius (isolation) while keeping it alive just long enough to image, then preserve and walk away.

The payoff came the next morning, on copies, in daylight. The ransomware belonged to a family known to generate a per-victim symmetric AES key and hold it in memory while it worked. Because the memory image had been taken while the process was running, the key was still in it. Carving the image with bulk_extractor's AES key-schedule scanner — and corroborating with a Volatility scan of the process's heap — surfaced candidate keys:

$ bulk_extractor -E aes -o be_out WS03-mem.raw
$ head -2 be_out/aes_keys.txt
2417829120  AES256  9f2c4e... (round-key schedule consistent)
2417831936  AES256  1ab7d0... (round-key schedule consistent)

One of those keys decrypted a known-plaintext test file — the analyst encrypted a file of known content with each candidate key and compared, a standard validation step — and then decrypted the rest of WS-03's .locked files. Combined with the two-month-old backup, the firm recovered essentially everything: the recent project files from the in-memory key, the older material from the backup. They did not pay the ransom. The whole recovery, from the candidate-key list to a restored project folder, took a quiet morning at a workbench, on copies, with the original memory image untouched and hashed in the evidence locker — exactly the posture Case Study 1 lost by powering off.

WS-05 — the machine an employee had powered off "to help" — told the other half of the story. Its process was long dead; its RAM was gone; its key was unrecoverable. The files it had already encrypted before shutdown were restored only from the stale backup, and the few created in the last two months were lost for good.

The analysis

  1. A live ransomware process may be holding the key in RAM. Many families keep the per-victim symmetric key in memory while they encrypt. Capturing memory before the process exits has, in real cases, recovered keys that decrypt files no backup could restore. Power-off destroys that one path.

  2. Isolate, don't power off. Disabling the NIC and blocking at the firewall stopped the spread to the network share while keeping the local process — and its in-memory key — alive for capture. Containment and preservation were both served by refusing the reflex to pull the plug.

  3. Capture memory first, hash immediately. RAM was the prize and the most fragile artifact, so it came first, sealed with 2f8b… the moment it completed. Everything analytical happened later, on copies, in daylight — never on the bleeding host.

  4. It is a possibility, not a promise. Plenty of ransomware families purge keys aggressively, use asymmetric schemes that defeat memory recovery, or zero their buffers. Memory capture is a chance worth preserving, not a guarantee — and the real lesson the firm took away was the prevention one: a current, tested, offline backup would have made the whole drama a non-event.

  5. One memory image, two disciplines. The same WS03-mem.raw served the 💾 recovery goal (extract the key, restore the files) and the 🛡️ IR/forensic goal (prove what ran, when, and how it got in — the artifacts that feed Chapter 22 and Chapter 32). Captured once, soundly, it answered both can I get the data back? and can I prove what happened?

Discussion questions

  1. Compare WS-03 and WS-05 directly. Trace exactly which decision at which moment produced the different outcomes, and quantify what was won and lost on each machine.

  2. The technician isolated the host before capturing memory. Argue both sides: what did isolation-first protect, and what small risk did it introduce relative to capturing memory before any other action?

  3. ⭐ Recovering a key from memory worked here because of a specific property of this ransomware family. Describe two distinct key-management schemes a ransomware author could use that would make memory-key recovery fail, and explain what that implies about how much you should rely on this technique versus on backups. (Cross-reference Chapter 12.)

  4. How would you brief a small-business client, in plain language, on why "pull the plug to stop ransomware" is sometimes exactly the wrong move — without encouraging them to fiddle with a live infection themselves?

  5. The same memory image served recovery and forensics. If the firm later wanted to pursue the attacker (or file an insurance claim), what would you need to have done at capture time so that the image is admissible and useful for restoration? Tie your answer to chain of custody and hashing.