ShellBags Deleted Folders: Proving a Folder Existed

TL;DR. ShellBags keep entries after the folder is deleted, so the full path, name and embedded times of a vanished folder survive in the user's hive. On NTFS, the shell item also holds the folder's MFT entry and sequence number. Look that entry up in the current $MFT: same sequence and same name means the folder (or its record) is still there; a higher sequence means it was deleted and the record reused; an unallocated record with the same sequence means deleted, not yet reused. Then take the file reference to the USN journal to date the deletion.

"The folder never existed" and "I deleted it months ago" are claims ShellBags are well placed to test. This article is the procedure I use, with its limits.

Why the entry survives

Explorer does not clean BagMRU entries when a folder is deleted. The key describes a place the user navigated to, not a live object. Practitioners have relied on this since the early ShellBags research, for example Chad Tilbury's SANS post on reconstructing long-gone removable devices. What removes entries: Windows' own limit on remembered folders, profile resets, and cleaning tools (see limitations and anti-forensics).

The surviving entry gives you:

Step 1: find candidate entries

List everything in the user's ShellBags, then compare against the current file system. With the ShellBags Parser, export CSV and diff the paths against a file listing from the image (or against an $MFT parse). Folders in the ShellBags but not on disk are your candidates.

Two things to set aside early:

• Removable and network paths. A missing E:\exfil is not deleted; the drive is just not here. Check it against the device or server if you can get it.
• Archive paths. Items below a .zip never existed on disk as folders. See ShellBags and ZIP files.

Step 2: read the MFT reference

For each local NTFS candidate, note the MFT entry and sequence from the details panel (the search box also filters by MFT entry number). The format is Microsoft's MFT_SEGMENT_REFERENCE: a 48-bit entry number and a 16-bit sequence number, which Microsoft describes as a circularly reused tag. libyal's NTFS documentation notes that the sequence number is incremented each time the record is freed.

Without an MFT reference (XP-era items with extension version 3, FAT/exFAT volumes, network items), skip to step 4.

Step 3: compare with the current $MFT

Parse the $MFT of the same volume and look up the entry:

That comparison turns "a ShellBag names this folder" into "this specific folder record existed and was deleted", which is much harder to dispute.

A rename is worth a note of its own. If two ShellBag entries in the same parent share an MFT entry and sequence but have different names, the folder was very likely renamed between the two visits. The older name is the one in the entry with the older key time.

Step 4: date the deletion

The ShellBag cannot tell you when the folder was deleted. Other artifacts can:

• USN journal. Filter $UsnJrnl:$J on the folder's file reference number (entry + sequence). A FILE_DELETE reason gives the time; a RENAME_OLD_NAME/RENAME_NEW_NAME pair gives renames. The USN parser does this in the browser.
• Recycle Bin. A folder sent to the Recycle Bin becomes $R... with a matching $I... file holding the original path and deletion time. The Recycle Bin parser reads $I files.
• Volume Shadow Copies. An older snapshot may still contain the folder and its contents.
• LNK files and Jump Lists. Files opened from the folder before it was deleted may be referenced by LNK files and Jump Lists, with their own MFT references.

Step 5: bound the timeline

Combine the pieces:

1. Embedded created time: the folder existed from at least this point.
2. ShellBag key times (MRU-derived where possible): the user was there around this time. See ShellBags timestamps explained.
3. USN / Recycle Bin: the folder was deleted at this time.

A hypothetical write-up (invented values): "A folder named staging existed at C:\Users\Public\staging (MFT entry 104233, sequence 3), created on [date]. The account browsed it, last around [time]. The record was freed and reused (current sequence 4). The USN journal records its deletion at [time]." Each clause has a single source you can show.

Limits

• No MFT reference, no record check. XP-era items, FAT/exFAT volumes, and some item types lack a usable reference.
• The entry may be older than you think. A ShellBag created years ago in a migrated profile can refer to a folder on a disk that no longer exists.
• Cleaning tools target this exact use. Tools that remove "traces of deleted folders" delete ShellBags whose folders are gone. An absence proves nothing.
• Deleted keys are not recovered by every tool. Entries removed from the hive may still sit in unallocated cells; Registry Explorer can show deleted keys. The ShellBags Parser does not recover them yet.

FAQ

Do ShellBags keep entries for deleted folders?

Yes. Deleting a folder does not remove its BagMRU entry. The entry stays until Windows prunes it or a cleaning tool deletes it, with the folder's path, embedded times and, on NTFS, its MFT entry and sequence number.

How do I know if the folder's MFT record was reused?

Compare the sequence number in the ShellBag with the current $MFT record for the same entry. NTFS increments the sequence number when a record is freed, so a higher current value means the original folder is gone and the record was recycled.

Related articles

• ShellBags limitations and anti-forensics
• The shell item format explained
• ShellBags forensics: the complete guide