Spot the Exfil: Finding a Data-Siphon Pattern in Access Logs
The challenge
These are your web access logs. Most traffic is small pages and assets, but one IP keeps pulling the full data export and the response sizes are enormous - someone is siphoning data out. Filter to the export endpoint, find the single source draining gigabytes, and submit its IP address.
What you'll learn
- Filter a noisy access log by path to isolate one endpoint
- Use the response-size column to distinguish browsing from bulk data theft
- Recognise the high-volume single-source signature of data exfiltration
- Attribute the exfiltration to a single source IP
- Tell an exfil pattern apart from a brute force or scan
Skills tested
Prerequisites
- Understanding of HTTP requests and response sizes
- Familiarity with typical web traffic versus bulk downloads
How it works
Not every attack is a brute force. Once an attacker has access, the goal is often to steal data, and that leaves a very different footprint in the logs. Ordinary web traffic is made of small responses - a page is a few kilobytes, an API call a few hundred bytes, a health check a handful of bytes. Data exfiltration breaks that pattern: one client repeatedly hits an endpoint that returns the whole dataset, and the response sizes balloon into hundreds of megabytes or gigabytes.
The tell here is the bytes column. Filter to path:/export and you see 45.77.12.9 fetching /export?all=1 again and again, each response around four billion bytes - roughly 4 GB. No legitimate user downloads the entire database a dozen times in half an hour. Every other line in the log is a normal-sized page or asset from a different address, so the exfil source is the one row type that combines a sensitive endpoint, one repeating IP, and an absurd response size.
SIEM triage is about choosing the right column to sort or filter on. For a suspected data leak, response size (or bytes out) is the single most revealing field - it turns an invisible theft into an obvious spike.
Common mistakes
- Ignoring the bytes column. Without it, the export requests look like ordinary GETs; the response size is what proves theft.
- Confusing exfil with a brute force. There are no repeated 401s here - the requests succeed; the anomaly is volume, not failures.
- Blaming a busy but benign IP. Several addresses make many small requests; only one combines a sensitive endpoint with gigabyte responses.
- Submitting the path instead of the IP. The question asks which source is draining the data.
How to defend against it
Data exfiltration is best caught by watching how much data leaves, not just who logs in. The same response-size signal you filtered on can drive automated detection and prevention.
- Alert on abnormally large responses or per-client egress volume to sensitive endpoints like
/export. - Rate-limit and paginate bulk export endpoints so a single request cannot return the entire dataset.
- Require strong authentication and authorization on any full-data-export route, and log who triggers it.
- Use data-loss-prevention or egress monitoring to flag unusual outbound volume per source.