Repérer l'exfil : trouver un pattern de vol de données dans les logs d'accès
Le défi
Voici vos logs d'accès web. La plupart du trafic est de petites pages et ressources, mais une IP récupère sans cesse l'export complet des données et les tailles de réponse sont énormes - quelqu'un siphonne les données. 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
- Filtrer un log d'accès bruyant par chemin pour isoler un endpoint
- Utiliser la colonne de taille de réponse pour distinguer la navigation normale du vol de données en masse
- Reconnaître la signature d'exfiltration de données : un volume élevé depuis une source unique
- Attribuer l'exfiltration à une seule adresse IP source
- Distinguer un pattern d'exfiltration d'un brute force ou d'un scan
Compétences testées
Prérequis
- Compréhension des requêtes HTTP et des tailles de réponse
- Familiarité avec le trafic web classique par rapport aux téléchargements en masse
Comment ça marche
Toutes les attaques ne sont pas des brute force. Une fois qu'un attaquant a accès, l'objectif est souvent de voler des données, ce qui laisse une empreinte très différente dans les logs. Le trafic web ordinaire est fait de petites réponses : une page fait quelques kilo-octets, un appel API quelques centaines d'octets, un health check quelques octets à peine. L'exfiltration de données rompt ce schéma : un client sollicite sans cesse un endpoint qui renvoie l'intégralité d'un jeu de données, et les tailles de réponse explosent jusqu'à des centaines de mégaoctets, voire des gigaoctets.
L'indice ici est la colonne bytes. Filtrez sur path:/export et vous voyez 45.77.12.9 récupérer /export?all=1 encore et encore, chaque réponse pesant environ quatre milliards d'octets, soit approximativement 4 Go. Aucun utilisateur légitime ne télécharge la base de données entière une douzaine de fois en une demi-heure. Toutes les autres lignes du log sont des pages ou ressources de taille normale provenant d'une autre adresse, si bien que la source d'exfiltration est le seul type de ligne qui combine un endpoint sensible, une IP qui se répète, et une taille de réponse absurde.
Le triage SIEM consiste à choisir la bonne colonne pour trier ou filtrer. En cas de suspicion de fuite de données, la taille de réponse (ou volume sortant) est le champ le plus révélateur : il transforme un vol invisible en un pic évident.
Erreurs fréquentes
- Ignorer la colonne bytes. Sans elle, les requêtes d'export ressemblent à des GET ordinaires ; c'est la taille de réponse qui prouve le vol.
- Confondre l'exfil avec un brute force. Il n'y a pas de 401 répétés ici, les requêtes réussissent ; l'anomalie porte sur le volume, pas sur des échecs.
- Accuser une IP occupée mais bénigne. Plusieurs adresses font beaucoup de petites requêtes ; une seule combine un endpoint sensible avec des réponses de plusieurs gigaoctets.
- Soumettre le chemin au lieu de l'IP. La question demande quelle source draine les données.
Comment s'en protéger
L'exfiltration de données se détecte mieux en surveillant le volume de données qui sort, pas seulement qui se connecte. Le même signal de taille de réponse que vous avez filtré peut alimenter une détection et une prévention automatisées.
- Déclencher une alerte sur des réponses anormalement volumineuses ou sur le volume sortant par client vers des endpoints sensibles comme
/export. - Limiter le débit et paginer les endpoints d'export en masse pour qu'une seule requête ne puisse pas renvoyer l'intégralité du jeu de données.
- Exiger une authentification et une autorisation fortes sur toute route d'export complet des données, et journaliser qui la déclenche.
- Utiliser une solution de prévention des fuites de données (DLP) ou une surveillance du trafic sortant pour signaler un volume sortant inhabituel par source.