Forensique USB : retrouver clés, utilisateurs et fichiers

Ce guide vous mène du constat « une clé USB a été branchée » à une conclusion défendable : de quel périphérique il s'agit, quand il a été connecté, quel utilisateur avait une session ouverte et quels fichiers en ont été ouverts. Il couvre le registre, les journaux texte et les journaux d'événements que laissent Windows 10 et 11, les différences entre versions, et une méthode pas à pas applicable à n'importe quel dossier.

Les identifiants qui servent de pivot

Une investigation USB consiste à relier des traces qui portent chacune un identifiant différent. Retenez ces quatre-là avant de commencer :

Le numéro de série du périphérique identifie le matériel. Le VSN identifie le système de fichiers qu'il porte, et c'est le seul identifiant enregistré par les fichiers LNK et les Jump Lists. L'essentiel du travail consiste à relier les deux.

Identifier le périphérique dans la ruche SYSTEM

Tous les chemins ci-dessous sont sous SYSTEM\ControlSet00x\ ; consultez Select\Current pour savoir quel control set était actif.

Enum\USBSTOR

Les périphériques de stockage de masse apparaissent sous Enum\USBSTOR\Disk&Ven_<fabricant>&Prod_<produit>&Rev_<révision>\<numéro de série>. Par exemple :

Enum\USBSTOR\Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00\4C530001230518115455&0

Le suffixe &0 est un numéro d'unité logique ajouté par Windows, il ne fait pas partie du numéro de série matériel. La clé du numéro de série contient notamment les valeurs FriendlyName et ContainerID.

Si le deuxième caractère du numéro de série est & (par exemple 7&2a1b3c4d&0), le périphérique n'expose pas de numéro de série unique et Windows en a généré un. Cet identifiant n'est pas stable d'une machine à l'autre : impossible de s'en servir pour affirmer que « la même clé a été branchée sur les deux postes ».

Enum\USB

Enum\USB\VID_xxxx&PID_yyyy\<numéro de série> recense tous les périphériques USB, pas seulement le stockage : claviers, téléphones, concentrateurs. Le numéro de série y correspond à celui de USBSTOR (sans le &0), ce qui donne le VID/PID d'un périphérique de stockage. ContainerID relie les entrées apparentées entre les sous-arbres Enum.

Horodatages de connexion (Windows 8 et suivants)

Sous chaque clé d'instance du périphérique, la sous-clé Properties\{83da6326-97a6-4088-9453-a1923f573b29} contient des sous-clés numérotées dont la valeur est un FILETIME en UTC :

Seuls le premier et le plus récent événement sont conservés. Sur un système en direct, la clé Properties n'est lisible qu'avec les privilèges SYSTEM : raison de plus pour travailler sur une ruche collectée. Sous Windows 7, rabattez-vous sur les LastWrite des clés et sur le journal setupapi, en les traitant comme des approximations.

MountedDevices

SYSTEM\MountedDevices associe les lettres de lecteur (\DosDevices\E:) et les GUID de volume (\??\Volume{GUID}) aux périphériques. Pour un support amovible, la donnée est une chaîne UTF-16 contenant le chemin USBSTOR et le numéro de série, ce qui relie un numéro de série à une lettre de lecteur et, surtout, à un GUID de volume. Les lettres sont réattribuées au fil du temps : la lettre actuelle ne dit rien de celle qu'avait le périphérique au moment des faits.

Ruche SOFTWARE : Portable Devices et EMDMgmt

SOFTWARE\Microsoft\Windows Portable Devices\Devices liste les périphériques avec un FriendlyName, souvent le nom de volume vu par l'utilisateur pour un stockage, ou le nom de l'appareil pour un téléphone (« Galaxy S23 »). Le nom de la sous-clé contient le numéro de série du périphérique.

SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt est alimentée par ReadyBoost. Les noms de ses sous-clés contiennent le chemin du périphérique, le nom de volume et un nombre final qui est le VSN en décimal ; convertissez-le en hexadécimal pour le comparer aux LNK. Sa présence est aléatoire : EMDMgmt n'est en général pas renseignée quand le disque système est un SSD, soit la plupart des machines récentes. Ne comptez pas dessus.

# Convertir un VSN décimal d'EMDMgmt au format XXXX-XXXX des parseurs LNK
$vsn = 2767329728
'{0:X8}' -f $vsn -replace '(.{4})(.{4})', '$1-$2'

Attribution à l'utilisateur avec MountPoints2

Les ruches SYSTEM et SOFTWARE concernent toute la machine. Pour relier un périphérique à une personne, ouvrez le NTUSER.DAT de chaque utilisateur et regardez :

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{volume GUID}

Si le GUID de volume issu de MountedDevices y figure, le volume a été monté pendant une session interactive de cet utilisateur. Le LastWrite de la sous-clé donne une approximation du dernier montage dans sa session. Associez le profil à son SID via ProfileList et confirmez l'ouverture de session dans les événements Security. MountPoints2 enregistre aussi les partages réseau sous la forme ##serveur#partage, utile quand les données sont parties par un autre chemin.

setupapi.dev.log : la première installation

C:\Windows\INF\setupapi.dev.log (sous XP, C:\Windows\setupapi.log) journalise l'installation des pilotes. À la première détection d'un périphérique, on trouve un bloc de ce type :

>>>  [Device Install (Hardware initiated) - USBSTOR\Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00\4C530001230518115455&0]
>>>  Section start 2026/09/14 09:12:33.412

L'heure de « Section start » est en heure locale de la machine, contrairement au registre : convertissez-la (voir UTC et heure locale). Sur certains systèmes le journal bascule vers des fichiers setupapi.dev.<date>.log, et les mises à jour de fonctionnalités le recréent : collectez tous les setupapi*.log du dossier.

Select-String -Path C:\Windows\INF\setupapi.dev*.log -Pattern 'USBSTOR' -Context 0,1

Journaux d'événements : chaque connexion, pas seulement la première et la dernière

Le registre garde la première et la dernière. Les journaux d'événements donnent chaque connexion, tant qu'ils n'ont pas été écrasés.

Partition/Diagnostic 1006 est le plus précieux, car il peut inclure le secteur d'amorçage de volume (VBR) de chaque partition. Le VSN s'y trouve à un décalage fixe (0x43 en FAT32, 0x48 en NTFS, 0x64 en exFAT) : on peut donc le retrouver dans l'événement et relier directement un numéro de série matériel aux fichiers LNK, même quand EMDMgmt est vide. Ce canal est petit et tourne vite : vérifiez son plus ancien enregistrement avant de tirer une conclusion d'une absence. Les noms de champs varient selon les builds, fiez-vous au XML de l'événement plutôt qu'aux noms de colonnes d'un seul parseur.

# N'extraire que les événements utiles à l'USB depuis un dossier de journaux collecté
EvtxECmd.exe -d E:\case\C\Windows\System32\winevt\Logs --csv E:\out\evtx --inc 1006,400,410,2003,2100,2102,6416

# Aperçu rapide sur un système en direct
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Partition/Diagnostic'; Id = 1006 } |
  Select-Object TimeCreated, Id, Message -First 20

L'EVTX Parser est pratique pour examiner un canal exporté dans le navigateur.

Du périphérique aux fichiers : VSN, LNK, Jump Lists et ShellBags

Une fois le VSN connu, basculez vers les artefacts d'activité utilisateur (détaillés dans ShellBags, fichiers LNK et Jump Lists) :

• Fichiers LNK : filtrez la sortie de LECmd sur DriveSerialNumber égal au VSN et DriveType amovible. Chaque résultat est un fichier ouvert depuis ce volume, avec son chemin, les horodatages de la cible et les dates de création/modification du raccourci.
• Jump Lists : les mêmes champs dans la sortie de JLECmd, plus l'application utilisée et le dernier accès DestList.
• ShellBags : les dossiers parcourus sur la lettre de lecteur qu'avait le périphérique pendant la fenêtre de connexion. Les ShellBags ne stockent pas le VSN : reliez-les par la lettre et l'heure.
• OpenSavePidlMRU et LastVisitedPidlMRU : fichiers enregistrés vers, ou choisis depuis, cette lettre de lecteur dans les boîtes ouvrir/enregistrer.

# Entrées LNK et Jump Lists pour un numéro de série de volume donné
LECmd.exe -d E:\case\C\Users --csv E:\out\lnk
JLECmd.exe -d E:\case\C\Users --csv E:\out\jl
Import-Csv (Get-ChildItem E:\out\lnk\*.csv).FullName | Where-Object { $_.DriveSerialNumber -match 'A4F219C0|A4F2-19C0' }

Attention à la portée de cette preuve. Un LNK prouve qu'un fichier a été ouvert depuis le support. Il ne prouve pas qu'un fichier y a été copié : une copie via l'Explorateur ne crée aucun LNK. Pour les copies, examinez la $MFT et le journal USN du volume source, OpenSavePidlMRU pour un « Enregistrer sous » vers le support et, si vous disposez du périphérique, les horodatages de son système de fichiers.

Quand on dispose du périphérique

Si la clé a été saisie, bouclez la démonstration par l'autre bout. Branchez-la derrière un bloqueur d'écriture et faites-en une image avant toute autre opération. Lisez le numéro de série matériel dans les descripteurs USB (sur une station d'analyse Linux, lsusb -v ou udevadm info affichent iSerial) et comparez-le à USBSTOR. Lisez le VSN dans le VBR de chaque partition et comparez-le aux résultats LNK et Jump Lists. Examinez ensuite le système de fichiers du support : fichiers portant les noms des cibles LNK, et leurs dates de création sur le support, qui pour une copie reflètent en général le moment où elle y a été déposée. Un numéro de série, un VSN et des noms de fichiers concordants transforment une déduction tirée du registre en corroboration physique. Si le numéro de série concorde mais pas le VSN, le support a été reformaté après l'ouverture des fichiers.

# Numéro de série matériel et VID/PID d'un périphérique branché, depuis une station Linux
lsusb -v 2>/dev/null | grep -E 'idVendor|idProduct|iSerial'

Téléphones et appareils photo MTP

Les téléphones en mode transfert de fichiers utilisent le protocole MTP (Media Transfer Protocol). Ils apparaissent sous Enum\USB (et sous une entrée SWD\WPDBUSENUM), dans Windows Portable Devices avec leur nom convivial et dans les événements Kernel-PnP, mais pas sous USBSTOR, et sans lettre de lecteur ni VSN. Les ShellBags sont la meilleure trace de navigation : chemins du type Galaxy S23\Internal storage\DCIM\Camera. Les LNK d'éléments ouverts directement depuis un appareil MTP sont moins systématiques que pour le stockage de masse : leur absence n'a pas de valeur probante.

Construire le récit d'exfiltration

Une conclusion solide d'exfiltration par USB repose en général sur cinq éléments :

1. Le périphérique : fabricant, produit, numéro de série (unique, pas généré avec &), VID/PID.
2. La fenêtre : première installation, connexions issues de 1006 ou de Kernel-PnP, dernière arrivée et dernier retrait via 0066/0067.
3. L'utilisateur : MountPoints2 dans son profil, et une ouverture de session interactive correspondante.
4. Les données : entrées LNK et Jump Lists portant le VSN du périphérique, ShellBags sur sa lettre de lecteur, MRU de boîtes de dialogue pointant vers lui, et activité du système de fichiers source dans la fenêtre.
5. L'absence d'alternative : aucune autre session utilisateur, aucun accès à distance à ce moment-là.

Notez chaque horodatage avec sa signification et son fuseau horaire, et énoncez les limites : la « dernière arrivée » est la dernière, pas la seule.

Pièges

• Les mises à jour de fonctionnalités effacent l'historique. Une mise à niveau majeure de Windows peut supprimer les entrées USBSTOR et recréer les journaux setupapi. Vérifiez Windows.old, les clichés instantanés de volume et SYSTEM\Setup\Upgrade\Pnp\CurrentControlSet\Control\DeviceMigration avant de conclure qu'un périphérique n'a jamais été utilisé.
• Se fier à la lettre de lecteur actuelle. Les lettres changent ; utilisez la correspondance valable pendant la fenêtre.
• Comparer entre machines des numéros de série générés par Windows. Ce ne sont pas des identifiants matériels.
• Mélanger les fuseaux horaires. Registre et événements sont en UTC ; setupapi est en heure locale.
• Compter sur les journaux DriverFrameworks-UserMode. Ils sont désactivés par défaut sur les builds récents.
• Prendre un support reformaté pour un autre support. Le VSN change au formatage, le numéro de série matériel non.
• Ne pas analyser les journaux de transactions du registre. L'activité récente d'un périphérique peut ne se trouver que dans SYSTEM.LOG1/.LOG2.

Outils

• Registry Explorer et RECmd (Eric Zimmerman) : signets pour USBSTOR, MountedDevices et MountPoints2 ; les fichiers batch RECmd les exportent en CSV.
• EvtxECmd : maps pour les événements Partition/Diagnostic et Kernel-PnP.
• USB Detective : automatise la corrélation entre registre, setupapi, événements, LNK et Jump Lists ; les éditions commerciales vont plus loin que l'édition communautaire.
• RegRipper : plugins usbstor, usb, mountdev, mp2 pour des rapports texte rapides.
• Les parseurs en ligne de ce site, comme le Registry Parser, pour une ruche isolée.

RECmd.exe -d E:\case\C --bn .\BatchExamples\RECmd_Batch_MC.reb --csv E:\out\registry

Méthode pas à pas

1. Collecter : SYSTEM, SOFTWARE et leurs journaux, chaque NTUSER.DAT, C:\Windows\INF\setupapi*.log, les journaux d'événements, le dossier Recent de chaque profil et les clichés instantanés. Le guide de triage liste les cibles KAPE.
2. Inventorier les périphériques : entrées USBSTOR et USB avec numéros de série, VID/PID et noms conviviaux ; signalez les numéros générés par Windows.
3. Les dater : 0064 à 0067, première installation setupapi (convertie en UTC), puis chaque événement 1006 et Kernel-PnP.
4. Relier les volumes : MountedDevices pour les lettres et GUID de volume ; VSN depuis les données VBR du 1006 ou EMDMgmt.
5. Attribuer : retrouvez le GUID de volume dans le MountPoints2 de chaque utilisateur, associez le profil à un SID, confirmez l'ouverture de session.
6. Trouver les fichiers : entrées LNK et Jump Lists correspondant au VSN, ShellBags sur la lettre de lecteur, MRU des boîtes de dialogue, et activité $MFT/USN côté source pendant la fenêtre de connexion.
7. Rédiger : une frise en UTC avec la signification de chaque horodatage, les identifiants qui relient chaque étape et les zones d'ombre restantes.

Pour le contexte registre derrière ces clés, voir l'investigation du registre Windows, et pour la référence complète des clés USB, la fiche périphériques USB.