How to Analyze ShellBags Online With a Browser Parser
Step-by-step: parse UsrClass.dat and NTUSER.DAT in your browser, read the tree and timeline, triage flagged folders, export CSV or JSON. Nothing uploaded.
TL;DR. Open the ShellBags Parser, drop UsrClass.dat and NTUSER.DAT (or a whole KAPE/Velociraptor ZIP), and you get every browsed folder as a tree per account, a timeline, triage flags for other drives, network shares, archives and user-writable folders, and CSV/JSON export. The parser is Rust compiled to WebAssembly running in a Web Worker: the hives never leave your machine. It does not replay transaction logs yet, so replay dirty hives first.
People search for "ShellBags Explorer online" because the reference tools are Windows programs, and a lot of first-look triage happens on a Mac, a Linux analysis box, or a locked-down laptop where installing .NET tools is a ticket. This guide walks through a full session using the synthetic sample built into the site, so you can follow along without real data.
Before you start: collect the right files
You need, per user:
| File | Where | Why |
|---|---|---|
UsrClass.dat | C:\Users\<user>\AppData\Local\Microsoft\Windows\ | Main ShellBags tree on Vista and later |
NTUSER.DAT | C:\Users\<user>\ | Second BagMRU tree, and the user name |
.LOG1 / .LOG2 for each | Next to each hive | Pending writes of a dirty hive |
Both hives are locked while the user is logged on. Use KAPE's RegistryHivesUser target, Velociraptor, FTK Imager or a disk image. Details and pitfalls are in where ShellBags are stored and how to collect them.
If a hive is dirty, replay its logs first with rla.exe or Registry Explorer (Eric Zimmerman's tools). The parser detects dirty hives and says so, but it reads the primary file as-is.
Step 1: load the hives
Open the home page. You can:
- drop loose files (
UsrClass.dat,NTUSER.DAT, renamed copies are fine), - choose a folder (for example a KAPE output directory),
- drop a ZIP triage collection from KAPE or Velociraptor.
Or click Try a sample to load two synthetic hives from a fictional intrusion: the account svc_backup unzips a toolkit, browses a finance share and copies data to a USB drive.
Parsing runs in a Web Worker. There is no upload endpoint; once the page has loaded, it works offline.
Step 2: read the intake report
Before reading results, check what was not parsed. The tool lists each skipped file with a reason:
- All zeros: the hive was locked when copied and the tool that copied it produced an empty image. Re-collect with a raw copy method.
- Transaction log: keep it next to the hive and replay it; it is not parsed on its own.
- A different hive (SYSTEM, SOFTWARE, Amcache...): ShellBags only live in NTUSER.DAT and UsrClass.dat. For the other hives, see the registry parser or the Amcache parser.
- Not a registry hive: the first bytes are shown.
Parser warnings (unreadable values, dirty hive) appear in their own panel. A dirty warning means recent ShellBags may be missing.
Step 3: identify the accounts
Each hive is attributed to an account: the SID from the UsrClass root key (S-1-5-21-..._Classes), the user name from NTUSER's Shell Folders values, or the Users\<name>\ folder in the drop path. With a whole triage collection, you get one group per user. In the sample, both hives belong to svc_backup.
Step 4: walk the tree
The Tree view follows the BagMRU hierarchy, grouped per account and per hive. Columns: folder, shell item type, last interacted, key last write, created, accessed, MFT, flags.
Click any row for the details panel:
| Field | Meaning |
|---|---|
| Name / 8.3 name | Long name from the extension block, short name from the item header |
| Shell item type | Root, volume, directory, network, delegate, control panel, URI, variable |
| BagMRU key | For example BagMRU\0\1\0\0, to find it again in Registry Explorer |
| MRU position | Position in the parent's MRUListEx (0 = most recent) |
| NodeSlot | Link to the Bags settings key |
| Child folders | Number of subkeys |
| Modified (shell item) | FAT modified time from the item header |
| Extension block version | 3, 7, 8 or 9: hints at the Windows version that wrote it |
| GUID | For root and known-folder items |
| Raw shell item | Hex, for anything the parser does not decode |
In the sample, expand My Computer\E: to find exfil\finance_2026, and Network to find \\FILESRV01\Finance with Payroll and Board.
Step 5: triage with flags and filters
Tick Flagged only. The flags are simple, documented heuristics:
- Other drive (USB?): a drive letter other than C: under My Computer.
- Network location: a UNC path or a network item.
- Inside an archive: a path through
.zip,.7z,.rar,.cab,.iso,.tar,.gz,.vhd(x)and similar. - User-writable folder:
AppData,Users\Public,ProgramData,Windows\Temp,$Recycle.Bin,PerfLogs,Temp.
They point; they do not prove. A D: drive can be a second internal disk, a ProgramData subfolder can be a legitimate vendor directory. The filter box matches paths, dates and MFT entry numbers, which is how you pivot from an MFT entry seen in the USN journal back to the folder.
Step 6: switch to the timeline
The Timeline view sorts by the best available time: "last interacted" when the entry was first in its parent's MRUListEx, otherwise the key's last write. Know which one you are looking at: the column tells you. The logic behind it is in ShellBags timestamps explained. Switch between UTC and local time with the toggle; report in UTC.
For the sample, the story reads: tools.zip\x64 browsed around 10:07, ProgramData\Intel at 10:09, \\FILESRV01\Finance from 10:31, Board at 10:36, E:\exfil\finance_2026 at 10:45, Recycle Bin at 10:50 (all 2026-09-14 UTC, fictional). The investigation walkthrough interprets it.
Step 7: export and corroborate
Export CSV or JSON. Exports contain the rows currently shown, so filter first if you want a focused table. CSV cells that start like a spreadsheet formula are neutralised, because folder names are attacker-controlled.
Then corroborate: LNK files and Jump Lists for files opened in those folders, event logs (EVTX parser) for logons and USB connections, and the USN journal for file creation and deletion.
What the tool does not do (yet)
- Replay
.LOG1/.LOG2transaction logs. - Recover deleted BagMRU keys from unallocated hive cells.
- Fully decode MTP device items, ZIP-content (
0x52) items and search results (kept as best-effort names plus hex).
For those, use ShellBags Explorer / SBECmd and Registry Explorer alongside.