Registry Parser
← Tous les articles

Forensique ShellBags : l'artefact brouillon qui clôt les dossiers

8 min de lecture

ShellBags est l'artefact dont les analystes se plaignent puis sur lequel ils s'appuient quand même. Le format est gênant, l'analyse est contestée, la documentation est incomplète, et les données clôturent des affaires que rien d'autre ne peut clôturer. Chaque praticien DFIR sérieux finit par faire la paix avec eux.

Voici ce qu'ils contiennent réellement, où sont les pièges d'analyse, et comment les utiliser sans se faire avoir.

Ce qu'Explorer enregistre

Explorer doit se souvenir des paramètres d'affichage par dossier : ordre de tri, largeurs de colonnes, mode d'affichage, positions des icônes. Stocker ces données est le but de surface de ShellBags. L'effet de bord qui nous intéresse est que stocker cela nécessite d'enregistrer chaque dossier que l'utilisateur a ouvert, y compris les dossiers sur médias amovibles et partages réseau.

Les données vivent dans deux structures parallèles : BagMRU (un arbre miroir de la hiérarchie de dossiers que l'utilisateur a parcourue, chaque nœud portant un MRUListEx et un ID numérique), et Bags (un tableau plat d'enregistrements bag indexés par ces ID, tenant les paramètres d'affichage réels plus les horodatages).

Sur Windows moderne (7 et ultérieur), les copies significatives vivent dans UsrClass.dat sous Local Settings\Software\Microsoft\Windows\Shell\BagMRU et \Bags. NTUSER.DAT a aussi un Software\Microsoft\Windows\Shell\BagMRU, mais sur Windows moderne il est presque vide. UsrClass est où ça se passe.

ItemID : les éléments shell embarqués

La partie intéressante est ce que chaque nœud BagMRU contient. Les noms de valeurs sont des entiers (0, 1, 2, ...), et la donnée est une structure SHITEMID sérialisée. Même format que le SHITEMID enfoui dans un fichier LNK. Même format que les éléments dans les jump lists. Une fois que vous savez en analyser un, vous pouvez analyser les autres.

Le SHITEMID est étiqueté avec un octet de type qui vous dit quel genre d'élément shell c'est :

  • 0x1F : dossier racine (Mon ordinateur, Corbeille, Panneau de configuration).
  • 0x2F : lettre de lecteur (avec l'identifiant de volume).
  • 0x31, 0x32 : entrées de dossier du système de fichiers, avec un nom court ou long, horodatages FAT/NTFS, et taille de l'entrée.
  • 0x3A : entrée du système de fichiers, variante moins courante.
  • 0x41, 0x42 : emplacements réseau (chemins UNC, partages mappés).
  • 0x71 : Panneau de configuration.

Pour les dossiers sur volumes NTFS locaux, vous obtenez le nom du dossier, l'horodatage modifié, l'horodatage d'accès, l'horodatage de création, et (sur Windows plus récent) le numéro d'entrée MFT plus la séquence. Cette dernière partie est le lien vers le MFT : vous pouvez résoudre une entrée ShellBag directement à un enregistrement MFT sans jamais toucher au système de fichiers.

Pour les dossiers sur médias amovibles, vous obtenez les mêmes données plus le numéro de série du volume. C'est comment vous reconstruisez l'usage USB même après que la clé a été jetée à la rivière. Le Bag a encore les horodatages et le nom.

Le problème d'écriture paresseuse

Explorer n'écrit pas dans BagMRU à chaque navigation. Il écrit quand les paramètres d'affichage changent, quand le dossier est fermé, ou quand le processus Explorer se termine proprement. Cela produit trois modes d'échec qui mordent les analystes :

Les dossiers que l'utilisateur a ouverts n'apparaissent pas. Si l'utilisateur a ouvert un dossier, regardé la vue par défaut, et fermé Explorer avec le bouton X, le bag peut ne jamais être écrit. Aucun journal de cela.

Les horodatages ne reflètent pas la navigation. L'heure de modification du Bag reflète la dernière écriture, pas la dernière visite. Si l'utilisateur a revisité un dossier mais n'a changé aucun paramètre d'affichage, aucune écriture n'a eu lieu, et l'horodatage est périmé.

Les valeurs LastWrite de sous-clés ne sont pas des horodatages d'activité utilisateur. Le LastWrite d'une sous-clé BagMRU ne se met à jour que quand ses enfants changent. Les gens mésinterprètent cela tout le temps.

Ce sur quoi vous pouvez compter : l'existence d'un ShellBag signifie que l'utilisateur y a navigué à un moment, et le nom du dossier, la référence MFT, et le numéro de série du volume sont corrects. Ce sur quoi vous ne pouvez pas compter : l'heure de modification du Bag comme événement de navigation précis. Recoupez avec LNK, jump lists, et le journal USN pour les événements d'accès réels.

Reconstruction de médias amovibles

C'est là que ShellBags devient irremplaçable. La chaîne :

  1. ShellBag a un nœud 0x2F avec la lettre de lecteur du volume et son numéro de série.
  2. Sous ce nœud, l'arbre BagMRU enregistre chaque dossier que l'utilisateur a ouvert sur le périphérique.
  3. La clé MountedDevices de la ruche SYSTEM mappe les lettres de lecteur aux ID de volume au moment des écritures du ShellBag.
  4. L'historique des périphériques USB sous SYSTEM\ControlSet001\Enum\USBSTOR donne le fournisseur, le produit et le numéro de série du périphérique.

Reliez ces quatre éléments et vous pouvez dire : "Sur l'hôte X, l'utilisateur Y a branché un Kingston DataTraveler avec le numéro de série Z, et a navigué dans ces dossiers." La clé USB est partie ; le registre s'en souvient.

La reconstruction est la même sur les partages réseau. Le ShellBag enregistre le chemin UNC, le nom du partage, et la hiérarchie de dossiers parcourue. Si le partage n'existe plus, le bag a encore le chemin.

Survie après suppression de dossier

Les ShellBags persistent après que le dossier sous-jacent est supprimé. Parfois pendant des années. J'ai sorti des bags référençant des dossiers supprimés il y a trois mises à niveau Windows. Pour la question "cet utilisateur a-t-il ouvert ce dossier", où le dossier a été supprimé dans une tentative de nettoyage, ShellBags répond oui si la réponse est oui. Si l'utilisateur supprime tout son profil, le UsrClass.dat part avec. Si seulement le dossier est supprimé, le bag reste.

Outils qui le font bien, et outils qui le font mal

L'analyse ShellBag est l'un des artefacts où la qualité de l'outil compte le plus. Le format a changé entre versions Windows, les structures SHITEMID ne sont pas exhaustivement documentées, et de petits bugs d'analyse mènent à une perte silencieuse de données.

Outils qui gèrent ShellBags correctement :

  • ShellBagsExplorer d'Eric Zimmerman. L'implémentation de référence selon moi. Gère toutes les variantes SHITEMID connues, affiche la hiérarchie complète, et fait remonter les numéros de série de volume et les références MFT là où ils sont présents.
  • Le plugin shellbags de RegRipper (et son compagnon shellbags_xp). Solide pour les flux en ligne de commande. Le plugin est bien commenté et mérite d'être lu pour comprendre ce qu'il extrait.

Outils à utiliser avec prudence :

  • La plupart des implémentations Python ad-hoc sur GitHub. La moitié qui gèrent 0x31 correctement manquent souvent les éléments réseau 0x42 ou les blocs d'extension Property Storage modernes. Testez contre une ruche au contenu connu avant d'en faire confiance.
  • Les navigateurs registre génériques qui vous montrent l'arbre BagMRU mais ne décodent pas le SHITEMID embarqué. Vous voyez la valeur binaire et c'est tout.

Si un outil vous donne une sortie ShellBag et que vous ne pouvez pas dire à partir de la sortie s'il a analysé toutes les variantes SHITEMID, supposez qu'il ne l'a pas fait. Lancez un second outil et comparez.

Cas limites qui piègent les gens

Par utilisateur, pas par hôte. ShellBags sont dans UsrClass et NTUSER. Si vous n'analysez que le profil de l'admin, vous voyez l'historique de l'admin, pas celui de l'utilisateur suspect.

Profils itinérants. Sur un domaine avec profils itinérants, des ShellBags d'une machine peuvent apparaître sur une autre via la synchro de profil. Le bag ne sait pas sur quelle machine il a été écrit. Recoupez avec Prefetch et EVTX sur l'hôte suspecté.

Plusieurs sessions peuvent écraser. Avec plusieurs fenêtres Explorer ouvertes, l'ordre MRU reflète la fenêtre qui a mis à jour en dernier, pas l'accès chronologique. Traitez la position MRU comme approximative.

Les dossiers spéciaux utilisent des GUID connus. Bureau, Documents, Téléchargements sont représentés comme GUID plutôt que chemins. Un outil qui ne résout pas {B4BFCC3A-DB2C-424C-B029-7FE99A87C641} en "Bureau" vous laissera perplexe.

L'extension Property Storage. Les éléments ShellBag plus récents portent des blocs d'extension avec données de magasin de propriétés sérialisées (entrée MFT, séquence, taille de fichier, horodatages additionnels). Les analyseurs plus anciens ne les voient pas.

Un flux qui clôt les dossiers

Pour une question "cet utilisateur a-t-il ouvert ce fichier depuis ce périphérique" :

  1. Extrayez UsrClass.dat pour l'utilisateur. Aussi NTUSER pour les bags hérités.
  2. Analysez avec ShellBagsExplorer. Notez les chemins BagMRU et les horodatages.
  3. Recoupez l'historique USB depuis SYSTEM Enum\USBSTOR. Faites correspondre les numéros de série de volume.
  4. Pivotez vers les fichiers LNK dans Recent\ pour tout dossier correspondant. Le LNK ajoute des horodatages d'accès précis.
  5. Pivotez vers les jump lists pour les applications qui ont ouvert des fichiers dans ces dossiers.
  6. Si le fichier est sur l'hôte, le MFT vous donne les horodatages. S'il a été supprimé, le journal USN peut avoir l'événement de suppression.

Cette séquence a répondu à "cette exfiltration s'est-elle faite via USB" pour moi plus de fois que je ne peux compter. Le ShellBag est l'ancre ; les autres artefacts sont la corroboration.

Pour aller plus loin

ShellBags sont brouillons. Ils sont aussi l'un des rares artefacts qui récupèrent l'activité utilisateur après suppression de dossier, après retrait du périphérique, et à travers les mises à niveau système. Faites la paix avec le format. Les données valent la friction.