Case Study 1 — The Logs That Outlived the Disks

A small manufacturer with no current backup is hit by ransomware, and recovery is partial at best. But the network logs lived on a box the malware never reached — and they proved something the encrypted, wiped disks never could: that gigabytes of data had been stolen days before anything was locked.

Background

Meridian Tool & Die runs about eighty people and a shop floor full of CNC machines off a modest IT footprint: two Windows file servers, a backup NAS, a domain controller, and a perimeter firewall. There is no current offsite backup — the nightly job to a second NAS had been failing silently for months, the classic precondition of this book's ransomware anchor (Chapter 12 — Ransomware Recovery). On a Friday night the file servers and the backup NAS are encrypted, shadow copies deleted, and a ransom note left on every share demanding payment in cryptocurrency — and, ominously, threatening to publish the company's data if the firm does not pay. That last line is the modern "double extortion" play: the operators claim to have taken the data, not merely locked it.

You are retained for incident response. Recovery, you tell the owner honestly up front, will be partial: without backups you can hope for an old external drive and whatever carving recovers, nothing more (theme #5, know your limitations). But there is a second, equally urgent question that recovery cannot touch and that the publish-or-pay threat makes existential: did data actually leave the building, and if so, what and how much? If customer and employee personal data was exfiltrated, the firm has breach-notification obligations regardless of whether it pays (Chapter 25 — The Legal Framework). The disks cannot answer this: the staging files were deleted by the attacker and the volumes are now encrypted. The answer, if it exists anywhere, is on the network.

The investigation

Meridian's one piece of luck is unglamorous. A previous consultant had stood up a bare-bones network-security-monitoring setup: a Zeek sensor on a switch SPAN port writing conn.log, dns.log, and ssl.log to a small Linux box in the corner, the firewall exporting NetFlow to that same box, and the internal DNS resolver logging queries. The ransomware encrypted Windows servers and the NAS; it never touched the Linux log collector. The infrastructure kept records on the firm's behalf that the attacker had no path to reach — the chapter's central lesson made literal.

You acquire the log box the right way (image and hash before you touch anything, per Chapter 15 — Live Response and Triage) and start where retention is longest, with metadata, to find events in time.

The DNS log narrates the intrusion's beginning. One workstation — 10.10.2.37, an estimator's PC — had been resolving a single low-reputation domain on a metronome:

dns.log (excerpt) — 10.10.2.37, one domain, every ~300 s, for 9 days
beacon analysis: events 2,571   mean interval 300.2 s   cv 0.011
  → near-zero variance over thousands of queries = a machine on a timer, not a human

A coefficient of variation of 0.011 across more than two thousand queries is not browsing; it is a command-and-control beacon (the malware C2 heartbeat). It runs for nine days before the encryption event — the dwell time during which the operators were inside, exploring, and staging. Had anyone reviewed this log even once that week, the foothold would have surfaced long before the trigger was pulled.

Now the decisive question — exfiltration. You pivot to conn.log and the flow records for the two nights before encryption, hunting the asymmetry that means upload:

conn.log (excerpt) — off-hours, internal server -> external hosting-provider IP
ts             id.orig_h    id.resp_h        id.resp_p  service  duration  orig_bytes      resp_bytes  conn_state  history
...02:41 Wed   10.10.2.11   185.x.x.x        443        ssl      6h12m     41,203,884,544  402,118     SF          ShADadDfF...
                ^FILE-SRV-1  ^bulletproof host          ^TLS               ^~38 GiB OUT    ^~390 KB in ^clean      ^orig pushed bulk

A file server sent roughly 38 GiB and received under 400 KB, in a single clean TLS session running six hours in the dead of night, to an IP in a hosting range with no business relationship to Meridian. The orig_bytes ≫ resp_bytes ratio (over 100,000-to-1) is the screaming signature of bulk upload, not browsing. ssl.log, joined by the same connection uid, gives the SNI and certificate for the destination; dns.log shows the server resolved that host minutes earlier; the firewall's NetFlow corroborates the volume independently. Four sources agree, and none of them lives on a disk the attacker could encrypt or a workstation he could wipe.

MERIDIAN — RECONSTRUCTED FROM NETWORK LOGS (UTC)
9 days prior  C2 beacon begins from 10.10.2.37 (cv 0.011, 300 s)  [dns.log]
Wed 02:41     FILE-SRV-1 -> 185.x.x.x:443, ~38 GiB out, 6h12m, SF  [conn.log + flow]
Wed 02:41     same uid: SNI + cert for the hosting host            [ssl.log]
Wed 08:53     beacon and outbound sessions cease                   [dns.log/conn.log]
Fri 23:18     encryption event; shadow copies deleted; ransom note [DISK, Ch.12]
              — the staging files were deleted from FILE-SRV-1, and
                the volume is now encrypted; the NETWORK is the only
                witness that 38 GiB ever left.                     [theme #3]

You characterize the finding precisely and to its limits. The TLS payload was encrypted and you have no session keys, so you cannot, from the wire alone, prove which files were in the 38 GiB. But you can prove that ~38 GiB left a specific internal file server to an external host two nights before the encryption — and a directory-listing of that server's data set, cross-checked against the volume that moved, makes the inference that personal data was among it well supported. That distinction — an encrypted transfer of N bytes occurred to destination D at time T, with content characterized by inference rather than asserted as fact — is the honest finding, and it is enough to drive the firm's decisions. Counsel, armed with proof that data was exfiltrated, treats the incident as a reportable breach and notifies affected individuals; the negotiation posture toward the ransom actors changes once the firm knows exactly what the "we will publish" threat actually covers; and the malware C2 domain and the beacon interval feed the deeper endpoint analysis in Chapter 32 — Malware Forensics. Recovery of the files remains partial and painful. But the forensic question — did data leave, what scope — was answered with confidence, by the only evidence source the attack could not reach.

The analysis

  1. The network is often the only witness to the exfiltration half of double extortion. Modern ransomware steals before it locks, and the staging files are deleted from disk while the volume is encrypted. Flow and Zeek logs, kept off the affected hosts, can prove the theft when the endpoints cannot — which is exactly why this is a network chapter's case even though it begins as a recovery disaster.
  2. Beaconing is a dwell-time alarm you can quantify. A coefficient of variation near zero over thousands of queries is a machine on a timer, not a person. The nine-day beacon was a standing invitation to catch the intrusion early; the lesson is prevention as much as investigation.
  3. orig_bytes ≫ resp_bytes is the upload fingerprint. A server that sends 38 GiB and receives 390 KB is exfiltrating, not browsing. The direction of the asymmetry, read straight off conn.log, distinguishes the two without ever decrypting a byte.
  4. Corroboration across independent, attacker-unreachable sources is what makes the finding hold. DNS, conn.log, ssl.log, and NetFlow agreed, and all four lived on a collector the ransomware never touched. One source is a lead; four that agree, on infrastructure the adversary could not edit, is a finding.
  5. State content to its limit — and it is still decisive. Encryption meant you could not name the files inside the 38 GiB, so you reported a transfer of that volume to that destination at that time and let the breach-notification decision rest on a well-labeled inference. Refusing to overclaim did not weaken the case; it made it survivable.

Discussion questions

  1. The recovery effort was a partial failure (no backups) while the forensic effort succeeded. Explain how a single incident can be both, and why the network evidence belonged to the forensic side of the ledger even though the engagement started as ransomware recovery.
  2. The nine-day C2 beacon was sitting in dns.log the whole time. Propose a simple, low-cost monitoring practice that would have surfaced it during the dwell window, and explain what makes beaconing one of the most reliably detectable malicious patterns.
  3. You proved ~38 GiB left FILE-SRV-1 but could not read the encrypted payload. Write the one-sentence finding you would put in the report, and the one-sentence inference about the data's nature — keeping them rigorously separate, the way Chapter 26 — The Forensic Report requires.
  4. ⭐ Suppose Meridian's flow had been sampled (sFlow at 1-in-1000) and the Zeek box had only 48 hours of retention. Walk through how each limitation would have degraded this investigation, what you could still have claimed, and the honest finding you would write if the exfiltration window had aged out before you arrived.
  5. The destination was a generic hosting-provider IP with no threat-intelligence flag, and the data could just as easily have gone to a sanctioned cloud service. Why is "the destination looked legitimate" not evidence of innocence — and how does that caution connect to the way sophisticated exfiltration deliberately blends into allow-listed traffic?