ShellBags et clés USB : un cas d'investigation commenté

TL;DR. Dans ce cas fictif, les ShellBags de svc_backup sur le poste FIN-WKS-07 montrent, en 45 minutes : une navigation dans Downloads\tools.zip, un nouveau dossier sous ProgramData\Intel, le partage \\FILESRV01\Finance (Payroll, puis Board), et E:\exfil\finance_2026 sur un second lecteur. Les ShellBags prouvent que le compte a navigué vers chaque dossier et donnent l'ordre et des heures approximatives. Ils ne prouvent la copie d'aucun fichier. Le rapport énonce la navigation, puis désigne les artefacts qui peuvent prouver le reste.

Scénario fictif. Tout ce qui suit repose sur les ruches synthétiques du bouton Essayer un exemple du ShellBags Parser : le compte, le poste, le partage, le SID et les heures sont inventés. Le cas prolonge la même histoire que les sites parseurs frères (un compte de service malveillant sur FIN-WKS-07). Aucune organisation ni personne réelle n'est concernée.

La question

L'équipe finance signale que des documents du conseil d'administration sont apparus sur un site de partage. Le SOC observe une ouverture de session interactive de svc_backup, un compte de service qui ne devrait jamais ouvrir de session interactive, sur FIN-WKS-07 le 2026-09-14. Question posée aux ShellBags : quels dossiers ce compte a-t-il parcourus dans l'Explorateur, et dans quel ordre ?

La collecte

L'intervenant a collecté C:\Users\svc_backup\NTUSER.DAT et ...\AppData\Local\Microsoft\Windows\UsrClass.dat, avec leurs fichiers .LOG1/.LOG2, via la cible KAPE RegistryHivesUser (voir où sont stockés les ShellBags). Aucune des ruches n'était sale. La clé racine de UsrClass est S-1-5-21-3623811015-3361044348-30300820-1119_Classes, et les Shell Folders de NTUSER pointent vers C:\Users\svc_backup : les deux ruches sont attribuées au même compte.

Ce que montre le parseur

Déposer les deux ruches dans le ShellBags Parser donne 20 entrées. Avec Signalés uniquement coché, les entrées intéressantes sont :

Chemin	Type	Date utilisée	Signaux	MFT (entrée/séq.)
`My Computer\C:\Users\svc_backup\Downloads\tools.zip\x64`	répertoire dans une archive	dernière interaction 10:07:20	archive	0 (sans signification)
`My Computer\C:\ProgramData\Intel`	répertoire	dernière interaction 10:09:05	modifiable par l'utilisateur	91233/1
`\\FILESRV01\Finance`	réseau	dernière interaction 10:31:07	réseau	n/a
`\\FILESRV01\Finance\Payroll`	répertoire	dernière écriture de la clé 10:32:40	réseau	70112/1
`\\FILESRV01\Finance\Board`	répertoire	dernière interaction 10:36:18	réseau	70140/1
`My Computer\E:\exfil`	répertoire	dernière interaction 10:45:51	autre lecteur	35/1
`My Computer\E:\exfil\finance_2026`	répertoire	dernière interaction 10:45:51	autre lecteur	36/1

Toutes les heures du 2026-09-14, en UTC. « Dernière interaction » signifie que l'entrée était première dans le MRUListEx de son parent et reprend le LastWrite de la clé parente ; « dernière écriture de la clé » est celle de la clé de l'entrée elle-même. La différence compte : voir les horodatages des ShellBags expliqués.

Lecture, entrée par entrée

1. La boîte à outils dans un ZIP

tools.zip est un item file entry sous Downloads, et x64 se trouve sous lui dans l'arborescence. L'utilisateur a donc ouvert le ZIP dans l'Explorateur comme un dossier compressé et navigué dans son répertoire x64. Les dates embarquées du ZIP (création 10:06:12, modification 10:06:40, accès 10:07:02) sont ses dates dans le système de fichiers au moment de l'enregistrement de l'item, ce qui correspond à un téléchargement vers 10:06. La clé tools.zip a été écrite pour la dernière fois à 10:07:20 avec x64 en première position MRU : navigation dans l'archive vers 10:07.

Ce que cela ne montre pas : l'extraction. Parcourir un ZIP dans l'Explorateur ne l'extrait pas. Cherchez les fichiers extraits dans la MFT et le journal USN. Plus de détails dans ShellBags et fichiers ZIP.

2. Un nouveau dossier dans ProgramData

C:\ProgramData\Intel a eu sa dernière interaction à 10:09:05. Sa date de création embarquée est 10:09:00, alors que ProgramData date du 2026-09-01. Un dossier au nom d'éditeur créé une minute avant d'être parcouru, dans un emplacement modifiable par l'utilisateur : schéma classique de staging. La référence MFT (entrée 91233, séquence 1) permet d'extraire son enregistrement et ses enfants de la $MFT. Si des artefacts d'exécution sont disponibles (Prefetch, Amcache, BAM dans le registre), vérifiez ce qui a été exécuté depuis ce dossier.

3. Le partage finance

Trois faits :

\\FILESRV01 était l'enfant le plus récent de Network, et Finance l'enfant le plus récent de \\FILESRV01, lors de l'écriture de ces clés à 10:31:07.
Le MRUListEx de Finance vaut 1, 0 : Board (slot 1) a été utilisé après Payroll (slot 0).
Board hérite du LastWrite de Finance, 10:36:18. Payroll, non ; le LastWrite de sa propre clé (10:32:40), sans sous-clé, approche le moment où son entrée a été enregistrée.

Formulation solide : « Le compte a navigué vers \\FILESRV01\Finance\Payroll puis vers \\FILESRV01\Finance\Board ; Board était le sous-dossier le plus récemment utilisé de Finance à 10:36:18 UTC. » Les références MFT embarquées (70112, 70140) sont celles du NTFS du serveur de fichiers, utiles quand vous examinerez FILESRV01. Côté serveur, l'audit des accès aux partages (événements de sécurité 5140 et 5145, s'il est activé) peut confirmer la session et les fichiers touchés.

4. Le second lecteur

E: était l'enfant le plus récent de My Computer à 10:45:51, et exfil\finance_2026 a été parcouru à ce moment. Selon leurs dates embarquées, exfil a été créé à 10:40 et finance_2026 à 10:45. Tous deux portent des références MFT : le volume E: était donc formaté en NTFS à ce moment ; des numéros d'entrée bas comme 35 et 36 correspondent à ce qu'on attend d'un volume fraîchement formaté, une piste à vérifier plutôt qu'une conclusion.

Le parseur le signale « Autre lecteur (USB ?) » parce que la lettre n'est pas C:. Les ShellBags seuls ne peuvent pas dire qu'il s'agissait d'un périphérique USB. Cela vient de l'historique des périphériques de la ruche SYSTEM, des journaux setupapi et des journaux d'événements, ainsi que des fichiers LNK dont le numéro de série de volume correspond.

5. La Corbeille à 10:50

La clé racine BagMRU a été écrite pour la dernière fois à 10:50:03 avec Recycle Bin en première position. Le compte a ouvert la Corbeille cinq minutes après l'activité sur E:. Isolé, c'est anecdotique. Dans ce contexte, c'est une raison d'analyser $Recycle.Bin (parseur de Corbeille) pour savoir ce qui a été supprimé.

La chronologie

Heure (UTC)	Constatation ShellBags	Artefact suivant à vérifier
~10:02	Première activité Explorateur dans l'arborescence NTUSER (`My Computer\C:`)	Événements d'ouverture de session (4624 type 2/10)
~10:07	Navigation dans `Downloads\tools.zip\x64`	MFT/USN pour l'extraction, Zone.Identifier
10:09	`ProgramData\Intel` (créé à 10:09)	Prefetch/Amcache/BAM pour les binaires qui s'y trouvent
10:31–10:36	`\\FILESRV01\Finance`, `Payroll`, puis `Board`	LNK/Jump Lists, 5140/5145 sur le serveur
10:40–10:45	`E:\exfil`, `finance_2026` créés et parcourus	Historique USB, numéro de série de volume dans les LNK
10:50	Corbeille	Fichiers `$I` de `$Recycle.Bin`

Ce que les ShellBags ne peuvent pas dire

Qu'un fichier a été ouvert, copié ou envoyé.
Que E: était un périphérique USB, ni lequel.
Quoi que ce soit fait en console : dans l'histoire associée, les outils en ligne de commande de l'attaquant ne laissent aucun ShellBag.
Qu'aucun autre dossier n'a été parcouru : une session Explorateur sous un autre compte, ou des clés nettoyées, n'apparaîtraient pas.

C'est pourquoi la section du rapport consacrée aux ShellBags est courte et précise, et pourquoi chaque ligne de la chronologie a une colonne « artefact suivant ». Pour le choix des artefacts, voir ShellBags vs fichiers LNK, Jump Lists et RecentDocs.

Reproduire le cas

Ouvrez le ShellBags Parser, cliquez sur Essayer un exemple, cochez Signalés uniquement, puis alternez entre Arborescence et Chronologie. Le guide pas à pas explique chaque panneau.