Détecter l'exfiltration de données avec l'usage réseau SRUM
19/05/2026
Network Data Usage est l'un des rares endroits sur un hôte Windows qui enregistre des octets par processus avec attribution par utilisateur sur un réseau spécifique. Elle n'enregistre pas les destinations, URL ni contenus. Traitez-la comme une source de triage et de corroboration, pas une capture de paquets. Utilisée avec les journaux proxy et les chronologies du système de fichiers, elle clôt des affaires d'exfiltration que l'EDR seul ne pouvait pas résoudre.
Ce que la table contient réellement
{973F5D5C-1D90-4944-BE8E-24B94231A174} : Network Data Usage. Chaque
ligne horaire contient :
TimeStamp: limite du seau (date OLE).AppId: se résout vers un processus viaSruDbIdMapTable.UserId: se résout vers un SID.InterfaceLuid: LUID Windows pour l'interface réseau.L2ProfileId: GUID opaque ; résolvez viaNetworkList\Profilesdans le registre.L2ProfileFlags: masque binaire :0x100filaire,0x200sans-fil,0x400WWAN.BytesSent,BytesRecvd: compteurs par échantillon, par processus.
Ce qu'elle ne contient pas : URL, noms de fichiers, charges utiles de paquets, destinations.
Le flux de travail
- Acquérir et restaurer. Extrayez tout le répertoire
sru\et la rucheSOFTWARE. Rejouez les journaux si sale. Voir comment réparer un SRUDB.dat corrompu. - Ouvrir Network Data Usage. Dans l'analyseur navigateur ou
SrumECmd. L'onglet de l'analyseur résout déjàAppIdetUserId. - Trier par
BytesSentdécroissant. Exportez en CSV si vous voulez traiter les chiffres dans un tableur. - Établir une base, ne pas seuiller aveuglément. Les clients de
synchronisation cloud, les navigateurs et les agents de mise à jour
transfèrent légitimement des gigaoctets. Le signal est un processus
qui normalement parle peu et qui envoie soudain beaucoup :
powershell.exe,pwsh.exe,cmd.exe,curl.exe, archiveurs, tout ce qui vient de%TEMP%ou%AppData%, tout binaire non signé. - Attribuer. Le
UserIdrésolu (SID) indique la session. L'AppIdrésolu nomme le binaire. Le SID d'un employé partant face à une ligne7z.exeoucurl.exeest une piste. - Vérifier le réseau.
L2ProfileFlagsse décode en filaire / Wi-Fi / haut débit mobile. Trafic sortant via un hotspot personnel pour contourner le filtrage de sortie d'entreprise est le signal d'exfiltration classique. - Délimiter dans le temps. Utilisez
TimeStamppour aligner sur la démission du suspect, une fenêtre de compromission connue, ou une activité hors heures.
Un signal type
Une ligne pwsh.exe, UserId résolu vers le SID du suspect,
BytesSent ≈ 1,4 Go sur trois seaux du soir consécutifs,
L2ProfileFlags indiquant un haut débit mobile. Cette combinaison
(processus inhabituel + volume inhabituel + utilisateur identifié +
hors heures + réseau de contournement) est l'empreinte d'exfiltration.
Elle ne vous dit pas les fichiers.
Pour le quoi, pivotez :
- journal USN : suppressions, renommages, créations d'archives dans la même fenêtre.
- MFT : répertoires de staging, fichiers d'archive, tailles de fichiers qui correspondent aux volumes transférés.
- Prefetch : exécution
d'archiveurs,
curl,rclone,aws.exe. - AmCache : SHA-1 de tout binaire sur mesure référencé dans les lignes suspectes.
- EVTX : journaux script-block
PowerShell
4104, connexions réseau Sysmon3(si l'hôte avait Sysmon).
Chevauchement réel avec l'EDR
L'EDR moderne enregistre aussi le trafic réseau au niveau processus. SRUM gagne encore quand :
- L'EDR n'était pas déployé pendant la fenêtre suspecte.
- L'EDR a été désactivé par l'adversaire ; DPS l'est rarement.
- La rétention EDR ne couvre pas la période.
- Le transfert s'est fait sur un hotspot personnel inaccessible depuis le cloud de l'EDR.
Les meilleurs dossiers d'exfiltration empilent EDR, proxy/pare-feu, SRUM et preuves système de fichiers. Si l'un manque, les autres comblent généralement le vide.
Limites à énoncer honnêtement
- Regroupement horaire : impossible de prétendre à une minute précise de transfert depuis les lignes court-terme. On peut dire "entre 22:00 et 23:00 UTC".
- Pas de destination : SRUM ne peut pas prouver où les données sont allées. Les journaux proxy ou NetFlow le font.
- Compteurs cumulatifs par échantillon incluent les retransmissions. Les chiffres globaux sont corrects ; les revendications par paquet ne le sont pas.
- Les jumelles LT agrègent par semaine. Utilisez-les pour "s'est-il passé quelque chose dans l'année écoulée" ; n'épinglez pas une heure précise depuis une ligne LT.
Pour aller plus loin
Questions fréquentes
SRUM peut-il montrer quelles données ont été volées ?
Non. SRUM enregistre les compteurs d'octets par processus, pas les noms de fichiers ni leur contenu. Il dit quel processus a envoyé combien, sur quel réseau et sous quel utilisateur. Le 'quoi' se corrobore avec le journal USN, le MFT ou un DLP.
Quel seuil d'octets indique une exfiltration ?
Aucun chiffre universel. Établissez la base du processus : un agent de sauvegarde envoyant 2 Go est normal ; powershell.exe ou un binaire sur mesure envoyant 200 Mo ne l'est pas. L'onglet Anomalies de l'analyseur signale plus de 50 Mo dans un seul échantillon comme point de départ.
Quelle table SRUM utiliser ?
Network Data Usage ({973F5D5C-1D90-4944-BE8E-24B94231A174}). BytesSent est le compteur sortant ; AppId et UserId se résolvent vers le processus et l'utilisateur ; L2ProfileId correspond au réseau.
Peut-on détecter une exfiltration via VPN ou hotspot ?
Il détecte les octets indépendamment de la destination. L2ProfileFlags distingue filaire / Wi-Fi / haut débit mobile, ce qui révèle souvent un réseau inattendu (hotspot personnel) utilisé pour contourner les contrôles de sortie de l'entreprise.
SRUM suffit-il seul pour un cas d'exfiltration ?
C'est une preuve circonstancielle forte (processus + volume + utilisateur + réseau + temps). Associez-la aux journaux proxy/pare-feu, au DLP et aux chronologies du système de fichiers pour un dossier complet et défendable.