← Retour à l’analyseur

Détecter l’exfiltration de données avec SRUM

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

  1. 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.
  2. Ouvrir dans l’analyseur SRUM et sélectionner l’onglet Utilisation des données réseau.
  3. Trier par BytesSent décroissant. Exportez en CSV pour travailler les chiffres dans un tableur.
  4. 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é.
  5. Attribuer. Le UserId résolu (SID) indique la session. L’AppId résolu indique le programme. Le SID d’un employé sur le départ face à une ligne 7-Zip ou curl.exe est une piste forte.
  6. Vérifier le réseau. L2ProfileFlags se décode en Filaire / Wi-Fi / Mobile. Une exfiltration via hotspot personnel pour contourner le filtrage d’entreprise apparaît clairement ici.
  7. Cadrer dans le temps. Le TimeStamp situe 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 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.