Détecter l'exfiltration de données et la copie sur USB avec le USN journal

Après le ransomware, la deuxième question DFIR la plus courante est une variante de « est-ce que quelque chose est parti d'ici ? ». Le USN journal est l'un des endroits les moins chers pour commencer à y répondre. Chaque copie USB, chaque upload cloud-sync et chaque opération de drop-everything-in-a-temp-folder-then-zip laisse une forme reconnaissable dans $J — assez reconnaissable pour qu'avec deux filtres et un pivot sur le chemin parent tu puisses généralement triagiser une fenêtre candidate d'exfil en moins de vingt minutes.

Ce billet est le playbook pour trouver ces motifs, ventilé par canal d'exfil.

Les clés USB laissent la trace la plus propre

Quand un utilisateur branche un volume amovible, Windows lui attribue une lettre de lecteur et, si le volume est NTFS, l'appareil obtient son propre $UsnJrnl. Les fichiers copiés vers la clé USB atterrissent dans le journal de destination comme FileCreate | Close plus un flux d'enregistrements DataExtend | Close. Les fichiers copiés depuis le disque source laissent une trace plus douce côté source : des événements open et close qui produisent souvent BasicInfoChange | Close à cause du scan AV et du caching filesystem qui suivent la lecture.

Ce que tu as typiquement sur un engagement réel :

• Le journal du disque source. Montre ce qui a été ouvert, tous les fichiers temp ou archive créés, et le sweep final de suppression si l'utilisateur a fait le ménage.
• Les hives de registre. SYSTEM\MountedDevices, SYSTEM\CurrentControlSet\Enum\USBSTOR, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 et setupapi.dev.log identifient ensemble quel appareil physique a été branché et quand. Parse-les avec le parser de registre.
• Le journal du volume de destination, si tu as l'image USB. C'est là que vivent les écritures de fichiers réelles.

Le signal décisif côté source est le motif archive-avant-copie, parce que la plupart des utilisateurs qui ont quelque chose à cacher se tournent vers 7-Zip ou la compression intégrée d'Explorer avant de sortir le lecteur : un FileCreate d'un .7z, .zip, .rar ou fichier au nom aléatoire à un chemin temp, suivi d'enregistrements DataExtend | Close soutenus jusqu'à ce que le fichier atteigne sa taille finale. Le chemin est habituellement \Users\<u>\AppData\Local\Temp\, \Users\<u>\Desktop\ ou la racine du profil utilisateur.

Pour le côté identification USB, croise les timestamps du journal avec les événements Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx de connexion/déconnexion — le parser EVTX en fait un travail de quelques clics. Apparie avec des fichiers LNK sous \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ et des jump lists pour des preuves explicites d'utilisateur-a-ouvert-depuis-USB.

Le motif classique staging-puis-archive

Cartographie sur T1074 Data Staged dans MITRE ATT&CK et ressemble à ça sur disque :

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 de ceux-ci, le fichier grossit
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (nettoyage)

Trois signaux en séquence :

1. Une rafale de FileCreate dans un seul répertoire de staging.
2. Un FileCreate subséquent plus du DataExtend qui roule sur une seule archive, dont la taille finale approxime la somme des fichiers stagés.
3. Un sweep de suppression du répertoire de staging peu après la fermeture de l'archive.

Chaque signal seul est bruyant. Combinés ils sont diagnostiques. Filtre sur FileCreate dans \AppData\Local\Temp\, \Users\Public\, \Downloads\ et autres emplacements inscriptibles de l'arbre utilisateur, puis clusterise par répertoire parent et cherche >50 creates en 60 secondes. Cette cadence attrape le staging de vol par insider et la plupart des charges d'infostealers. Laisse tomber les chemins de build connus (node_modules\, target\, Debug\, Release\, obj\, .next\, dist\) du filtre ; ils produisent des rafales de forme identique et domineront tes résultats sinon.

Staging de cloud-sync

OneDrive, Dropbox, Google Drive et Box maintiennent tous un dossier de sync local et poussent tout ce qu'il y a dedans au moment où l'agent le récupère. Le journal expose deux motifs diagnostiques :

RenameNewName en masse vers le dossier de sync. Le nouveau parent est \Users\<u>\OneDrive\, \Users\<u>\Dropbox\, \Users\<u>\Google Drive\ ou \Users\<u>\Box\ ; l'ancien parent est Desktop\, Documents\ ou Downloads\. La moitié rename préserve la référence parent originale du fichier, ce qui veut dire que tu peux prouver la provenance même après que le fichier soit parti.

DataExtend | Close sur des fichiers dans le dossier de sync sans FileCreate d'app utilisateur correspondant. Ce sont les écritures de l'agent lui-même — des téléchargements du côté cloud vers la copie locale. Les creates sont ce que tu veux pour la direction upload. Les agents de sync en arrière-plan comme OneDrive.exe et Dropbox.exe écrivent aussi des fichiers log dans leurs sous-répertoires AppData\Local\, ce qui te donne une autre façon d'encadrer l'activité si la preuve de rename est rare.

Moins courant mais bon à savoir : certains opérateurs scriptent un Copy-Item vers une jonction ou un symlink qui pointe vers le dossier cloud, ce qui produit des enregistrements ReparsePointChange en plus de la paire rename.

BITS, outils d'upload natifs et exfil living-off-the-land

Un motif que j'ai vu plus souvent dans les engagements ransomware récents : l'opérateur utilise bitsadmin.exe ou Start-BitsTransfer de PowerShell pour pousser des fichiers vers l'extérieur, parfois vers du stockage cloud contrôlé par l'attaquant avec des certificats valides. Le journal montre :

• FileCreate de fichiers d'état de jobs BITS sous \ProgramData\Microsoft\Network\Downloader\ (correspondant à qmgr.db, qmgr0.dat, qmgr1.dat).
• Pour les uploads, les fichiers sources stagés dans \Users\<u>\AppData\Local\Microsoft\BITS\ juste avant le transfert.

Apparie avec les IDs d'événement Microsoft-Windows-Bits-Client%4Operational.evtx 59 (job créé), 60 (job transféré) et 61 (job terminé) — le pont EVTX pour l'exfil BITS est l'une des corrélations les plus propres disponibles.

Même histoire pour rclone.exe et MEGAsync.exe. Ils produisent des signatures prévisibles de file-create dans leurs répertoires d'app et fichiers log ; vérifie \Users\<u>\AppData\Roaming\rclone\ pour la configuration qui liste la destination.

Heuristiques qui méritent leur place

Après assez d'engagements, les heuristiques qui marquent constamment de l'exfil réel :

Rafale de creates. Plus de N événements FileCreate dans un seul répertoire en T secondes. Tune à la baseline ; N=50, T=60 est le point de départ pour les hôtes desktop.

Archive après rafale. Un seul FileCreate d'un fichier avec une extension .zip, .7z, .rar, .tar.gz, .tar.zst ou .iso dans les minutes suivant une rafale de creates, avec du DataExtend qui roule s'accumulant à plusieurs Mo. La taille d'archive correspond grossièrement à la taille cumulée des fichiers stagés.

Rename de masse au-delà des limites de répertoire. Des enregistrements RenameNewName dont le chemin du nouveau parent est structurellement différent de l'ancien — Documents\ vers OneDrive\, Desktop\ vers Users\Public\, Downloads\ vers \AppData\Local\Microsoft\BITS\. Facile à exprimer en regex sur les chemins complets résolus par MFT.

Rafales hors heures. N'importe lequel des précédents en dehors des heures de travail normales de l'utilisateur. Croise avec les logons 4624 de Security.evtx pour les frontières de session réelles.

Sweep de suppression après archive. Un cluster FileDelete sur le répertoire de staging après que l'archive soit fermée. C'est l'utilisateur qui essaie de faire le ménage. La forme du cluster — beaucoup de fichiers supprimés en quelques secondes, tous partageant un parent — est inhabituelle hors des workflows dev/build.

Le parser sur cette page expose des filtres par fenêtre temporelle et par raison qui font de la détection de rafales et du clustering de rename un clic chacun. Pour l'analyse hors heures, exporte en CSV et pivote sur heure-du-jour.

Ce que tu ne verras pas dans $UsnJrnl

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

• Upload direct depuis la mémoire via un POST navigateur, Invoke-WebRequest -InFile depuis une variable, ou curl qui pipe depuis Get-Content. Rien n'atterrit sur disque.
• Lecture depuis un partage réseau que le côté source ne possède pas. Le journal sur ton hôte n'a rien parce que le fichier n'a pas vécu là.
• Capture d'écran comme exfil. Seuls les fichiers de capture atterrissent sur disque ; les données réelles partent via l'image rendue.
• Impression. Ne laisse que l'activité \Windows\System32\spool\PRINTERS\, qui est son propre artefact forensique.
• Tunneling DNS ou ICMP. Rien ne touche le disque ; pivote vers les captures réseau et l'événement 3 Sysmon.

Pour celles-ci, pivote vers EVTX, les connexions réseau Sysmon (événement 3), historique navigateur, SRUM pour les octets réseau par processus, dumps RAM, ou les artefacts PRINTERS spool. La page tactique Exfiltration de MITRE ATT&CK liste chaque technique avec des notes sur où elle laisse vraiment des résidus.

Un exemple travaillé

Le genre de CSV que tu pourrais exporter d'un engagement réel pour démontrer l'exfil :

Cette timeline est une preuve accablante. Sans le journal tu la reconstituerais à partir du registre, Prefetch, shadow copies et les logs propres d'OneDrive — cinq fois le boulot, la moitié de la confiance.

Lectures complémentaires

• MITRE ATT&CK — la tactique Exfiltration et T1074 Data Staged pour la taxonomie complète.
• CISA, ressources insider threat — les hypothèses de base et seuils de détection de leur playbook sont proches de ce qui tient en environnement corporate réel.
• The DFIR Report — plusieurs intrusions au format long documentent le motif exfil-puis-chiffrer pas à pas, avec des preuves USN dans la timeline. Ce qui se rapproche le plus d'un corpus vérité-terrain public sur la façon dont ces motifs apparaissent en pratique.