ShellBags Timestamps Explained: What Each Time Means

TL;DR. A ShellBag entry involves three different kinds of time. The key LastWrite (a 100-ns FILETIME) says when that BagMRU key last changed, which is driven by its children. The "last interacted" time is derived: the child in first position of a parent's MRUListEx was the most recent one when the parent key was written, so it inherits the parent's LastWrite. The embedded created/modified/accessed times are the folder's own file system times in 2-second FAT format, captured when the item was recorded, and not updated afterwards. Only the second kind is close to "when the user was there", and only for one child per folder.

If a ShellBags finding is going to be challenged, it will be challenged on timestamps. The artifact contains plenty of times; very few of them mean what a reader assumes.

The three kinds of time

The first two are registry times. The third is file system metadata that happened to be copied into the registry.

How MRUListEx turns a key time into an interaction time

Each BagMRU key holds a binary MRUListEx value: a list of 32-bit slot numbers, most recently used first, ended by 0xFFFFFFFF. When the user navigates into one of the key's children, Explorer moves that child's slot to the front and rewrites MRUListEx. Rewriting a value updates the key's LastWrite.

So, at the moment the parent key was last written, the child in position 0 was the one being used. That is the reasoning behind the "last interacted" column in tools such as ShellBags Explorer and SBECmd, and the one 4n6k laid out with step-by-step testing. It only works for position 0. For every other child, the parent's LastWrite says nothing about when that child was last used.

ShellBags Explorer also shows a "first interacted" time for some entries. The idea: a key with no subkeys has had no children to reorder, so its LastWrite is close to when it was created. Treat it as an approximation, and read the tool's own documentation before quoting it.

A worked example

The ShellBags Parser ships a synthetic sample (fictional data) in which the account svc_backup browses a finance share. Simplified, the relevant keys look like this:

BagMRU\1\0\0                    \\FILESRV01\Finance   LastWrite 2026-09-14 10:36:18 UTC
  values: 0 = Payroll, 1 = Board
  MRUListEx = 1, 0, FFFFFFFF
BagMRU\1\0\0\0                  Payroll               LastWrite 2026-09-14 10:32:40 UTC (no subkeys)
BagMRU\1\0\0\1                  Board                 LastWrite 2026-09-14 10:36:18 UTC (no subkeys)

What can be said:

• Board is at MRU position 0 in Finance, so its last interaction is the Finance key's LastWrite: 10:36:18 UTC.
• Payroll is at position 1. The Finance LastWrite does not date it. Its own key LastWrite (10:32:40) is when that key last changed; since it has no children, that is a reasonable approximation of when it was first recorded, not proof of the last visit.
• The order is solid: Board was used more recently than Payroll.

In the tool, "Last interacted" is filled only for MRU position 0 entries, and the timeline view falls back to "Key last write" for the rest, so you always see which kind of time you are sorting on.

What the embedded times are

A file entry shell item carries a modification time at offset 8. On Windows XP and later, its 0xBEEF0004 extension block adds creation and last-access times, per the libfwsi specification. They are the directory's own times, read from the file system when the item was built. 4n6k's testing found that they do not get updated after the shell item is first created.

Useful for:

• Dating a folder that no longer exists (see deleted folders).
• Matching a folder on removable media to the same folder in a seized drive image.
• Showing a folder was created shortly before it was browsed (a staging pattern).

Not useful for: saying when the user opened it.

Formats and precision

• FAT date/time. Two 16-bit values: date (year since 1980, month, day) and time (hour, minute, seconds/2). Microsoft's DosDateTimeToFileTime documents the layout. Seconds are always even. Expect up to a 1-second difference when comparing with a FILETIME from the $MFT or the USN journal.
• Time zone. libfwsi documents the shell item FAT times as UTC. Registry LastWrite times are UTC FILETIMEs. Present everything in UTC in reports, and convert only for display.
• FAT file systems. For folders on FAT volumes (many USB sticks), the underlying file system itself stores local time, and last access is a date only. Microsoft's File Times page notes that access time on FAT has a resolution of one day. Do not read an hour into an accessed value from a FAT32 stick.

Pitfalls I see in reports

1. "Folder X was last opened at [key LastWrite]." Wrong unless X is at MRU position 0 in its parent, and even then the time belongs to the parent's key.
2. "The user accessed the folder at [embedded accessed time]." That is the folder's file system access time from when the item was recorded.
3. Using a parent's LastWrite for all its children. Only one child inherits it.
4. Assuming navigation caused every write. View changes (sort order, icon size) and Explorer housekeeping also write keys. The time bounds an event; it does not name it.
5. Minute-level precision without corroboration. Registry writes can lag the click. Cross-check with LNK files, Jump Lists, event logs and the USN journal before stating a precise time.
6. Hive not replayed. On a dirty hive, the latest LastWrite values may be in the transaction logs.
7. Clock issues. A wrong system clock or deliberate change shifts every registry time. Check the system's time change events.

How to write it up

A defensible phrasing: "The BagMRU entry for \\FILESRV01\Finance\Board was the most recently used child of \\FILESRV01\Finance when that key was last written, at 2026-09-14 10:36:18 UTC. This is consistent with the account navigating to that folder at or shortly before that time." Then cite the corroborating artifact.

FAQ

Is a ShellBags key LastWrite time the last time the folder was opened?

Not in general. A BagMRU key's LastWrite changes when its own values change, which happens when its children are added or reordered. Only the child in first position of a parent's MRUListEx can be tied to the parent's LastWrite.

Are the created/modified/accessed times in a ShellBag the user's access times?

No. They are the folder's own file system times, copied into the shell item when it was recorded, and they are not refreshed on later visits.

Why do ShellBags times end in even seconds?

The embedded times are stored in FAT (DOS) date/time format, which has a 2-second resolution for times of day.

Related articles

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