Spot the Exfil: Finding a Data-Siphon Pattern in Access Logs
Le défi
Voici vos logs d'acces web. La plupart du trafic est de petites pages et ressources, mais une IP recupere sans cesse l'export complet des donnees et les tailles de reponse sont enormes - quelqu'un siphonne les donnees. Filtrez sur le point de terminaison d'export, trouvez la source unique qui draine des gigaoctets, et soumettez son adresse IP.
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- Understanding of HTTP requests and response sizes
- Familiarity with typical web traffic versus bulk downloads
Comment ça marche
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.
Erreurs fréquentes
- 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.
Comment s'en protéger
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.