Shellbags

Windows remembers how each folder looked the last time a user browsed it in Explorer: window size and position, sort order, view mode and icon size. These records, called Shellbags, survive after the folder, USB drive or network share is gone. This lesson covers where they are stored, how to rebuild folder paths from them and how far their timestamps can be trusted.

What Shellbags are and why examiners care

Shellbags are written by the Windows shell, which drives File Explorer, the desktop and the standard Open/Save dialogs. When a user opens a folder through the shell, Windows records the folder's position in the shell namespace (Desktop, This PC, E:\, Clients …) in the user's registry hive, with a slot for its view settings. The user does not need to change the view for the entry to be created.

This is evidence that a specific user account navigated to a folder, including folders that are hard to see otherwise:

• folders on removable drives that are no longer connected;
• network shares (for example \\FILESRV01\Projects);
• folders inside ZIP archives opened in Explorer as compressed folders;
• folders that were later deleted, renamed or wiped.

The data sits in a per-user hive, so it is attributed to the account that owns that hive (Lesson 2.2).

Where they live

On Windows 7, 8, 10 and 11 most Shellbags are in UsrClass.dat, at C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat:

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

On a live system this hive is mounted as HKEY_USERS\<SID>_Classes. NTUSER.DAT also contains Software\Microsoft\Windows\Shell\BagMRU and Software\Microsoft\Windows\Shell\Bags; on these versions it usually holds far fewer entries, but not always none, so parse both hives.

In a triage collection, expect UsrClass.dat with UsrClass.dat.LOG1 and .LOG2: the hive is often dirty, and recent entries may exist only in the transaction logs until they are replayed (Lesson 2.1).

Structure of the BagMRU tree

BagMRU is a tree that mirrors the shell namespace. The BagMRU key itself is the root (the Desktop). Each key holds:

• Numbered values (0, 1, 2 …, REG_BINARY). Each holds one_ shell item_: the binary identifier of one child folder, in the ITEMIDLIST format also used in LNK files. The subkey with the same number holds that child's children, so a folder's full path is the chain of items from the root down.
• MRUListEx (REG_BINARY): the child value numbers as 4-byte little-endian integers, most recently used first, ended by 0xFFFFFFFF.
• NodeSlot (REG_DWORD): the number_ n_ of the key Bags\<n> that holds this folder's view settings. Under Bags\<n>\Shell\<folder type GUID> are values such as Mode, LogicalViewMode, Sort and IconSize; a ComDlg subkey appears for folders viewed through Open/Save dialogs.

The numbers carry no meaning: value 2 is simply the third child recorded under that parent.

Shell item types

Every shell item starts with a 2-byte size and a 1-byte class type indicator at offset 2, which tells the parser how to read the rest.

Folders inside a ZIP archive appear below the item of the archive itself, one of the few cases where a file name appears in Shellbags.

Timestamps

Shellbags offer two different kinds of time; do not confuse them.

Key LastWrite times

Each BagMRU key has a LastWrite time (FILETIME, UTC): the last change to any value in that key, such as a new child added, MRUListEx reordered because a child was revisited, or the key created. A parent's LastWrite therefore says when its child list last changed, and the child at the head of MRUListEx is the one most likely involved. There is one time per key; earlier visits are overwritten.

Timestamps inside file entry items

A file entry item (0x31/0x32) stores, from its start:

After the short name comes an extension block with signature 0xBEEF0004. It holds the creation and last access times (also DOS date/time), the long name in UTF-16LE and, on Windows 10 and 11 for folders on NTFS, the folder's 8-byte file reference (6-byte MFT entry number plus 2-byte sequence number).

DOS date/time packs a 16-bit date (bits 15–9 year since 1980, 8–5 month, 4–0 day) and a 16-bit time (bits 15–11 hour, 10–5 minute, 4–0 seconds divided by 2). Seconds are stored in steps of 2, so these values can differ from the NTFS timestamps by up to 2 seconds. Parsers such as SBECmd report them as UTC.

These are the folder's own MAC times at the moment the item was written, not browsing times. They help indirectly: the item cannot predate its embedded modified time, and the MFT reference identifies the folder in the drive's $MFT (Lesson 1.3).

"First interacted" and "last interacted"

Parsers derive these from LastWrite times. Typically, if a folder heads its parent's MRUListEx, the parent's LastWrite is reported as the folder's last interacted time; if a folder's own key has no children, its LastWrite is reported as first interacted, since nothing has changed that key since its creation. These are inferences, not stored fields. Report them by their source ("key BagMRU\1\0\2 was last written at T, with 2026 first in its MRUListEx"), not as "the user opened 2026 at T", and corroborate with LNK files, Jump Lists (Lesson 2.4) and USB connection times (Lesson 2.6).

What Shellbags prove and do not prove

Shellbags support the statement that this user account navigated to this folder path through the Windows shell, at least once, and no later than the relevant LastWrite time. They do not prove:

• that any file in the folder was opened, copied or seen: ordinary file names are not recorded;
• how long or how often the user visited;
• that each intermediate folder was opened separately: typing a full path into the address bar also creates nodes for the folders above it;
• which physical device was mounted as E: (use Lesson 2.6 artifacts or the MFT reference).

Deleting a folder does not delete its Shellbag; only cleaning the hive does (Module 7).

Example tools: ShellBags Explorer (graphical tree), SBECmd (SBECmd.exe -d <hive folder> --csv <out>, one CSV row per item with absolute path, MRU position, node slot, LastWrite and embedded times) and Registry Explorer for the raw keys.

Worked example: E:\Clients\2026\Contracts

UsrClass.dat of user mira (Windows 11, logs replayed; E: was an NTFS USB drive) contains this branch:

Path. Joining the items from the root down gives E:\Clients\2026\Contracts, with view settings in Bags\38.

Embedded times of the 2026 item. The modified field holds date word 0x5C62 and time word 0x8509. Date: 0x5C62 = 23,650; 23,650 >> 9 = 46, so the year is 1980 + 46 = 2026; (23,650 >> 5) & 0xF = 3 (March); 23,650 & 0x1F = 2. Time: 0x8509 = 34,057; 34,057 >> 11 = 16 hours; (34,057 >> 5) & 0x3F = 40 minutes; (34,057 & 0x1F) × 2 = 9 × 2 = 18 seconds. Result: 2026-03-02T16:40:18Z. The 0xBEEF0004 block gives creation 2026-01-05T09:12:44Z and MFT entry 64, sequence 1.

What can be concluded about E:\Clients\2026:

1. The account mira navigated through the shell to E:\Clients\2026 on whatever volume was mounted as E:.
2. The E:\Clients key was last written at 2026-03-18T14:05:51Z with 2026 heading its MRUListEx: the best-supported statement is that 2026 was added to, or moved to the front of, the folders browsed under Clients at that time.
3. The 2026 key was last written at 2026-03-18T14:06:03Z with Contracts at the head, and the childless Contracts key carries the same time: at 14:06:03Z the user reached Contracts through 2026, probably for the first time.
4. When 2026 was first browsed cannot be determined; earlier visits are overwritten. The embedded dates describe the folder, and only show the item was written no earlier than 2026-03-02T16:40:18Z.
5. Nothing shows which files in Contracts were opened. To tie E: to the evidence drive, look up MFT entry 64 in the USB image's $MFT: sequence 1, name 2026, parent Clients would confirm it.

Exam focus: Expect to rebuild a full folder path from a BagMRU branch, including removable or network locations, and to name the account from the hive it came from. You may be asked for a LastWrite time in ISO 8601 UTC, to distinguish it from the folder's embedded timestamps, or to match a folder to its MFT entry. Know what a Shellbag does not prove, especially that files inside were opened.

Key points

• Shellbags record folders a user browsed through the Windows shell, with view settings; they persist after the folder, drive or share is gone.
• On Windows 7 and later they are mainly in UsrClass.dat (Local Settings\Software\Microsoft\Windows\Shell\BagMRU and Bags), with fewer in NTUSER.DAT (Software\Microsoft\Windows\Shell\BagMRU and Bags); collect the .LOG1/.LOG2 files too.
• BagMRU is a tree: numbered values hold shell items, subkeys of the same number hold children, MRUListEx gives order and NodeSlot points to Bags\<n>.
• Key LastWrite times show when a node's child list last changed; DOS timestamps inside file entry items are the folder's own MAC times at recording, with 2-second resolution.
• "First/last interacted" values are inferences from LastWrite times; report them by their source and corroborate.
• Shellbags prove navigation to a path, not that any file in it was opened.