Détecter l’exfiltration de données avec SRUM
19/05/2026
Ce que SRUM peut et ne peut pas dire
La table Utilisation des données réseau enregistre, par bucket horaire : quel processus a envoyé combien d’octets, sous quel utilisateur, sur quel réseau. Elle n’enregistre pas les destinations, URLs ou contenus. C’est donc une puissante source de triage et corroboration, pas une capture réseau.
La méthode
- Acquérir et récupérer la base. Si elle est dirty, faites d’abord la récupération douce — voir Réparer un SRUDB.dat corrompu.
- Ouvrir dans l’analyseur SRUM et sélectionner l’onglet Utilisation des données réseau.
- Trier par
BytesSentdécroissant. Exportez en CSV pour travailler les chiffres dans un tableur. - Baseliner, pas seuiller à l’aveugle. Navigateurs, agents de mise à
jour et clients de synchro déplacent légitimement des Go. Le signal
est un processus qui normalement parle peu et envoie soudain
beaucoup :
powershell.exe,cmd.exe, archiveurs, binaire non signé. - Attribuer. Le
UserIdrésolu (SID) indique la session. L’AppIdrésolu indique le programme. Le SID d’un employé sur le départ face à une ligne 7-Zip oucurl.exeest une piste forte. - Vérifier le réseau.
L2ProfileFlagsse décode en Filaire / Wi-Fi / Mobile. Une exfiltration via hotspot personnel pour contourner le filtrage d’entreprise apparaît clairement ici. - Cadrer dans le temps. Le
TimeStampsitue le transfert par rapport à la démission, une fenêtre de compromission connue, ou une activité hors heures (l’onglet Anomalies signale automatiquement les schémas hors heures).
Signal concret
Une ligne pwsh.exe, utilisateur = SID du suspect, BytesSent ≈ 1,4 Go
sur trois buckets de soirée consécutifs, L2ProfileFlags = mobile —
cette combinaison (processus inhabituel + volume + utilisateur + hors
heures + réseau de contournement) est l’empreinte type de
l’exfiltration. Elle ne donnera pas les fichiers ; pivotez vers le
journal USN et la MFT pour cela.
Limites à énoncer honnêtement dans un rapport
- Regroupement horaire — impossible de revendiquer la minute exacte.
- Pas de destination — SRUM ne prouve pas où sont allées les données.
- Compteurs cumulés par échantillon, pouvant inclure des retransmissions.
Énoncez-les clairement ; cela rend la preuve présentée plus crédible.
Pour aller plus loin
Questions fréquentes
- SRUM montre-t-il quelles données ont été volées ?
- Non — SRUM compte les octets par processus, pas les noms de fichiers ni le contenu. Il indique quel processus a envoyé combien, sur quel réseau, sous quel utilisateur. On corrobore le « quoi » avec le journal USN, la MFT ou le DLP.
- Quel seuil d’octets indique une exfiltration ?
- Aucun nombre universel. Établissez une base par processus : un agent de sauvegarde envoyant 2 Go est normal ; powershell.exe ou un binaire custom envoyant 200 Mo ne l’est pas. L’onglet Anomalies signale >50 Mo dans un échantillon comme point de départ.
- Quelle table SRUM utiliser ?
- Utilisation des données réseau ({973F5D5C-1D90-4944-BE8E-24B94231A174}). BytesSent est le compteur sortant ; AppId et UserId résolvent le processus et l’utilisateur ; L2ProfileId mappe le réseau.
- Peut-il détecter une exfiltration via VPN ou hotspot ?
- Il détecte les octets quelle que soit la destination. L2ProfileFlags distingue filaire / Wi-Fi / mobile, ce qui révèle souvent un réseau inattendu (hotspot personnel) utilisé pour contourner le filtrage sortant de l’entreprise.
- SRUM suffit-il seul pour un cas d’exfiltration ?
- C’est une forte preuve circonstancielle (processus + volume + utilisateur + réseau + heure). Associez-le aux logs proxy/pare-feu, au DLP et aux timelines système pour un dossier complet et défendable.