Case Study 1: After the Ransomware — Meridian's Post-Breach Investigation

"Containment told us the fire was out. Forensics had to tell us how it started, what burned, and whether anyone's house was still smoldering — and prove all of it." — Priya Nair, IR & Threat Hunting Lead, Meridian Regional Bank (constructed)

Executive Summary

The ransomware tabletop the Meridian team rehearsed in Chapter 24 stopped being a tabletop when, one April morning, the file server FS-01 began encrypting shares and a ransom note appeared. The incident- response lifecycle worked: detection, containment, and recovery brought operations back without the core- banking system ever being touched. But the moment containment finished, the investigation began — and its questions were harder than "is the fire out?" They were: How did the attacker get in? How long were they inside? What did they touch before the ransomware? Did any customer data leave? And can we prove the answer to a regulator and a cyber-insurer?

This case study follows the forensic investigation that answered those questions. It is told as a phased walkthrough — evidence preservation, acquisition, artifact analysis, timeline construction, scoping, and root cause — and it is where the chapter's vocabulary becomes a working method. The decisive findings: the attacker entered through a VPN account protected by a password alone, with no multi-factor authentication; they were resident for eleven days; they reached four hosts including a database server; and — provably, from preserved evidence — they did not exfiltrate the customer-PII database, which narrowed Meridian's breach-notification obligation from a catastrophe to a contained, defensible disclosure. The scenario, hosts, accounts, IPs, and all figures are constructed for teaching (Tier 3); IPs use documentation ranges.

Skills applied: order-of-volatility acquisition; write-blocker imaging and hash verification; chain of custody; Windows and Linux artifact analysis ($MFT, registry, event logs, Prefetch, auth.log); multi-source timeline construction; indicator scoping by pivoting; root-cause analysis; recognizing anti-forensics; translating forensic findings into a notification decision.

Background

Recall Meridian Regional Bank: ~1,800 employees, ~120 branches, a hybrid environment with an on-prem Windows Active Directory domain and VMware, plus AWS and Microsoft 365. The security team is small — CISO Dana Okafor, SOC Manager Marcus Reyes, IR/hunting lead Priya Nair, security engineer Sam Whitfield, GRC analyst Elena Vasquez, and junior SOC analyst Theo Brandt. After the Chapter 1 phishing near-miss, Dana won funding for a security-program maturation initiative; by this incident, Meridian had a SIEM (Chapter 21), detection use cases (Chapter 22), and an IR plan with a ransomware playbook (Chapter 24). What it had not yet formalized was forensic readiness — and this incident is what forces that final piece.

The environment at the time of the incident (the parts that matter):

The reason this matters: had Meridian rushed to rebuild FS-01 to restore the shares — the natural operational instinct — it would have destroyed the only on-host record of what the attacker did there, and the bank would have been forced to assume the worst about customer data. The investigation below is the alternative: preserve first, then recover from a copy.

The Investigation

Phase 1 — Preservation: winning the race before recovery

The IR playbook's first post-containment step, newly informed by forensic discipline, was explicit: preserve before you remediate. FS-01 had been isolated from the network during containment but left powered on — a deliberate choice, because the order of volatility (§25.2) says the most fragile and most valuable evidence of an active intrusion lives in memory, and powering off destroys it.

Priya made the live-versus-power-off decision the chapter describes. The ransomware's encryption had already completed (so there was nothing actively being destroyed to race against), and the machine was isolated (so it could do no further harm on the network). That combination favored capturing memory first, then imaging the disk:

FS-01 PRESERVATION SEQUENCE (constructed)
  1. Confirm host isolated (containment already done) — no further network harm.
  2. MEMORY CAPTURE first: trusted tool -> external drive.
        captured FS-01-mem.raw (volatile: processes, connections, injected code)
  3. Document live state (running processes, netstat) from the capture.
  4. Power down for disk imaging.
  5. Remove system disk; image through HARDWARE WRITE BLOCKER:
        /dev/sdb (read-only) -> FS-01-disk.img   (bit-for-bit)
  6. Hash source and image (SHA-256); confirm MATCH.
  7. Seal original disk; begin chain-of-custody record.

Theo handled the chain of custody (§25.3), and Priya was deliberate that he do it as the evidence was collected, not afterward from memory:

CHAIN-OF-CUSTODY — item E-2025-0417-01 (constructed)
  Item        : FS-01 system disk, Seagate S/N ABC123EXAMPLE
  Acquired by : T. Brandt   2025-04-17 15:20 UTC   (Meridian DC, rack B12)
  Write blocker: Tableau (S/N ...)    Hash(SHA-256): a1b2c3...EXAMPLE (illustrative)
  Handoffs    : scene->Brandt->evidence safe->Nair (analysis on IMAGE)->safe
  Rule applied: all analysis on FS-01-disk.img; original stays SEALED.

🛡️ Defender's Lens: Note what preservation bought that recovery alone would not: a frozen, hash-verified copy of FS-01 exactly as the attacker left it, plus its memory. Every later finding — the malicious service, the cleared log, the scope, the proof about customer data — comes from this preserved evidence. The team could now restore production from clean backups on a parallel track, with no pressure to disturb the evidence. Preservation and recovery stopped competing.

The decision to capture memory before powering off was not bureaucratic box-checking; it paid an immediate dividend the team would have forfeited the instant they hit the power switch. When Priya later analyzed FS-01-mem.raw, the RAM held things the disk did not and could not. A running process whose on-disk binary had already been deleted (the attacker had cleaned up after execution) was still resident in memory, with its full command line visible. An open network connection to an internal host — 10.20.0.55, the pivot machine — was live in the connection table at the moment of capture, pinning down where the attacker was operating from in a way no disk artifact could. And a fragment of the attacker's tooling that existed only in memory, never written to disk, gave Priya a string she could later search for fleet-wide. This is the order of volatility justifying itself: had the team "frozen" the machine by pulling power, every one of those findings would have evaporated, and the investigation would have been poorer for it. Memory is the most fragile evidence and, in an active intrusion, frequently the richest.

Phase 2 — Acquisition integrity: proving the copy is sound

Before analyzing anything, Priya verified the image with the integrity check at the center of the chapter (§25.2) — the operation encoded in forensics.py's evidence_hash:

INTEGRITY VERIFICATION (constructed; hashes illustrative)
  SHA-256(source /dev/sdb)        = a1b2c3...EXAMPLE
  SHA-256(image FS-01-disk.img)   = a1b2c3...EXAMPLE
  Compare ->  MATCH  ->  image is SOUND; analyze freely, original untouched ✓

The same verification was recorded for the memory capture and, later, for evidence pulled from DB-07 and the off-host SIEM exports. From this point on, the original disk was never touched again; every command Priya ran touched the image, and she kept contemporaneous notes of each — the repeatability principle (§25.3) that lets a second examiner reproduce the work.

⚠️ Common Pitfall (avoided): Early in the case, an eager systems administrator offered to "just grab the suspicious files off FS-01 and send them over" to save time. Priya declined: a file copy would miss deleted files and slack space (where the attacker's tools often hide), would alter timestamps, and would carry no integrity guarantee. The bit-for-bit image was slower but complete and sound — and in this case it preserved a deleted binary that a file copy would have missed entirely.

Phase 3 — Artifact analysis: reading what FS-01 recorded

With a sound image, Priya read the high-value Windows artifacts (§25.4). Each record is a fact; she assembled them deliberately, not jumping to conclusions:

FS-01 ARTIFACT FINDINGS (constructed, UTC)

  [Security.evtx]
  2025-04-15 02:14:07  4624  Logon type=3 (network)  Account=svc_backup  Source=10.20.0.55
  2025-04-15 02:15:31  7045  Service installed  Name="SysHelper"  ImagePath=C:\Windows\Temp\sh.exe
  2025-04-15 03:02:10  1102  "The audit log was cleared"  Account=svc_backup

  [$MFT]
  2025-04-15 02:15:02  C:\Windows\Temp\sh.exe   CREATED (Std-Info)
                       FileName-attribute CREATED = 2019-08-01  <-- TWO times disagree

  [Prefetch]
  SH.EXE-9F3A1B2C.pf   run count=3   last run=2025-04-15 02:16:44

  [Registry: SYSTEM hive]
  Service "SysHelper" persistence confirmed; also Run key entry for sh.exe (auto-start)

The analysis, stated as Priya wrote it in her notes:

• A backup service account did something a backup account should never do. svc_backup performed a network logon (type 3) at 02:14 — backup accounts run scheduled jobs, not interactive or ad-hoc network logons. That single anomaly is where the on-host story begins.
• A service was installed in a temp directory. Legitimate services do not live in C:\Windows\Temp. Event 7045 plus that path is a textbook persistence/lateral-movement indicator.
• The binary's timestamps were forged. The $MFT showed sh.exe created at 02:15 in one timestamp set but claiming a 2019 date in the other — timestomping (anti-forensics, §25.6). The discrepancy itself confirmed both when the file really arrived and the attacker's intent to hide it.
• The binary actually ran. Prefetch proved sh.exe executed three times — not merely present, but used.
• The attacker tried to erase the trail. At 03:02, svc_backup cleared the Security log (Event 1102). On a machine with only local logging, this would have been a wall. Meridian's SIEM had a forwarded copy of those events (forensic readiness, §25.6) — so the clearing became an indicator, not a dead end.

A note on how Priya read these artifacts, because the method matters as much as the findings. She did not start from a theory and look for confirmation — the fastest way to a wrong conclusion. She started from the artifacts and let them constrain the theory. The svc_backup network logon was the anomaly that opened the thread, but on its own it was only suspicious, not damning: maybe a misconfigured backup job. It was the combination — that account, installing a service, from a temp directory, with forged timestamps, that then ran, after which the log was cleared by the same account — that excluded the benign explanations one by one. Each artifact narrowed the space of what could have happened until only an intrusion remained. This is the discipline the chapter calls reading "each line is a fact; together they are a narrative": no single fact carried the conclusion, and Priya was careful in her notes to record which artifact supported which claim, so a second examiner — or a skeptical auditor — could follow the same chain of inference and reach the same place.

The timestamp discrepancy deserves a second look, because it is the kind of detail that separates a careful examiner from a hurried one. A hurried analyst, seeing the $MFT's Standard-Information time of 02:15, records "file created 02:15" and moves on. Priya noticed that the second timestamp set — the FileName attribute — claimed 2019, and knew that those two should normally agree. The disagreement was not noise; it was the signature of timestomping, and it told her two things at once: that 02:15 was the real creation time (the FileName attribute is harder for common tools to forge, so it is often the more trustworthy of the two), and that the attacker had deliberately tried to age the file to make it blend in with legitimate system files. An anti-forensic act, attempted, had instead become an indicator — both of when the tool really arrived and of the attacker's intent to hide. The lesson the chapter states in the abstract was concrete here: anti-forensics is rarely perfect, and its imperfections are evidence.

🔗 Connection: Every one of these artifacts is also a detection Meridian should have alerted on in real time (Chapters 21–22): a backup account's network logon, a service installed in a temp path, a log clear. Forensics and detection are the same data read at different times. The investigation became a finding for the detection program: these artifacts must become live alerts, so the next intrusion is caught at 02:15, not reconstructed after the ransomware.

Phase 4 — Timeline: merging on-host and off-host evidence

A list of artifacts is not yet a narrative. Priya merged FS-01's artifacts with two off-host sources — the SIEM-forwarded events and the VPN concentrator's logs — into a single UTC-sorted timeline (§25.5), the operation merge_timeline performs. The off-host VPN log proved decisive:

UNIFIED TIMELINE — Meridian ransomware (constructed, UTC, source-tagged)
┌──────────────────┬─────────┬──────────────────────────────────────────────┐
│ Time (UTC)       │ Source  │ Event                                         │
├──────────────────┼─────────┼──────────────────────────────────────────────┤
│ 2025-04-04 23:40 │ VPN     │ VPN connect — user=jlopez  src=203.0.113.9    │ ← INITIAL ACCESS
│ 2025-04-04 23:52 │ WinEvt  │ Network logon svc_backup (from jlopez host)   │   (pivot to svc acct)
│ 2025-04-05 00:10 │ MFT     │ recon tools staged on FS-01                   │
│ ...  (11 days of low-and-slow activity) ...                                │
│ 2025-04-15 02:14 │ WinEvt  │ Network logon svc_backup                      │
│ 2025-04-15 02:15 │ MFT     │ C:\Windows\Temp\sh.exe created (timestomped)  │
│ 2025-04-15 02:15 │ WinEvt  │ Service "SysHelper" installed -> sh.exe       │   (persistence)
│ 2025-04-15 02:16 │ Prefetch│ sh.exe executed (x3)                          │
│ 2025-04-15 02:55 │ EDR     │ mass file encryption begins on FS-01          │   IMPACT (ransomware)
│ 2025-04-15 03:02 │ WinEvt  │ audit log cleared (svc_backup)                │   (anti-forensics)
└──────────────────┴─────────┴──────────────────────────────────────────────┘

Two facts emerged only from the merge. First, the true initial access was 2025-04-04 — eleven days before the ransomware — via a VPN login by jlopez. The on-host artifacts alone, especially after the 03:02 log clear, would have suggested a much later start; the off-host VPN log, which the attacker never reached, reset the clock to its real beginning. Second, the dwell time was eleven days of quiet activity before impact, which immediately raised the stakes of scoping: an attacker with eleven days inside has time to spread.

⚠️ Common Pitfall (illustrated): Theo's first draft timeline used only the FS-01 Security log and placed initial access at 02:14 on April 15. Priya caught it: "That's the cleared log talking. What does the VPN say?" Adding the off-host source moved the real start back eleven days. Never let a source the attacker could reach define the boundaries of your timeline — weight off-host, append-only sources most heavily.

Phase 5 — Scoping: how far did it go, and the question that mattered most

Now the central question: was FS-01 the whole incident, or the part they happened to see? Priya scoped by pivoting on indicators (§25.6), each confirmed indicator becoming the next search:

SCOPING PIVOTS (constructed)
  1. Pivot on file hash SHA-256(sh.exe)=a1b2c3...EXAMPLE across the fleet (EDR/SIEM)
        -> found on WS-14, WS-22, and DB-07     (scope widens from 1 to 4 hosts)
  2. Pivot on account svc_backup — where did it log on?
        -> WS-14, WS-22, FS-01, DB-07; first abused right after jlopez's VPN login
  3. Pivot on jlopez VPN source IP 203.0.113.9
        -> single external IP, all sessions outside business hours
        -> jlopez confirms: never connected from there; credential was stolen
  CONVERGENCE -> ROOT CAUSE: stolen jlopez VPN credential; VPN had NO MFA.
  FULL SCOPE: FS-01, WS-14, WS-22, DB-07 + accounts svc_backup, jlopez(VPN)

The pivot to DB-07 — the Linux database server holding customer PII — was the finding that mattered most to the business, because it determined whether this was a disruption or a data breach. Priya preserved and analyzed DB-07's evidence with the same discipline (its own image, hash, custody record), reading the Linux artifacts (§25.4):

DB-07 ARTIFACT FINDINGS (constructed, UTC)
  [/var/log/auth.log]
    Apr 15 02:30  sshd: Accepted publickey for svc_backup from 10.20.0.55
    Apr 15 02:33  sudo: svc_backup : COMMAND=/bin/ls /var/lib/db/exports
  [~/.bash_history for svc_backup]  -> truncated (suspicious)
  [filesystem timestamps via stat on the PII export directory]
    PII export files: ATIME unchanged since last legitimate backup (Apr 12)
    No new large files created; no archive (.tar/.zip) of PII staged
  [NetFlow to DB-07 / from DB-07 (off-host network sensor)]
    Inbound from attacker-controlled hosts: yes (the ls/recon)
    Large OUTBOUND transfer of DB-07 data to any external/staging host: NONE

The conclusion was carefully bounded, exactly as forensic honesty demands: the attacker reached DB-07 and listed the PII export directory (reconnaissance), but the evidence showed no access to the contents and no exfiltration — the file access times were unchanged, no archive of the data was staged, and the off-host NetFlow recorded no large outbound transfer of database data. The attacker looked at the door of the customer-data room and never opened it before being detected and contained.

It is worth dwelling on why this negative finding was so much harder to earn than a positive one would have been, because it is one of the chapter's most important and least intuitive points. To prove the attacker did take data, Priya would need a single piece of positive evidence: an archive staged, a large outbound transfer, an access timestamp on the PII files matching the intrusion window. Any one of those would settle it. To prove the attacker did not take data — the far more valuable conclusion for the bank — she had to demonstrate the absence of all of those signs and establish that she had looked everywhere they would appear. A single un-checked channel would leave the conclusion open. So she enumerated the ways data could have left DB-07 and confirmed each was silent: the filesystem access times on the export directory's contents were unchanged since the last legitimate backup on April 12 (the attacker's ls touched the directory listing but not the files within); no compression tool ran and no archive was staged on the host; and — the corroboration that made it defensible — the off-host NetFlow sensor, which the attacker never knew about and could not have scrubbed, recorded no large outbound flow of database data to any external or staging host during the entire eleven-day window. Three independent lines of evidence, one of them beyond the attacker's reach, all pointing the same way. That is what a defensible negative looks like, and it is why it takes more work than a positive.

Had any one of those checks been impossible — had Meridian not deployed the NetFlow sensor, or had the filesystem been mounted with access-time updates disabled and no other corroboration available — the honest conclusion would have flipped. Priya was explicit in her report about this conditional: the finding of "no exfiltration" was contingent on the specific evidence she could examine, and she named that evidence. A finding that cannot say what it depends on is not a finding; it is a hope. This precision is exactly what let counsel rely on it.

🔗 Connection: This is the seam between forensics and governance. The factual finding — PII directory was enumerated but not accessed or exfiltrated, corroborated by file-access times and independent off-host NetFlow — is what Elena (GRC) and legal counsel needed to scope Meridian's obligations under the GLBA Safeguards Rule and state breach-notification laws. Forensics produced the facts; governance made the notification decision. Without the preserved evidence, the only defensible position would have been to assume exfiltration and notify maximally.

Phase 6 — Root cause and the anti-forensics ledger

Walking the scope chain to its origin delivered the root-cause analysis (§25.6):

• Proximate cause: ransomware executed on FS-01.
• Root cause: the bank's VPN accepted a password alone — no multi-factor authentication — so a single stolen credential (jlopez) gave an external attacker direct internal access, from which they pivoted to a service account and spread.
• Fix at the root-cause level: require phishing-resistant MFA on the VPN (and re-examine every remote-access and service-account path) — the authentication discipline of Chapter 16, and the very class of control that saved Meridian from the Chapter 1 phishing attempt. Rebuilding FS-01 fixes nothing; closing the VPN gap closes the actual hole.

Priya also catalogued the attacker's anti-forensics and how each was defeated — a ledger that became a forensic-readiness argument:

ANTI-FORENSICS LEDGER (constructed)
  Technique               Defeated by
  ----------------------  -----------------------------------------------------
  Cleared Security log    SIEM-forwarded copy (off-host, append-only) — and the
   (Event 1102)            1102 event itself, an indicator of intent.
  Timestomped sh.exe      $MFT's TWO timestamp sets disagreeing — exposed the forgery.
  Truncated bash_history  The absence on an active account is itself evidence;
   on DB-07                auth.log + NetFlow reconstructed the session anyway.
  Service in Temp dir     Anomaly itself; Prefetch proved execution despite hiding.

📟 War Story echo: The single decision that made this entire investigation possible was made months earlier and had nothing to do with the incident: configuring the SIEM to receive forwarded Windows events and deploying off-host NetFlow sensors. The attacker cleared the local log confidently — and the forwarded copy made the clearing irrelevant. Forensics was won before the incident, in the logging architecture, exactly as §25.6 argues.

Discussion Questions

1. Priya left FS-01 powered on and captured memory before imaging the disk, but the ransomware encryption had already finished. Construct a scenario in which she would have been right to power off immediately instead, and state precisely what evidence that trade sacrifices.
2. The investigation's most consequential single finding was negative — that customer PII was not exfiltrated. Why is a defensible negative finding often harder to produce, and more valuable, than a positive one? What evidence made it defensible here?
3. The dwell time was eleven days, but on-host artifacts (after the log clear) suggested a much shorter intrusion. Explain how this gap could have led to under-scoping, and which sources prevented it.
4. Where in this investigation did honesty about uncertainty matter? Identify a place where the team bounded its claim ("reached but did not access") rather than overstating, and why that discipline protects the bank.
5. The root cause was a VPN without MFA — a known control gap. Should the investigation assign that to a failure of risk management (Chapter 1's risk register), of identity (Chapter 16), or of governance? Is "root cause" always a single thing?

Your Turn

Take a constructed intrusion of your own design (or extend Meridian's): one entry point, one pivot account, three affected hosts, and one sensitive data store. Produce, on one page: (1) a preservation sequence respecting the order of volatility; (2) a chain-of-custody line for the primary evidence item; (3) a five-to-eight-row unified timeline merged from at least one on-host and one off-host source, with the initial-access row identified; (4) a scoping pivot chain converging on a root cause; and (5) a one-sentence, bounded conclusion about whether sensitive data was exposed, naming the evidence that supports it. If you cannot support a claim with a named artifact, mark it "unknown — would require X" — that honesty is the skill.

Key Takeaways

• Preserve before you remediate. The order of volatility (memory before disk) and a write-blocked, hash-verified image let recovery and forensics proceed in parallel instead of competing — and preserve evidence (deleted binaries, slack space) a file copy would destroy.
• Off-host evidence is the lifeline. The attacker cleared the local log and timestomped a binary; the SIEM-forwarded events, off-host NetFlow, and the $MFT's dual timestamps defeated each anti-forensic act. The forwarded copy, configured months earlier, is what made the case.
• The timeline must merge independent sources. The true initial access (eleven days earlier) came only from the off-host VPN log; trusting the cleared on-host log would have understated the intrusion and risked under-scoping.
• Scoping answers the question the business actually has. Pivoting on indicators (hash → account → credential → entry IP) revealed the full four-host footprint and reached the PII database — and the negative finding (enumerated but not exfiltrated), corroborated by file-access times and NetFlow, narrowed the breach-notification obligation defensibly.
• Root cause drives the only fix that matters. The proximate event (ransomware on FS-01) was a symptom; the root cause (VPN without MFA) is the gap whose fix prevents recurrence — connecting straight back to authentication (Chapter 16). An investigation that stops at cleanup buys the incident's cost without its lesson.
• Forensic findings feed the program. Root cause updates the risk register, scoping drives notification, and the artifacts that should have alerted in real time become new detection use cases and a forensic-readiness standard.