Shellbags

Windows mémorise l’apparence de chaque dossier lors de sa dernière consultation dans l’Explorateur : taille et position de la fenêtre, ordre de tri, mode d’affichage et taille des icônes. Ces enregistrements, appelés Shellbags, subsistent après la disparition du dossier, du lecteur USB ou du partage réseau. Cette leçon présente leur emplacement de stockage, la manière de reconstituer les chemins des dossiers à partir de ces données et les limites de fiabilité de leurs horodatages.

Ce que sont les Shellbags et pourquoi ils intéressent les examinateurs

Les Shellbags sont écrits par le shell Windows, qui gère l’Explorateur de fichiers, le Bureau et les boîtes de dialogue standard Ouvrir/Enregistrer. Lorsqu’un utilisateur ouvre un dossier par l’intermédiaire du shell, Windows enregistre la position du dossier dans l’espace de noms du shell (Bureau, Ce PC, E:\, Clients …) dans la ruche de Registre de l’utilisateur, avec un emplacement pour ses paramètres d’affichage. Il n’est pas nécessaire que l’utilisateur modifie l’affichage pour que l’entrée soit créée.

Il s’agit d’un élément de preuve montrant qu’un compte utilisateur précis a accédé à un dossier, y compris à des dossiers autrement difficiles à repérer :

• les dossiers sur des lecteurs amovibles qui ne sont plus connectés ;
• les partages réseau (par exemple \\FILESRV01\Projects) ;
• les dossiers à l’intérieur d’archives ZIP ouvertes dans l’Explorateur en tant que dossiers compressés ;
• les dossiers qui ont ensuite été supprimés, renommés ou effacés de manière sécurisée.

Les données se trouvent dans une ruche propre à l’utilisateur ; elles sont donc attribuées au compte propriétaire de cette ruche (leçon 2.2).

Où ils se trouvent

Sous Windows 7, 8, 10 et 11, la plupart des Shellbags se trouvent dans UsrClass.dat, à l’emplacement C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat :

• Local Settings\Software\Microsoft\Windows\Shell\BagMRU
• Local Settings\Software\Microsoft\Windows\Shell\Bags

Sur un système en cours d’exécution, cette ruche est montée sous HKEY_USERS\<SID>_Classes. NTUSER.DAT contient également Software\Microsoft\Windows\Shell\BagMRU et Software\Microsoft\Windows\Shell\Bags ; sur ces versions, cette ruche contient généralement beaucoup moins d’entrées, mais elle n’en est pas toujours dépourvue : analysez donc les deux ruches.

Lors d’une collecte de triage, attendez-vous à trouver UsrClass.dat accompagné de UsrClass.dat.LOG1 et de .LOG2 : la ruche présente souvent des modifications non consolidées, et les entrées récentes peuvent n’exister que dans les journaux de transactions tant que ceux-ci n’ont pas été rejoués (leçon 2.1).

Structure de l’arborescence BagMRU

BagMRU est une arborescence qui reflète l’espace de noms du shell. La clé BagMRU elle-même constitue la racine (le Bureau). Chaque clé contient :

• Des valeurs numérotées (0, 1, 2 …, REG_BINARY). Chacune contient un_ élément du shell_ : l’identifiant binaire d’un dossier enfant, au format ITEMIDLIST également utilisé dans les fichiers LNK. La sous-clé portant le même numéro contient les enfants de ce dossier ; le chemin complet d’un dossier est donc la chaîne d’éléments allant de la racine jusqu’à lui.
• MRUListEx (REG_BINARY) : les numéros des valeurs enfants sous forme d’entiers petit-boutistes de 4 octets, du plus récemment utilisé au moins récemment utilisé, avec 0xFFFFFFFF comme marqueur de fin.
• NodeSlot (REG_DWORD) : le numéro_ n_ de la clé Bags\<n> qui contient les paramètres d’affichage de ce dossier. Sous Bags\<n>\Shell\<folder type GUID> se trouvent des valeurs telles que Mode, LogicalViewMode, Sort et IconSize ; une sous-clé ComDlg apparaît pour les dossiers consultés au moyen des boîtes de dialogue Ouvrir/Enregistrer.

Les numéros n’ont aucune signification particulière : la valeur 2 est simplement le troisième enfant enregistré sous ce parent.

Types d’éléments du shell

Chaque élément du shell commence par une taille sur 2 octets et un indicateur de type de classe sur 1 octet à l’offset 2, qui indique à l’analyseur comment lire la suite.

Les dossiers à l’intérieur d’une archive ZIP apparaissent sous l’élément correspondant à l’archive elle-même ; c’est l’un des rares cas où un nom de fichier apparaît dans les Shellbags.

Horodatages

Les Shellbags fournissent deux types d’informations temporelles différents ; ne les confondez pas.

Horodatages LastWrite des clés

Chaque clé BagMRU possède un horodatage LastWrite (FILETIME, UTC) : il correspond à la dernière modification d’une valeur quelconque de cette clé, par exemple l’ajout d’un nouvel enfant, le réordonnancement de MRUListEx à la suite d’une nouvelle consultation d’un enfant, ou la création de la clé. Le LastWrite d’un parent indique donc quand sa liste d’enfants a été modifiée pour la dernière fois, et l’enfant en tête de MRUListEx est celui qui est le plus probablement concerné. Il n’existe qu’un horodatage par clé ; les visites antérieures sont écrasées.

Horodatages à l’intérieur des éléments d’entrée de fichier

Un élément d’entrée de fichier (0x31/0x32) stocke, à partir de son début :

Le nom court est suivi d’un bloc d’extension portant la signature 0xBEEF0004. Il contient les horodatages de création et de dernier accès (également au format date/heure DOS), le nom long en UTF-16LE et, sous Windows 10 et 11 pour les dossiers sur NTFS, la référence de fichier du dossier sur 8 octets (numéro d’entrée MFT sur 6 octets, plus numéro de séquence sur 2 octets).

Le format date/heure DOS regroupe une date sur 16 bits (bits 15–9 : année depuis 1980, 8–5 : mois, 4–0 : jour) et une heure sur 16 bits (bits 15–11 : heure, 10–5 : minute, 4–0 : secondes divisées par 2). Les secondes sont stockées par pas de 2 ; ces valeurs peuvent donc différer des horodatages NTFS de 2 secondes au maximum. Les analyseurs tels que SBECmd les présentent en UTC.

Il s’agit des horodatages MAC propres au dossier au moment où l’élément a été écrit, et non des heures de consultation. Ils apportent une aide indirecte : l’élément ne peut pas être antérieur à l’heure de modification qu’il contient, et la référence MFT identifie le dossier dans la $MFT du lecteur (leçon 1.3).

« Première interaction » et « dernière interaction »

Les analyseurs déduisent ces valeurs des horodatages LastWrite. En général, si un dossier figure en tête du MRUListEx de son parent, le LastWrite du parent est présenté comme l’heure de dernière interaction avec le dossier ; si la clé propre au dossier ne possède aucun enfant, son LastWrite est présenté comme l’heure de première interaction, puisque rien n’a modifié cette clé depuis sa création. Il s’agit de déductions, et non de champs stockés. Présentez ces valeurs en indiquant leur source (« la clé BagMRU\1\0\2 a été écrite pour la dernière fois à T, avec 2026 en tête de son MRUListEx »), plutôt que d’affirmer « l’utilisateur a ouvert 2026 à T », et corroborez-les à l’aide des fichiers LNK, des listes de raccourcis (leçon 2.4) et des heures de connexion USB (leçon 2.6).

Ce que les Shellbags prouvent et ne prouvent pas

Les Shellbags étayent l’affirmation selon laquelle ce compte utilisateur a accédé à ce chemin de dossier par l’intermédiaire du shell Windows, au moins une fois, et au plus tard à l’heure LastWrite pertinente. Ils ne prouvent pas :

• qu’un fichier du dossier a été ouvert, copié ou vu : les noms de fichiers ordinaires ne sont pas enregistrés ;
• la durée ou la fréquence des visites de l’utilisateur ;
• que chaque dossier intermédiaire a été ouvert séparément : saisir un chemin complet dans la barre d’adresse crée également des nœuds pour les dossiers situés au-dessus ;
• quel périphérique physique était monté sous E: (utilisez les artefacts de la leçon 2.6 ou la référence MFT).

La suppression d’un dossier ne supprime pas son Shellbag ; seul le nettoyage de la ruche le fait (module 7).

Exemples d’outils : ShellBags Explorer (arborescence graphique), SBECmd (SBECmd.exe -d <hive folder> --csv <out>, une ligne CSV par élément avec le chemin absolu, la position MRU, l’emplacement du nœud, le LastWrite et les horodatages intégrés) et Registry Explorer pour les clés brutes.

Exemple détaillé : E:\Clients\2026\Contracts

Le fichier UsrClass.dat de l’utilisateur mira (Windows 11, journaux rejoués ; E: était un lecteur USB NTFS) contient cette branche :

Chemin. En assemblant les éléments depuis la racine, on obtient E:\Clients\2026\Contracts, dont les paramètres d’affichage se trouvent dans Bags\38.

Horodatages intégrés de l’élément 2026. Le champ de modification contient le mot de date 0x5C62 et le mot d’heure 0x8509. Date : 0x5C62 = 23 650 ; 23 650 >> 9 = 46, donc l’année est 1980 + 46 = 2026 ; (23 650 >> 5) & 0xF = 3 (mars) ; 23 650 & 0x1F = 2. Heure : 0x8509 = 34 057 ; 34 057 >> 11 = 16 heures ; (34 057 >> 5) & 0x3F = 40 minutes ; (34 057 & 0x1F) × 2 = 9 × 2 = 18 secondes. Résultat : 2026-03-02T16:40:18Z. Le bloc 0xBEEF0004 indique une création à 2026-01-05T09:12:44Z et l’entrée MFT 64, séquence 1.

Ce que l’on peut conclure au sujet de E:\Clients\2026 :

1. Le compte mira a accédé par l’intermédiaire du shell à E:\Clients\2026 sur le volume qui était monté sous E:.
2. La clé E:\Clients a été écrite pour la dernière fois à 2026-03-18T14:05:51Z avec 2026 en tête de son MRUListEx : l’affirmation la mieux étayée est que 2026 a été ajouté à la liste des dossiers consultés sous Clients, ou déplacé en tête de cette liste, à ce moment-là.
3. La clé 2026 a été écrite pour la dernière fois à 2026-03-18T14:06:03Z avec Contracts en tête, et la clé Contracts, sans enfant, porte le même horodatage : à 14:06:03Z, l’utilisateur a atteint Contracts en passant par 2026, probablement pour la première fois.
4. Il est impossible de déterminer quand 2026 a été consulté pour la première fois ; les visites antérieures sont écrasées. Les dates intégrées décrivent le dossier et montrent uniquement que l’élément a été écrit au plus tôt à 2026-03-02T16:40:18Z.
5. Rien n’indique quels fichiers de Contracts ont été ouverts. Pour relier E: au lecteur constituant un élément de preuve, recherchez l’entrée MFT 64 dans la $MFT de l’image du lecteur USB : une séquence 1, le nom 2026 et le parent Clients confirmeraient ce lien.

Points clés pour l’examen : Attendez-vous à devoir reconstituer un chemin de dossier complet à partir d’une branche BagMRU, y compris pour des emplacements amovibles ou réseau, et à identifier le compte à partir de la ruche d’origine. Il pourra vous être demandé de fournir un horodatage LastWrite en UTC au format ISO 8601, de le distinguer des horodatages intégrés du dossier ou de faire correspondre un dossier à son entrée MFT. Sachez ce qu’un Shellbag ne prouve pas, en particulier l’ouverture des fichiers qu’il contient.

Points essentiels

• Les Shellbags enregistrent les dossiers consultés par un utilisateur au moyen du shell Windows, avec leurs paramètres d’affichage ; ils persistent après la disparition du dossier, du lecteur ou du partage.
• Sous Windows 7 et versions ultérieures, ils se trouvent principalement dans UsrClass.dat (Local Settings\Software\Microsoft\Windows\Shell\BagMRU et Bags), et en moindre nombre dans NTUSER.DAT (Software\Microsoft\Windows\Shell\BagMRU et Bags) ; collectez également les fichiers .LOG1/.LOG2.
• BagMRU est une arborescence : les valeurs numérotées contiennent les éléments du shell, les sous-clés portant le même numéro contiennent les enfants, MRUListEx indique l’ordre et NodeSlot pointe vers Bags\<n>.
• Les horodatages LastWrite des clés indiquent quand la liste d’enfants d’un nœud a été modifiée pour la dernière fois ; les horodatages DOS à l’intérieur des éléments d’entrée de fichier sont les horodatages MAC propres au dossier au moment de l’enregistrement, avec une résolution de 2 secondes.
• Les valeurs de « première/dernière interaction » sont déduites des horodatages LastWrite ; présentez-les en indiquant leur source et corroborez-les.
• Les Shellbags prouvent l’accès à un chemin, et non l’ouverture d’un fichier qu’il contient.