ShellBags USB Forensics: A Worked Investigation Example

TL;DR. In this fictional case, the ShellBags of svc_backup on workstation FIN-WKS-07 show, within 45 minutes: browsing inside Downloads\tools.zip, a new folder under ProgramData\Intel, the \\FILESRV01\Finance share (Payroll, then Board), and E:\exfil\finance_2026 on a second drive. ShellBags prove the account navigated to each folder and give the order and approximate times. They do not prove any file was copied. The report states navigation, then points at the artifacts that can prove the rest.

Fictional scenario. Everything below uses the synthetic hives behind the Try a sample button of the ShellBags Parser: the account, host, share, SID and times are invented. The case continues the same story as the sibling parser sites (a rogue service account on FIN-WKS-07). No real organisation or person is involved.

The question

The finance team reports that board documents appeared on a paste site. The SOC sees an interactive logon by svc_backup, a service account that should never log on interactively, on FIN-WKS-07 on 2026-09-14. Question for the ShellBags: which folders did that account browse in Explorer, and in what order?

Collection

The responder collected C:\Users\svc_backup\NTUSER.DAT and ...\AppData\Local\Microsoft\Windows\UsrClass.dat, with their .LOG1/.LOG2 files, using KAPE's RegistryHivesUser target (see where ShellBags are stored). Neither hive was dirty. The UsrClass root key is S-1-5-21-3623811015-3361044348-30300820-1119_Classes, and NTUSER's Shell Folders point at C:\Users\svc_backup, so both hives are attributed to the same account.

What the parser shows

Dropping both hives into the ShellBags Parser gives 20 entries. With Flagged only ticked, the interesting ones are:

All times 2026-09-14, UTC. "Last interacted" means the entry was first in its parent's MRUListEx and takes the parent key's LastWrite; "key last write" is the entry's own key. The difference matters: see ShellBags timestamps explained.

Reading it, entry by entry

1. The toolkit inside a ZIP

tools.zip is a file entry item under Downloads, and x64 sits below it in the tree. That means the user opened the ZIP in Explorer as a compressed folder and navigated into its x64 directory. The ZIP's embedded times (created 10:06:12, modified 10:06:40, accessed 10:07:02) are its file system times when the item was recorded, which fits a download at about 10:06. The tools.zip key was last written at 10:07:20 with x64 in first MRU position: browsing inside the archive around 10:07.

What it does not show: extraction. Browsing a ZIP in Explorer does not extract it. Look for the extracted files in the MFT and USN journal. More in ShellBags and ZIP files.

2. A new folder in ProgramData

C:\ProgramData\Intel was last interacted at 10:09:05. Its embedded created time is 10:09:00, while ProgramData itself dates from 2026-09-01. A folder with a vendor name created a minute before it was browsed, in a user-writable location, is a classic staging pattern. The MFT reference (entry 91233, sequence 1) lets you pull its record and children from the $MFT. If execution artifacts are available (Prefetch, Amcache, BAM in the registry), check what ran from that folder.

3. The finance share

Three facts:

• \\FILESRV01 was the most recent child of Network and Finance the most recent child of \\FILESRV01 when those keys were written at 10:31:07.
• Finance's MRUListEx is 1, 0: Board (slot 1) was used after Payroll (slot 0).
• Board inherits Finance's LastWrite, 10:36:18. Payroll does not; its own key's LastWrite (10:32:40), with no subkeys, approximates when its entry was recorded.

Sound wording: "The account navigated to \\FILESRV01\Finance\Payroll and later to \\FILESRV01\Finance\Board; Board was the most recently used subfolder of Finance at 10:36:18 UTC." The embedded MFT references (70112, 70140) are the file server's NTFS records, useful when you examine FILESRV01. On the server side, share access auditing (Security events 5140 and 5145, if enabled) can confirm the session and the files touched.

4. The second drive

E: was the most recent child of My Computer at 10:45:51, and exfil\finance_2026 was browsed then. exfil was created at 10:40 and finance_2026 at 10:45 according to their embedded times. Both carry MFT references, so the E: volume was NTFS-formatted at the time; low entry numbers such as 35 and 36 are what you would expect on a freshly formatted volume, a lead worth checking rather than a conclusion.

The parser flags it "Other drive (USB?)" because the letter is not C:. ShellBags alone cannot say it was USB. That comes from the SYSTEM hive's device history, the setup API and event logs, and from LNK files whose volume serial number matches.

5. Recycle Bin at 10:50

The root BagMRU key was last written at 10:50:03 with Recycle Bin in first position. The account opened the Recycle Bin five minutes after the E: activity. On its own, trivia. In context, a reason to parse $Recycle.Bin (Recycle Bin parser) for what was deleted.

The timeline

What the ShellBags cannot say

• That any file was opened, copied or uploaded.
• That E: was a USB device, or which one.
• Anything done from a console: in the companion story, the attacker's command-line tools leave no ShellBags at all.
• That no other folders were browsed: an Explorer session on another account, or cleaned keys, would not appear.

This is why the report section on ShellBags is short and precise, and why every row in the timeline has a "next artifact" column. For the broader artifact choice, see ShellBags vs LNK files, Jump Lists and RecentDocs.

Reproduce it

Open the ShellBags Parser, click Try a sample, tick Flagged only, and switch between Tree and Timeline. The step-by-step guide explains each panel.

Related articles

• ShellBags and ZIP files
• Finding deleted folders with ShellBags
• ShellBags forensics: the complete guide