shellbags prove what folders someone browsed

your computer remembers folders you forgot about

here's a fun one for defenders and paranoid regular people alike: windows keeps a receipt every time you open a folder in explorer. doesn't matter if it's on your c drive, a network share, or a usb stick you plugged in once during the obama administration. the receipt is called a shellbag, and it sticks around long after the folder, the drive, or the evidence you thought you deleted is gone.

what a shellbag actually is

windows explorer likes to remember your preferences. window size, icon view, sort order, scroll position, all that stuff for every folder you've ever browsed. to remember it, windows has to store the folder's path and a timestamp somewhere. that "somewhere" is a registry hive called UsrClass.dat, tucked away per user.

the catch is that this data doesn't get cleaned up when the folder disappears. delete the folder, unplug the usb, format the drive, doesn't matter. the shellbag entry just sits there in the registry, a little fossil of a folder that used to exist.

pulling the data with SBECmd

eric zimmerman's SBECmd is the standard free tool for parsing this stuff into something readable. the command looks like this:

SBECmd.exe -d C:\Users\<user>\...\UsrClass.dat --csv .

breaking it down:

-d points at the target UsrClass.dat file. this hive lives under each user's AppData path, something like C:\Users\username\AppData\Local\Microsoft\Windows\UsrClass.dat.

--csv . tells the tool to dump its findings into a csv file in the current directory instead of just printing a wall of text to the console.

run it and you get a spreadsheet-friendly export of every folder path shellbags remembers, plus the last write timestamp associated with each one.

finding the removable drive activity

once you've got the csv, you want to filter for anything that points to a drive letter that isn't your normal internal disk. removable media usually shows up as E:, F:, or whatever letter windows assigned it that day. powershell makes this easy:

Import-Csv *.csv | select LastWriteTime,AbsolutePath | ? AbsolutePath -like '*E:\*'

this imports the csv, pulls out just the timestamp and path columns, then filters down to rows where the path contains "E:\". swap the drive letter for whatever you're hunting. what you end up with is a timeline of exactly which folders on that removable drive got opened, and when, even if that drive was tossed in a lake three weeks ago.

why this matters if you're defending, not attacking

this is squarely a defensive and incident response tool, and that's the only way it should be used on systems you own or are authorized to investigate. a few real use cases:

you're doing an internal investigation because sensitive files may have walked out the door on a usb stick. shellbags can show you exactly which folders on that drive got browsed and when, corroborating or busting an employee's story.

you suspect your own machine was accessed while you were away and want to know if someone poked around network shares or an external drive you keep at your desk.

you're auditing your own workstation as part of a security review and want to understand what artifacts persist even after you think you've wiped something clean.

the phrase "i never opened that folder" doesn't hold up well once someone runs SBECmd against your UsrClass.dat. that's useful for defenders proving a timeline, and it's a good reminder for everyone else that deleting a file or unplugging a drive doesn't erase the fact that you looked at it.

the takeaway

shellbags are a great example of how much windows quietly logs without asking permission. if you're on the defensive side, incident response, internal audits, or just understanding your own exposure, know that folder access leaves fingerprints that outlive the folder itself. if you're worried about your own privacy, understand that clearing recent files or emptying a usb drive isn't the same as erasing the trail. the fix isn't paranoia, it's awareness: know what artifacts your os keeps, check them on your own systems periodically, and don't assume "deleted" means "gone."