Case Study 2: 200 Gigabytes That Looked Like Backups — An Exfiltration Hunt at a Tech Company

"The data didn't leave in one alarming burst. It left as 'normal,' a little at a time, to a place we'd told ourselves was fine." — Incident lead, Lumen Forge (constructed)

Executive Summary

To see network monitoring from a different angle, leave the bank for a software company. Lumen Forge is a ~600-person SaaS firm whose crown jewels are not customer card numbers but source code and a proprietary machine-learning model — the intellectual property the whole business is built on. This case study is a data-exfiltration hunt: not the timing-driven beacon hunt of Case Study 1, but a volume-and-channel investigation into whether sensitive data has been quietly leaving the network. It is also a story about a visibility gap — Lumen Forge had decent perimeter logging and no internal network monitoring, and the gap nearly let a slow, blended exfiltration succeed. You will watch the team baseline outbound traffic per host and destination, distinguish a real anomaly from the noise of a busy engineering network, chase data that left through two different channels (bulk HTTPS to a cloud bucket and a trickle through DNS), and then redesign their monitoring so the next attempt is visible on day one. Where Case Study 1 was detection-and-analysis, this one is detection-and-design: the lesson is as much about where the sensors should have been as about catching the theft. All details are constructed for teaching (Tier 3).

Skills applied: per-host/per-destination outbound baselining; exfiltration detection by volume anomaly and by cumulative "low-and-slow" totals; identifying DNS tunneling in Zeek dns.log; reasoning about blended exfiltration to legitimate cloud services; diagnosing a sensor-placement/coverage gap; designing a network-visibility layer to close it; the limits of network telemetry without endpoint and identity correlation.

Background

Lumen Forge runs lean and cloud-heavy. Its engineers push code all day to cloud repositories and CI systems; its application servers stream telemetry to a cloud-storage provider; its data scientists move large datasets and model artifacts around routinely. Outbound traffic to cloud providers is not just normal here — it is the dominant traffic pattern, which is precisely what makes exfiltration hard to spot. At a bank, a server suddenly talking to cloud storage might be alarming; at Lumen Forge, everything talks to cloud storage, all the time, in large volumes. The "obvious" exfiltration signature — bulk outbound to a cloud bucket — is camouflaged by being the company's own background noise.

Lumen Forge's monitoring reflected a common small-company posture: a next-generation firewall at the internet edge with reasonably good egress logging, endpoint protection on laptops, and no network security monitoring inside the network at all — no Zeek, no internal flow collection, no east-west visibility. Management had reasoned, not unreasonably, that "we're cloud-first, so the perimeter is where the action is." The hunt will show why that reasoning, while half right, left a dangerous gap.

The trigger was mundane: a routine cloud-bill review flagged that egress data-transfer charges had crept up ~15% over two months with no corresponding growth in customers or features. A finance analyst asked security a deceptively simple question — "what is sending more data out, and is it supposed to?" That question is an exfiltration hunt in disguise.

🔗 Connection: Lumen Forge's crown jewels invert the bank's CIA emphasis from Chapter 1. For Meridian, customer data is primarily a confidentiality problem and the ledger an integrity one. For Lumen Forge, the source code and ML model are almost purely a confidentiality asset — their value is in their secrecy, and the worst case is theft, not alteration or downtime. The hunt is therefore tuned to outbound data movement, the network signature of a confidentiality breach, exactly as §10.5 describes.

The Hunt

Phase 1 — Building an outbound baseline from what little they had

With no internal flow collector, the team's only network data was the firewall's egress logs — which, fortunately, record per-connection source, destination, port, and byte counts: effectively coarse flow data for north-south traffic. It would not show east-west movement (a gap they will fix), but for an exfiltration question — what is leaving, and where to — north-south egress is exactly the right view.

The first move, straight from §10.4, is a baseline: for each internal host, how much does it normally send outbound, and to which destinations? The team summarized two months of egress logs with the summarize_flows logic — aggregating bytes per (source, destination) — and built a per-host profile of "normal outbound." This is the unglamorous prerequisite the chapter insists on: without knowing each host's normal, every large transfer on a network where large transfers are routine looks the same.

⚠️ Common Pitfall: Baselining globally on a network like this. If you only ask "is total outbound to cloud storage unusual?", the answer is always "no" — the company sends enormous volumes there by design, and the attacker's traffic hides in the aggregate. The chapter's fix (§10.5) is to baseline per host and per destination: a single engineering workstation sending 200 GB to a cloud bucket is wildly anomalous for that host even though the company as a whole sends petabytes to cloud storage. Slice the baseline finely enough that the attacker cannot hide in a sum.

Phase 2 — Finding the volume anomaly

Ranking hosts by deviation from their own outbound baseline (rather than by raw volume) immediately surfaced an outlier:

host             baseline_out/day   recent_out/day   ratio    top destination
──────────────────────────────────────────────────────────────────────────────
ws-eng-114       ~1.2 GB            ~9 GB            ~7.5x    bucket: 198.51.100.40 (cloud)
build-07         ~40 GB             ~41 GB           ~1.0x    cloud CI (expected)
ds-train-02      ~25 GB             ~26 GB           ~1.0x    cloud datasets (expected)
ws-eng-088       ~1.0 GB            ~1.1 GB          ~1.1x    cloud repos (expected)

Figure CS2.1 — Hosts ranked by outbound deviation from their own baseline. The CI and data-science hosts move far more absolute data than ws-eng-114, but they are moving their normal amount — ratio ~1.0. ws-eng-114, an ordinary engineering workstation, is sending ~7.5× its baseline, to a cloud bucket that is not one of its usual destinations. Ranking by ratio to baseline, not raw bytes, is what makes the anomaly visible on a network where huge transfers are routine.

This is the heart of the exfiltration-detection idea and the reason Figure CS2.1 ranks by ratio, not absolute bytes. build-07 moves 41 GB a day and is boring; ws-eng-114 moves 9 GB a day and is alarming — because 41 GB is normal for build-07 and 9 GB is seven times normal for ws-eng-114. The team pulled ws-eng-114's history and found the elevated outbound had been climbing for about three weeks, much of it overnight, to a single cloud bucket IP (198.51.100.40) that did not belong to any Lumen Forge account. The cumulative total to that destination over three weeks was roughly 200 GB — and critically, no single day exceeded the company's informal "investigate transfers over 50 GB/day" threshold, because the attacker had spread it out. This is low-and-slow exfiltration: stay under the per-interval alarm by trickling, and rely on the volume being lost in a busy network's noise.

🛡️ Defender's Lens: Low-and-slow defeats per-interval thresholds ("alert on >50 GB/day") but not cumulative, per-destination baselining ("this host has now sent 200 GB total to one non-standard destination over three weeks"). The general principle from §10.5: any single threshold an attacker knows about, they will stay just under. Robust exfiltration detection therefore watches cumulative totals to a destination over a long window, and compares each host to its own history — both of which require retained flow/egress data, the recurring reason this chapter cares so much about retention.

A reasonable objection arises here, and the team had to answer it before escalating: Lumen Forge uses cloud storage constantly — how do we know 198.51.100.40 is the attacker's bucket and not just a new, legitimate one an engineer started using? This is the exfiltration equivalent of Case Study 1's benign-explanation gauntlet, and it is answered the same way — by converging context, not a single fact. The destination did not match any cloud-storage endpoint in Lumen Forge's own accounts (the company knew its own bucket addresses); the transfers ran overnight, when ws-eng-114's engineer was not working; the data flow was almost entirely outbound (a developer using cloud storage legitimately typically both reads and writes, not pushes 200 GB one way); and the volume — 200 GB from a single workstation — vastly exceeded anything an engineer's laptop would have a reason to upload, since real bulk data lived on the build and data-science servers, not on ws-eng-114. Any one of these could have an innocent explanation; together they did not. Notice, too, the limit the team was honest about: the network data established that 200 GB went to an uncatalogued destination, but it could not, by itself, prove what the 200 GB contained (the channel was HTTPS) — confirming it was source code rather than, say, harmless logs required correlating with what ws-eng-114 had accessed internally, which they could not yet see. That gap is the whole point of Phase 4.

Phase 3 — The second channel: data hiding in DNS

The 200 GB to the cloud bucket was the obvious channel. But during the same investigation, an analyst reviewing ws-eng-114's egress noticed something the volume analysis had nearly missed: the host was also making an unusually large number of DNS queries — thousands per hour — to subdomains of a single external domain, each subdomain a long, random-looking string. Lumen Forge had no internal Zeek at the time, but the firewall's DNS logging captured enough to see the pattern, and the team reconstructed what a dns.log would have shown:

# reconstructed dns.log pattern from ws-eng-114
query = k7f3-9x2m1q8z4...a.sync.example     (TXT)   # long, high-entropy label
query = p2j8-4t6w0r3y9...b.sync.example     (TXT)
query = m9c1-7v5n2k8x6...c.sync.example     (TXT)
   ... thousands of distinct high-entropy subdomains of sync.example per hour ...

Figure CS2.2 — DNS tunneling, reconstructed. A host encoding data into the subdomain labels of queries to an attacker-controlled domain (sync.example). The tells are the volume (thousands of unique queries per hour, far above any normal host) and the entropy (long, random-looking labels, unlike real hostnames). The stolen bytes ride out inside the DNS queries themselves — a covert channel that a bytes-only outbound-volume check, focused on HTTPS, would underweight because each DNS query is tiny.

This is the §10.5 covert-channel scenario and the Chapter 9 DNS-abuse connection made real. Data exfiltrated through DNS does not show up as a big HTTPS transfer; it shows up as abnormal DNS behavior — query volume and name entropy far outside any normal host's. The team flagged it with exactly the logic this chapter's toolkit previews as a DGA/entropy score: real domain names have low entropy and hosts make modest numbers of distinct queries; ws-eng-114 violated both. The presence of two channels — bulk HTTPS and DNS tunneling — told the team this was a deliberate, prepared exfiltration, not an accident or a misconfigured backup.

🔗 Connection: This is precisely why Zeek's dns.log is called a detection goldmine in §10.3 and why Chapter 9 treats DNS as both an attack surface and a monitoring opportunity. Lumen Forge caught the DNS channel only by luck and coarse firewall logs; with internal Zeek, the dns.log would have made the tunneling obvious automatically — abnormal query volume and high-entropy names are among the most reliable network detections that exist. The fix in Phase 5 makes this a standing capability rather than a fortunate catch.

Phase 4 — The visibility gap, named

With the what and where established, the team confronted the uncomfortable architectural question: why did this run for three weeks before a cloud bill — not a security control — surfaced it? The answer was a coverage gap, and naming it precisely is the design lesson of this case:

  • No per-host outbound baselining was running. The data to detect the anomaly existed in firewall egress logs, but nobody was summarizing it per host against a baseline. The signal was present; no detection consumed it. (This is the §10.4 baseline lesson: collecting data is not the same as watching it.)
  • No internal (east-west) visibility at all. The team could see traffic leaving the building but had no view of what ws-eng-114 did inside the network first — whether it had accessed the source-code repository servers or the model store, and how. The attacker's staging (gathering the data internally before sending it) was completely invisible, because Lumen Forge had no sensor on internal traffic.
  • No DNS monitoring as a detection. DNS was logged but not analyzed; nobody was scoring query volume or entropy, so the tunneling channel was nearly missed.
   WHAT LUMEN FORGE COULD SEE              WHAT IT COULD NOT SEE (the gap)
   ────────────────────────────           ──────────────────────────────────────
   [internet edge]  egress bytes  ✓        east-west: ws-eng-114 -> code repo  ✗
   firewall logs    dst + ports   ✓        east-west: ws-eng-114 -> model store ✗
                    DNS queries   ✓(raw)   DNS analyzed for tunneling          ✗
                                           per-host outbound baseline running   ✗
   ───────────────────────────────────────────────────────────────────────────
   Result: the THEFT (north-south) was eventually visible in retained egress
   logs; the STAGING (east-west) was invisible; both detections were unmanned.

Figure CS2.3 — Lumen Forge's coverage gap. Perimeter egress data existed and eventually told the story, but no detection was actively consuming it, and there was zero east-west visibility, so the internal staging of the theft left no trace. Visibility is a coverage problem (where sensors sit) and an operations problem (whether anyone watches them) — the §10.6 Threshold Concept, learned the hard way.

🚪 Threshold Concept: Two failures hide inside one breach here, and a mature defender separates them. The first is coverage: no sensor watched east-west traffic, so an entire phase of the attack (internal staging) was unobservable — no analyst, however skilled, can detect what no sensor sees. The second is operations: even the data they did have (egress logs, DNS logs) was not being turned into detections, so the signal sat unread. "We have logs" is not "we have monitoring." Network monitoring is the active practice of consuming telemetry against baselines and detections — which is the difference between this case study and Case Study 1, where Meridian was actually watching.

Phase 5 — Closing the gap by design

The remediation is a network-monitoring redesign, applying this chapter's principles to a cloud-first company that had under-invested internally:

  1. Internal flow collection and east-west Zeek. Enable flow export on internal switches and place a Zeek sensor (via tap) on the link to the sensitive zones — the source-code repository and model-store servers — so that access to the crown jewels and any internal staging is visible. This is the single biggest gap-closer: it makes the previously invisible east-west phase observable.
  2. Per-host, per-destination outbound baselining as a running detection. Operationalize the Phase 1–2 analysis: continuously summarize outbound per host vs its baseline and alert on large ratios and on cumulative totals to non-standard destinations over multi-day windows — so low-and-slow no longer hides.
  3. DNS analysis as a standing detection. Feed DNS (via Zeek dns.log) into volume- and entropy-based scoring so tunneling is flagged automatically, not by luck.
  4. Everything into the SIEM, correlated with identity. Forward flow, Zeek, and DNS telemetry into the SIEM so a future "ws-eng-114 sends 7× baseline to a new bucket" can be correlated with "and an unusual credential accessed the model store an hour earlier" — turning two medium signals into one high- confidence detection (the Chapter 21 premise).
  5. Targeted full PCAP on the sensitive-zone link, short retention, for deep investigation when a detection fires.

Run the attack back through the redesigned monitoring and it dies early. On day one, the per-host baseline detection flags ws-eng-114 the first time its outbound climbs past a few times its norm to an uncatalogued destination — not three weeks and a cloud bill later. The DNS detection flags the tunneling the first hour it begins, on volume and entropy alone. And the new east-west sensor records ws-eng-114 reaching the source-code repository and model store — the staging that was previously invisible — so the SIEM can correlate "this workstation accessed the crown jewels" with "and then pushed 7× its normal volume to a new external destination" into a single high-confidence alert. The three-week dwell time collapses to hours. That is the concrete payoff of the design, and it is worth stating in those terms to a leadership team weighing the cost: the investment does not merely "improve visibility" in the abstract; it converts a specific, expensive, near-miss IP theft into a same-day detection.

It is also instructive that Lumen Forge's redesigned target state looks almost identical to Meridian's network-monitoring design from Case Study 1 — flow everywhere, Zeek on the high-value and east-west links, DNS analyzed, targeted PCAP on the crown-jewel link, everything correlated in the SIEM — despite the two organizations being wildly different in sector, size, and crown jewels. That convergence is not a coincidence; it is the chapter's principles doing their job. The questions are universal ("can I see east-west movement? am I baselining per host? is my DNS analyzed? does my telemetry reach a place where it can be correlated?"), even though the answers (which links, how much retention, which zones are sensitive) are tuned to each environment. A defender who internalizes the questions can design the visibility layer for a bank, a software company, a hospital, or a utility, because the shape of the problem — see the traffic, baseline it, detect the three behaviors, feed the SIEM — does not change.

🔗 Connection: Note what network monitoring still cannot do, even after this redesign, and where the handoff lies. The network can now show that ws-eng-114 accessed the model store and that it sent 200 GB out — but to prove intent and mechanism (was this a malicious insider, a compromised account, or malware? what process did it?), the team needs endpoint forensics (Chapter 25) and identity telemetry (Part IV), correlated in the SIEM (Chapter 21). Network monitoring is necessary and not sufficient: it tells you what moved where, and points you to the other sources that explain who and how. This is the same boundary Case Study 1 drew, reached from the exfiltration direction.

Discussion Questions

  1. Lumen Forge ranked hosts by ratio to their own baseline, not by raw outbound bytes. Explain why raw bytes would have hidden the attacker, and construct a short example (two hosts, with numbers) where ranking by raw volume points at the wrong host.
  2. The exfiltration used two channels: bulk HTTPS to a cloud bucket and DNS tunneling. Why would an attacker bother with the slow DNS channel at all, and what does using two channels tell you about their sophistication and intent?
  3. Management's reasoning — "we're cloud-first, so the perimeter is where the action is" — was half right. Which half was correct, and which half created the gap? How would you make the argument for internal visibility to a cost-conscious leadership team?
  4. The case distinguishes a coverage failure (no east-west sensor) from an operations failure (logs not turned into detections). Which of the two do you think is more common in real organizations, and which is cheaper to fix? Defend your answer.
  5. Even after the redesign, network monitoring cannot determine whether ws-eng-114 was a malicious insider or a compromised account. What specific endpoint and identity evidence would resolve that, and why must it be correlated with the network data rather than read in isolation?

Your Turn

You advise a 300-person company whose crown jewels are source code, with cloud-first infrastructure and only perimeter logging. (1) Write the per-host outbound baseline detection in steps: the grouping key, the comparison (ratio to host baseline and cumulative to destination), the windows, and the alert thresholds — and explain how each defeats a specific evasion (bulk vs low-and-slow). (2) Specify the DNS tunneling detection: which log, and the two properties you would score (with a one-line rationale each). (3) Identify the single most important coverage gap to close first and where you would place the sensor to close it. (4) Name one thing your design still cannot determine and which other data source (endpoint or identity) you would correlate to determine it. Keep it to one page.

Key Takeaways

  • Exfiltration detection is volume-and-channel analysis, the counterpart to Case Study 1's timing analysis: rank hosts by deviation from their own outbound baseline, not raw bytes, so the anomaly is visible even on a network where huge transfers are routine.
  • Baseline per host and per destination, not globally. A global baseline on a cloud-heavy network always says "normal"; the attacker hides in the aggregate. Fine-grained baselines expose a single host sending 7× its norm to a non-standard destination.
  • Low-and-slow defeats per-interval thresholds, not cumulative ones. Watch cumulative totals to a destination over multi-day windows; any single threshold the attacker knows, they will stay under.
  • DNS can be an exfiltration channel. Watch dns.log for abnormal query volume and name entropy; data tunneled through DNS is invisible to a bytes-only HTTPS check but obvious in DNS behavior (the Chapter 9 link).
  • Two failures hide in one breach: coverage and operations. No east-west sensor meant the internal staging was unobservable (coverage); unwatched egress and DNS logs meant the signal sat unread (operations). "We have logs" is not "we have monitoring."
  • Network telemetry tells you what moved where, not who and how. Even a well-designed visibility layer must hand off to endpoint forensics and identity data, correlated in the SIEM, to establish intent and mechanism — the same boundary both case studies reach from opposite directions.