TL;DR Executive
- Les traces USB sur Windows reposent sur une corrélation multi-artefacts (registre, SetupAPI, journaux sécurité), pas sur un artefact unique « parfait » [1][3][5][6].
SetupAPI.dev.logdocumente l’installation de périphériques et permet d’ancrer des premiers branchements, mais avec des nuances de fuseau/horodatage local [1][3][5].- Les événements de sécurité 6416/6419 améliorent la visibilité opérationnelle (reconnaissance de périphérique, requête de désactivation), surtout pour la détection en entreprise [6][7].
- L’attribution d’exfiltration exige de relier périphérique + utilisateur + activité fichiers/processus; la simple présence d’un USB n’est pas probante à elle seule [2][4][10].
- Les politiques de contrôle matériel (GPO/Defender Device Control) réduisent le risque et produisent des traces d’audit utiles au contentieux [9][10][11].
- Les divergences principales portent sur la fiabilité de certains timestamps historiques (pré-Windows 8) et la couverture inégale selon versions d’OS [1][3][12].
- Niveau de confiance global: élevé sur les mécanismes Windows documentés; modéré sur la reconstruction fine d’intention d’exfiltration sans artefacts complémentaires.
Problématique et objectifs
Question de recherche. Comment établir, avec un niveau probatoire défendable, qu’un périphérique USB/externe a été utilisé pour une exfiltration de données et reconstruire une timeline fiable?
Objectifs.
- Identifier les artefacts techniques les plus robustes.
- Évaluer leurs limites (faux positifs, ambiguïtés temporelles, attribution utilisateur).
- Proposer une méthodologie de corrélation adaptée au contexte d’expertise.
Méthodologie
- Stratégie de recherche: revue croisée de sources institutionnelles (Microsoft, NIST, MITRE, CISA) + sources DFIR spécialisées.
- Critères d’inclusion: source identifiable, contenu technique vérifiable, utilité directe pour acquisition/attribution/timeline USB.
- Critères d’exclusion: billets purement marketing sans détails techniques reproductibles; duplications non substantielles.
- Nombre d’URL analysées: 12 (dans la plage exigée 10–100).
- Cadre d’évaluation crédibilité: autorité, vérifiabilité, qualité éditoriale, fraîcheur, biais (grille skill).
- Limites méthodologiques: certaines sources académiques primaires récentes étaient inaccessibles (403/anti-bot) au moment de la collecte; compensation par sources officielles et DFIR corroborées.
Cadre conceptuel / technique
- Windows consigne l’installation de périphériques via SetupAPI.dev.log [5].
- Les événements sécurité 6416 (nouveau périphérique externe reconnu) et 6419 (requête de désactivation) enrichissent la télémétrie PnP [6][7].
- Les artefacts registre centraux restent
Enum\USB*,USBSTOR,MountedDevices,DeviceClasseset hives utilisateurs (ex. contexte de session) [1][2]. - Dans une perspective IR/forensique, la preuve doit être contextualisée juridiquement et techniquement, pas réduite à un indicateur isolé [8].
Analyse critique des résultats
1) Preuve de présence/connexion du périphérique
Les sources convergent: l’existence d’entrées USBSTOR/Enum + SetupAPI donne une preuve solide qu’un périphérique a été introduit sur l’hôte [1][2][5]. Microsoft confirme explicitement le rôle de SetupAPI pour journaliser les installations [5].
« The name of this log file is SetupAPI.dev.log, and it is located, by default, in %SystemRoot%\inf. » [5]
En pratique, cette couche répond à « quel périphérique a été vu par le système? » mais pas encore à « quel fichier a été copié? ».
2) Reconstruction temporelle (timeline)
Les timestamps ne se valent pas. Les praticiens DFIR rappellent que certaines approches historiques (LastWrite de clés registre) exigent prudence; Windows 8+ a introduit des propriétés plus explicites (last arrival/removal) selon travaux spécialisés [12].
Par ailleurs, SetupAPI (souvent heure locale) doit être harmonisé avec d’autres journaux parfois en UTC pour éviter des erreurs d’interprétation [2][3][6].
3) Attribution d’exfiltration
MITRE formalise l’exfiltration sur média physique (T1052.001) comme technique d’attaque réelle, y compris en contextes air-gap [3]. Toutefois, la reconnaissance d’un périphérique (p.ex. 6416) ne démontre pas automatiquement la copie de données sensibles [6].
L’attribution robuste requiert une chaîne corrélée: insertion périphérique + activité utilisateur/processus + accès/lecture/copie de fichiers sensibles + éventuelles traces EDR/DLP [4][10][11].
« This event generates every time a new external device is recognized by a system. » [6]
4) Valeur probatoire et gouvernance
Le cadre NIST insiste sur l’intégration de la forensique à la réponse incident avec précautions de conformité légale [8]. En entreprise, les contrôles préventifs (GPO, Defender Device Control) servent à la fois de réduction de risque et de génération d’artefacts d’audit exploitables [9][10].
CISA renforce l’axe prévention (désactivation Autorun, séparation des usages, chiffrement), utile pour argumenter la diligence organisationnelle [11].
Discussion
Pour un litige d’exfiltration USB, la meilleure pratique n’est pas « trouver un artefact roi », mais construire une convergence entre: 1) identification matérielle du support, 2) chronologie cohérente multi-sources, 3) lien opérateur (compte/session/processus), 4) matérialité de la donnée exportée.
Cette approche réduit les contestations sur les ambiguïtés de logs isolés. Elle permet aussi d’expliquer clairement au tribunal la différence entre connexion de périphérique et exfiltration effective.
Limites et incertitudes
- Hétérogénéité forte selon versions Windows, politiques d’audit et outils EDR déployés [5][6][10].
- Certains artefacts peuvent être absents (journalisation non activée) ou partiellement altérés (rotation, nettoyage, anti-forensics).
- Une part de littérature pratique provient d’éditeurs/outils forensiques (biais commercial possible), compensée ici par la triangulation avec Microsoft/NIST/MITRE/CISA [2][5][8][11].
Conclusion
La forensique USB probante repose sur une corrélation hiérarchisée des traces système et sécurité, et non sur un seul indicateur. Les artefacts SetupAPI/registre/événements 6416-6419 fournissent une base technique solide pour établir la présence et la chronologie de périphériques [1][5][6][7]. La qualification d’exfiltration exige toutefois des preuves complémentaires d’activité de copie et d’attribution utilisateur/processus [3][4][10]. En contexte expert, l’approche la plus défendable combine acquisition rigoureuse, normalisation temporelle, et narration probatoire explicite.
Références
- [Usb history viewing] — Forensics Wiki, s.d — https://forensics.wiki/usb_history_viewing/
- [Digital Forensics: Artifact Profile – USB Devices] — Magnet Forensics, 2025 — https://www.magnetforensics.com/blog/artifact-profile-usb-devices/
- [Exfiltration Over Physical Medium: Exfiltration over USB (T1052.001)] — MITRE ATT&CK, maj. 2025 — https://attack.mitre.org/techniques/T1052/001/
- [Automated Exfiltration (T1020)] — MITRE ATT&CK, s.d — https://attack.mitre.org/techniques/T1020/
- [SetupAPI Device Installation Log Entries] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries
- [6416(S) A new external device was recognized by the System] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-6416
- [6419(S) A request was made to disable a device] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-6419
- [NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response] — NIST, 2006 — https://csrc.nist.gov/pubs/sp/800/86/final
- [Manage Device Installation with Group Policy] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/client-management/client-tools/manage-device-installation-with-group-policy
- [Device control in Microsoft Defender for Endpoint] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/defender-endpoint/device-control-overview
- [Using Caution with USB Drives] — CISA, s.d — https://www.cisa.gov/news-events/news/using-caution-usb-drives
- [Windows 8 New Registry Artifacts Part 1 – New Device Timestamps] — Swift Forensics, 2013 — https://www.swiftforensics.com/2013/11/windows-8-new-registry-artifacts-part-1.html
