← Retour au blog

Détecter l'exfiltration de données et les copies sur clé USB avec le journal USN

Les copies massives, les drops sur USB et les répertoires de staging laissent une forme reconnaissable dans $UsnJrnl:$J. Les patterns à filtrer, avec des exemples concrets.

5 min de lecture

Après le ransomware, la deuxième question DFIR la plus fréquente qu'on entend est « est-ce que quelque chose est sorti d'ici ? ». Le journal USN est l'un des endroits les moins coûteux pour y répondre. Il enregistre chaque création, chaque renommage, chaque extension de données — ce qui signifie que l'exfiltration USB, le staging de synchronisation cloud, et le classique « tout déposer dans un dossier temp avant de zipper » ressortent tous de façon très distinctive sur une timeline.

Cet article est le playbook pour trouver ces patterns.

Les clés USB sont le mode facile

Quand un utilisateur attache un volume amovible, Windows lui assigne une nouvelle lettre de lecteur et le système de fichiers du périphérique reçoit son propre $UsnJrnl s'il est en NTFS. Mais quand des fichiers sont copiés depuis le système investigué vers la clé USB, le journal du volume source enregistre quand même le côté lecture comme une série d'accès — et, plus important, le journal de destination (si on a l'image USB) montre les écritures.

Ce qu'on a en général :

  • Le journal du disque source — montre ce qui a été ouvert/fermé et les fichiers temporaires.
  • Les ruches du registreSYSTEM\MountedDevices, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 et les events Setup matériel pour identifier quelle USB a été branchée.
  • Le journal du volume de destination, si le périphérique était en NTFS et qu'on peut l'imager — c'est là qu'on voit les fichiers réels.

Premier signal côté source : un cluster d'ouvertures de fichiers dans une fenêtre courte ciblant l'arbre Documents/Desktop/Downloads de l'utilisateur. Les ouvertures ne produisent pas toujours des enregistrements USN, mais les caches du système de fichiers et les scans AV qui suivent en produisent souvent (toucher les attributs déclenche BasicInfoChange | Close).

Un signal plus décisif arrive si l'attaquant zippe d'abord les données : un FileCreate d'un .7z, .zip, .rar ou d'un fichier au nom aléatoire à un chemin temp, suivi d'enregistrements DataExtend | Close soutenus jusqu'à ce que le fichier atteigne sa taille finale.

Le motif classique staging-puis-copie

Un motif fréquent, correspondant à T1074 Data Staged dans MITRE ATT&CK :

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
…
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← beaucoup, le fichier grossit
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (nettoyage)

Trois signaux ensemble :

  • Une salve de FileCreate dans un seul dossier de staging.
  • Des DataExtend ultérieurs sur une archive unique dont la taille finale approche la somme des fichiers stagés.
  • Un balayage de suppression du dossier de staging peu après la création de l'archive.

Filtrer les FileCreate dans \AppData\Local\Temp\, \Public\, \Downloads\ ou d'autres emplacements inscriptibles de l'arbre utilisateur, et chercher des clusters dans le temps de >50 fichiers en <60 secondes. C'est à quoi ressemble une opération de vol interne ou un infostealer sur disque.

Staging via synchronisation cloud

OneDrive, Dropbox, Google Drive — chacun maintient un dossier de synchronisation local. Tout ce qu'on y dépose est uploadé dès que l'agent le voit. Deux signaux :

  • RenameNewName en masse vers le dossier de sync depuis Desktop\, Documents\ ou Downloads\. La moitié rename vous dit le parent précédent ; le nouveau parent est le dossier de sync.
  • DataExtend | Close sur des fichiers dans le dossier de sync sans FileCreate correspondant d'une application utilisateur. L'agent de sync écrit ces fichiers lui-même — ce sont des téléchargements — mais ce sont les créations que vous voulez pour les uploads.

Pour un filtre par nom, les dossiers de sync canoniques sur Windows sont \Users\<u>\OneDrive\, \Users\<u>\Dropbox\ et \Users\<u>\Google Drive\. Les outils listés dans les ressources insider threat TLP-WHITE de la CISA ont des hypothèses de baseline similaires.

Heuristiques qui marchent vraiment

Après plusieurs missions, les heuristiques qui tendent à signaler une vraie exfiltration sont :

  1. Salve de créations : plus de N FileCreate dans un même dossier en T secondes. À calibrer sur la baseline. On commence à N=50, T=60.
  2. Archive après salve : un seul FileCreate d'un fichier avec une extension d'archive connue (.zip, .7z, .rar, .tar.gz) dans les minutes suivant une salve, avec des DataExtend ultérieurs accumulant plusieurs Mo.
  3. Renommage de masse à travers les frontières : enregistrements RenameNewName dont le nouveau chemin parent est structurellement différent de l'ancien (DocumentsOneDrive, DesktopPublic, etc.). Facile à exprimer en regex sur les chemins complets résolus.
  4. Salves hors heures de bureau : n'importe laquelle des précédentes en dehors des heures de bureau de l'utilisateur. À coupler avec les events de logon Security.evtx pour confirmation.

Le parseur de ce site expose un filtrage par fenêtre temporelle et des filtres par raison qui font 1–3 en un clic chacun. Pour (4), exporter en CSV et pivoter sur l'heure de la journée.

Ce que vous ne verrez pas

Quelques techniques d'exfiltration réelles ne produisent aucun signal USN exploitable :

  • Upload direct depuis la mémoire via un navigateur ou PowerShell — les données ne touchent jamais le disque, donc le journal n'a rien.
  • Lecture d'un partage réseau — le côté source est le système de fichiers qui héberge le partage, souvent pas le vôtre.
  • Capture d'écran comme exfil — produit seulement la création d'un ou deux fichiers image.
  • Impression — laisse seulement de l'activité dans \Windows\System32\spool\PRINTERS\, qui est son propre artefact forensique, pas vraiment un sujet USN.

Pour une vue plus large du modèle de menace, la page Exfiltration de MITRE ATT&CK liste chaque technique et son résidu. USN couvre directement peut-être un tiers ; le reste demande logs d'événements, captures réseau ou historique navigateur.

Exemple concret

Voici le genre de CSV qu'on exporterait d'une vraie mission pour démontrer une exfil :

HeureRaisonsCheminNotes
19:42:11FileCreate Close\Users\b\Temp\q3\Nouveau dossier
19:42:13–14FileCreate × 84\Users\b\Temp\q3\*.xlsxSalve
19:44:08FileCreate Close\Users\b\Temp\q3.zipArchive
19:44:08–22DataExtend × ~40\Users\b\Temp\q3.zipGrossit à 187 Mo
19:44:45RenameNewName Close\Users\b\OneDrive\q3.zipDéplacé vers sync
19:45:11FileDelete × 84\Users\b\Temp\q3\*Nettoyage

Cette timeline est un faisceau d'indices accablant. Sans le journal, il faudrait la reconstruire à partir du registre, du Prefetch et des shadow copies — cinq fois plus de travail, deux fois moins de confiance.