Field Notes · Technical Notes September 2, 2026 · 5 min read

Scoping data theft you cannot capture in full.

When terabytes have already moved, you cannot PCAP your way to the answer, and you should not try. Standing up a full-packet tap across a live, high-throughput environment in the middle of an incident is how the responder becomes the outage. The method is to scope from the evidence that already exists, and then prove it on the hosts.

Start with the clock, not the theft

Sensor time, domain-controller time, storage-array time, and staging-host time are rarely the same clock. Document the skew before you build any timeline. Every correlation you make afterward is only as defensible as the clock underneath it, and an actor’s best unearned defense is a responder whose timeline does not survive that question.

Scope the volume from flow, not from packets

Historical NetFlow and firewall session logs give you months of byte counts and peers with no new collection at all. You are looking for the shape that does not fit the environment: long-lived, high-octet conversations in off-shift windows, a small set of external peers, and a source that sits inside the archive tier. Backups and vendor loopback tests have their own signatures; learn the normal before you name the anomaly. Resolve the peers where DNS exists, and pull SNI and certificate metadata from TLS logs. You are not decrypting anything — you are establishing where the mass went, in a form you can hand to counsel.

Turn “big UDP” into named files

A flow spike is evidence of traffic, not evidence of loss. Network metadata and deep session inspection — where a sensor has already reassembled sessions on a span port — give you protocol, filename, file type, size, and hash on a sample of objects. That is the line between “a large transfer occurred” and a briefing that names what left.

High-speed transfer protocols are the common blind spot. IBM Aspera, which moves bulk data over the FASP protocol, runs its control channel over SSH on TCP/33001 (or 22, if a default was left in place) and moves the payload over UDP/33001. Flow tooling routinely files that UDP as background noise. It is often the entire exfiltration path, and it will not resemble the HTTP or TLS egress most monitoring is tuned for.

Watch for the paths that are not in the diagram

Mass rarely leaves by the route the network drawing shows. Expect three shapes, and expect the important data and the heavy data to travel differently:

• The bulk path. Archive to an internal staging share over SMB, then a high-speed transfer tool from a compromised jump host to external object storage. This carries the tonnage.
• The trusted internal segment. A network everyone agreed was sacred and no one instrumented, hair-pinned and used for egress from an address the environment assumes is legitimate. It is not mystical; it is an undocumented route.
• Vendor camouflage. Small, high-value data — manifests, records, extracts — split into files named like routine vendor drops and sent to a destination the environment sees every week. Low volume, highest regret. Content identification, not filename, is what kills the cover story.

Prove it on disk

Wire scope tells you what left; the hosts tell you who and how. The questions, not a tool list:

• Volume leaving a host: SRUM network-usage bytes tied to the transfer process on the transferring interface, in the same windows flow shows leaving the building.
• The staging cycle: USN journal ($UsnJrnl:$J) create → rename → delete on the staging volume — archives assembled, transferred, removed — with $MFT SI/FN timestamps consistent with sequential staging rather than user interaction.
• Execution: prefetch run counts and Amcache first-execution for the transfer and archive binaries (ascp, 7z, WinSCP, staging scripts); Shimcache as supporting, not primary.
• Knowledge and access: shellbags, LNK and jump-list entries, RecentDocs and OpenSave MRU pointing at the archive UNC paths and export directories; and the transfer tool’s own on-disk logs, which name destinations, target rates, and file lists. People forget those logs.
• Accounts: 4624 type 3 and type 10 into the jump hosts, 4648 explicit-credential use, 4672 privileged tokens, and DC 4768/4769 for the identities you will eventually remove.

Distinguish the theft from the noise. Late-arriving tools — a rclone or WinSCP first seen weeks after the main pattern was already mature — are usually not the story. Brief the noise as the theft and you lose the finding, and in an adversarial setting you lose it in front of people paid to find the gap.

Assume a second stage when you cut the first

Disabling the actor’s identities and purging tickets is the moment they learn they are caught. Plan for the destructive stage before you pull the trigger: shadow-copy deletion, new binaries on the storage controllers, encryption starting against the highest-value shares. If the first-stage evidence is already in a timeline rather than in someone’s head, you can act on the wipe in minutes instead of reconstructing it under fire. Recovery source and exhibit are not the same object: hash the known-good snapshots, set them aside as evidence, and restore from a copy.

What you can defend

Not “we caught them.” The narrower sentence is the one that holds up: you accounted for the bytes on the wire, tied those bytes to processes and accounts on disk, named the egress paths that were not in the architecture, and stopped the second stage because the first-stage evidence was already written down. A conclusion built that way survives the room where it is challenged. One built on adrenaline does not.

Companion: the Windows intrusion artifacts reference · Evidence Gaps Are Findings · A Technical Claim Is Not Evidence

If you are scoping a live exfiltration, this is the work I do.