Hunting Data Exfiltration
Data theft rarely looks dramatic on the wire. Here's how to hunt exfiltration across HTTP, DNS, cloud storage, and covert channels.
Nobody sets off an alarm labeled “data leaving the building.” Exfiltration, done competently, looks exactly like the thousand other legitimate uploads, syncs, and API calls happening across your network every hour. That’s the core challenge, and it’s why exfiltration hunting is less about finding a smoking gun and more about noticing when normal-looking behavior happens in an abnormal context wrong volume, wrong destination, wrong time, wrong account.
Attackers have a lot of channels to choose from, and a mature exfiltration hunting program can’t afford to only cover the obvious one.
Volume and destination together beat volume alone
The naive approach alert on any large outbound transfer drowns instantly in false positives, because legitimate large uploads happen constantly. Backup jobs, video conferencing, cloud storage sync, software updates. Raw byte count alone is close to useless as a standalone signal in most modern enterprise environments.
What actually works: volume relative to destination reputation and historical baseline for that specific host or user. A finance analyst’s workstation uploading 400MB to a personal Dropbox account it’s never touched before is a meaningfully different finding than the same volume moving to your organization’s own sanctioned Box tenant, which it uses every day. Building destination categorization sanctioned cloud services, unsanctioned but known services, entirely unknown destinations into your exfiltration analytics, and weighting volume anomalies against that categorization, cuts the noise dramatically compared to a flat threshold rule.
DNS and ICMP tunneling deserve their own dedicated watch
Covered in more depth in our DNS hunting piece, but worth restating here specifically in the exfiltration context: DNS tunneling remains a favored channel precisely because so many networks allow essentially unrestricted outbound DNS without a second thought. High query volume to a single parent domain, combined with high-entropy subdomain labels, is the signature to watch for, and it catches exfiltration attempts that would sail straight through volume-based HTTP monitoring because DNS traffic rarely gets counted the same way.
ICMP tunneling is rarer in practice but shows up occasionally, particularly in environments with looser egress filtering on ICMP than on TCP/UDP. Unusually large or frequent ICMP echo requests to a single external destination, especially with payload sizes that don’t match typical diagnostic ping usage, is worth a specific detection even though the volume of actual incidents you’ll catch this way is lower than DNS-based tunneling.
Cloud storage and SaaS exfiltration is where a lot of modern theft actually happens
A meaningful share of real-world exfiltration today doesn’t look like a classic C2 exfil channel at all it looks like someone uploading files to a personal cloud storage account, forwarding emails to a personal address, or using a legitimate SaaS API in a way that’s technically allowed but contextually wrong. This is genuinely harder to catch with network-layer analysis alone, because the traffic to Dropbox or Google Drive from a sanctioned SaaS gateway looks identical whether it’s an employee backing up vacation photos or someone walking out the door with a customer database.
CASB (Cloud Access Security Broker) telemetry, where available, becomes essential here because it can distinguish between an organization’s sanctioned tenant and an employee’s personal account on the same service something raw network flow data genuinely can’t do on its own, since the destination IP and even the SNI can look identical for both. Where CASB isn’t available, correlating proxy log user-agent and URL path data against known personal-account URL patterns for major cloud services gets you partway there, though it’s a rougher signal than dedicated CASB visibility.
Insider-adjacent exfiltration needs a different investigative posture
A meaningful share of serious exfiltration cases involve an insider someone with legitimate access moving data out deliberately, whether that’s a departing employee taking client lists or something more deliberate. The network hunting techniques above still apply, but the investigative framing shifts: you’re not looking for a compromised host behaving oddly, you’re looking for a legitimate account behaving oddly relative to its own established pattern.
Time-of-day and volume-relative-to-role analysis matter more here than pure destination categorization. Someone in HR who’s never accessed the engineering file share suddenly pulling and uploading forty gigabytes of source code repositories two days before their last day is a pattern that HR-adjacent network monitoring, tied to offboarding calendar data if your organization tracks it, can catch and honestly, correlating exfiltration hunting against HR offboarding schedules is one of the more underused but genuinely effective techniques available, even though it requires a level of cross-team coordination a lot of security programs never quite establish.
Building the investigation chain once something fires
When an exfiltration indicator does trip, the investigation needs to move fast on establishing scope: what was actually taken, where did it go, and is the channel still open. Pulling the specific files or data touched, if endpoint telemetry supports that level of detail, matters enormously for scoping actual business impact versus just confirming “something unusual happened.” A vague finding of “large upload detected” forces incident response into guesswork; a finding that specifies which files, which destination, and which account turns the same event into something legal and leadership can actually act on with confidence.