11.3 User Activity Artifacts: ShellBags, LNK Shortcut Files, Jump Lists & Recycle Bin ($I/$R)

11.3 User Activity Artifacts: ShellBags, LNK Shortcut Files, Jump Lists & Recycle Bin ($I/$R)

Quick Answer: User activity artifacts establish user intent, interaction, file opening, and data destruction. ShellBags (UsrClass.dat\...\Bags and BagMRU) prove that a user navigated into specific folders—even if those folders have since been deleted or were located on an unmounted external USB drive. Shortcut (.LNK) files reveal target file paths, target MAC timestamps, volume serial numbers, and the host machine's MAC address via the TrackerDataBlock. Jump Lists (%AppData%\Microsoft\Windows\Recent\AutomaticDestinations\) track per-application recent file openings in OLE Compound File containers named after 16-character AppIDs. Finally, the Windows Recycle Bin (C:\$Recycle.Bin\<User_SID>\) pairs the actual deleted file data ($R) with a 544-byte metadata index ($I) containing the original file size, 64-bit FILETIME deletion timestamp, and original file path.

---

ShellBags: Proving Folder Access and Navigation History

When a user browses the file system using Windows Explorer, the operating system saves their viewing preferences—such as icon size, grid position, window sorting, and view mode (Details, Large Icons, List). These settings are stored in registry structures known as ShellBags.

Registry Storage Locations

In modern Windows operating systems (Windows 7 through Windows 11), ShellBags reside primarily within the user's UsrClass.dat hive:

• Primary Path (UsrClass.dat): %UserProfile%\AppData\Local\Microsoft\Windows\UsrClass.dat Local Settings\Software\Microsoft\Windows\Shell\BagMRU Local Settings\Software\Microsoft\Windows\Shell\Bags
• Legacy / Secondary Path (NTUSER.DAT): %UserProfile%\NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU %UserProfile%\NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags (In modern Windows, this legacy path primarily records Remote Desktop and network shell interactions).

The BagMRU Tree Structure

The BagMRU key is organized as a hierarchical tree reflecting the folder structure of the file system:

• Root Key (BagMRU): Represents the desktop or root shell namespace.
• Numbered Subkeys (0, 1, 2...): Each subkey corresponds to a child folder navigated by the user.
• MRUListEx Value: A 4-byte integer array that defines the Most Recently Used access order of child subkeys. The first integer indicates the subkey corresponding to the folder most recently browsed by the user.
• NodeSlot Value: Points to the corresponding configuration record inside the companion Bags\<NodeSlot> key, which contains view mode settings.

UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\
  ├── BagMRU (Root: Desktop)
  │     ├── 0 (My Computer) [MRUListEx: 2, 0, 1]
  │     │     ├── 0 (C:\ Drive)
  │     │     └── 1 (E:\ Removable USB Disk)  <-- Proves USB Browsing
  │     │           └── 0 (Confidential_IP)   <-- Proves Folder Access
  │     └── 1 (Network Shares)
  └── Bags
        ├── 1 (View Settings for NodeSlot 1)
        └── 2 (View Settings for NodeSlot 2)

The Shell Item Data (SHITEMLIST)

Each numbered subkey in BagMRU contains binary values storing Windows Shell Items (SHITEMLIST). By decoding these shell items, forensic tools extract:

• Complete directory names (both long Unicode names and short 8.3 MS-DOS names).
• File system timestamps of the target folder recorded at the time of browsing (Created, Modified, and Accessed timestamps).
• File system type (FAT, NTFS) and volume information.

High-Value Forensic Applications

[!IMPORTANT] ShellBags persist indefinitely unless explicitly scrubbed. Even if an adversary deletes a sensitive directory, wipes a folder, or unplugs an external USB thumb drive, the ShellBags records remain intact inside UsrClass.dat. ShellBags provides definitive proof that a folder existed and that the user interactively navigated into it.

# Example Parsing with Eric Zimmerman's SBECmd
SBECmd.exe -d "C:\Users\Suspect\AppData\Local\Microsoft\Windows\" --csv "C:\Cases\ShellBags_Out"

---

Windows Shortcut (.LNK) Files: The Binary Shell Link Format

Windows Shortcut files (.lnk) conform to the Microsoft Shell Link Binary File Format ([MS-SHLLINK]). They are created automatically when users interact with files or can be explicitly created as shortcuts.

Automatic Generation Locations

• %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\ (Populated whenever a local or remote file is opened).
• %UserProfile%\Desktop\ and %UserProfile%\AppData\Roaming\Microsoft\Windows\Start Menu\.

Deep-Dive: Forensic Header and Metadata Blocks

A .lnk file is far more than a simple file pointer; it encapsulates an evidentiary snapshot of the target file and the host environment at the time the link was created or updated:

+-------------------------------------------------------------------------+
|                    MS-SHLLINK BINARY STRUCTURE BLOCKS                   |
+-------------------------------------------------------------------------+
| Structure Block       | Evidentiary Data Extracted                      |
|-----------------------|-------------------------------------------------|
| **ShellLinkHeader**   | • Target File Size                              |
|                       | • Target File Attributes (Hidden, System, etc.) |
|                       | • Target File Creation Timestamp                |
|                       | • Target File Last Modification Timestamp       |
|                       | • Target File Last Access Timestamp             |
|-----------------------|-------------------------------------------------|
| **LinkInfo**          | • Target File Full Absolute Local Path          |
|                       | • Volume Type (Fixed, Removable, Network)       |
|                       | • Volume Serial Number (Hexadecimal ID)         |
|                       | • Volume Label (e.g., "USB_BACKUP")             |
|                       | • Common Network Relative Link (UNC Path/Share) |
|-----------------------|-------------------------------------------------|
| **StringData**        | • Relative Path (e.g., ..\..\Finance.xlsx)     |
|                       | • Working Directory & Command-Line Arguments    |
|-----------------------|-------------------------------------------------|
| **ExtraDataBlocks**   | • TrackerDataBlock (Machine NetBIOS Name &      |
|                       |   Host MAC Address via Droid GUID)              |
+-------------------------------------------------------------------------+

The TrackerDataBlock and Host MAC Address Identification

The TrackerDataBlock contains data from the Windows Distributed Link Tracking (DLT) service, which ensures shortcuts function even if target files are renamed or moved across volumes. It contains two unique GUIDs: the Droid Volume Identifier and the Droid File Identifier:

• When parsed, these GUIDs follow the UUID Version 1 (time-based) standard.
• The final 12 hexadecimal characters of a Version 1 UUID represent the IEEE 802 MAC address of the physical Network Interface Card (NIC) of the host machine where the link was generated.
• Forensic Utility: Proves whether an evidentiary .lnk file discovered on a flash drive was generated on the suspect workstation or originated from an external third-party computer.

# Parsing LNK files with Eric Zimmerman's LECmd
LECmd.exe -f "C:\Users\Bob\AppData\Roaming\Microsoft\Windows\Recent\Confidential.xlsx.lnk"

---

Jump Lists: Application-Centric Usage Tracking

Introduced in Windows 7, Jump Lists provide users with quick access to recently opened, frequently opened, or pinned documents directly from application taskbar icons.

File Locations & Types

Jump Lists reside within the user profile under two distinct directories:

• AutomaticDestinations: %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\ Contains files automatically tracked by the Windows shell as the user opens items.
• CustomDestinations: %UserProfile%\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\ Contains application-specific custom categories or pinned actions programmed by software developers.

The Application User Model ID (AppID) Naming Standard

Jump List files do not use friendly names; they are named according to the application's unique Application User Model ID (AppID): [AppID].automaticDestinations-ms [AppID].customDestinations-ms

The 16-character hexadecimal AppID is generated by applying a proprietary CRC-64 algorithm to the application's executable path:

+-------------------------------------------------------------------------+
|                   COMMON APPLICATION APPIDs IN FORENSICS                |
+-------------------------------------------------------------------------+
| Hexadecimal AppID | Associated Application                              |
|-------------------|-----------------------------------------------------|
| 7e4dca8024686324  | Notepad                                             |
| 18ced1411779e4bb  | Windows File Explorer (Quick Access)                |
| adecfb853d774686  | Wordpad                                             |
| 918e0ecb43d17e23  | Microsoft Word 2016 / 365                           |
| 28c8b86deab549a1  | Google Chrome                                       |
| a7bd71699cd38d1c  | Microsoft Edge (Chromium)                           |
+-------------------------------------------------------------------------+

Internal Architecture of AutomaticDestinations

*.automaticDestinations-ms files are structured as OLE Compound File Binary Format (CFBF) files (the same compound container used by legacy Microsoft Office .doc files):

• When opened using a compound file parser, the container reveals multiple internal streams numbered 1, 2, 3...
• Each numbered stream is a fully functional, standalone MS-SHLLINK (.lnk) file containing target path, MAC timestamps, volume serial numbers, and file size.
• Crucially, the compound file contains a master stream named DestList.

The DestList Stream

The DestList stream functions as a relational database table indexing the numbered LNK streams:

• Tracks the exact Most Recently Used (MRU) order.
• Records the Interaction Count (how many times the user opened the document with that application).
• Records the Last Access Timestamp (64-bit FILETIME) of the document.
• Records whether the item was pinned by the user.

# Parsing Jump Lists with Eric Zimmerman's JLECmd
JLECmd.exe -d "C:\Users\Alice\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\" --csv "C:\Cases\JumpList_Out"

---

Windows Recycle Bin Architecture ($Recycle.Bin)

When a user deletes a file within the Windows Explorer GUI (by pressing Delete or dragging to the Recycle Bin, rather than executing a hard deletion via Shift+Delete), the file is moved to the hidden, system-protected $Recycle.Bin folder.

Directory Architecture & User SID Isolation

$Recycle.Bin resides in the root directory of each storage volume (e.g., C:\$Recycle.Bin\, D:\$Recycle.Bin\).

• Inside $Recycle.Bin, Windows creates an isolated subfolder for each user who deletes an item on that volume, named with the user's specific Security Identifier (SID): C:\$Recycle.Bin\S-1-5-21-3623811015-3361044348-30300820-1001\
• Forensic Principle: Files found within an SID directory can be definitively attributed to the user associated with that SID.

The $I and $R File Pairing Mechanism

Upon deletion, Windows renames the original file and generates two paired files sharing an identical random 6-character alphanumeric identifier:

Original File: "SecretPlan.docx" (Deleted by user)
       │
       ├──> $R1A2B3C.docx  --> Actual Deleted File Content (Payload)
       └──> $I1A2B3C.docx  --> Metadata Index Record (544 bytes in Win 10/11)

• The $R File (Data Content): Retains the original file's raw binary contents and extension, but its filename is changed to $R<RandomChars>.<Extension>.
• The $I File (Metadata Record): Contains the administrative metadata required by the operating system to restore the file to its original location if the user clicks "Restore".

Modern $I File Binary Structure (Windows 10 / 11 Version 2)

In Windows Vista through Windows 8, $I files used Version 1 (544 bytes). In Windows 10 and 11, $I files use the updated Version 2 specification:

+-------------------------------------------------------------------------+
|           WINDOWS 10/11 RECYCLE BIN $I FILE STRUCTURE (VERSION 2)        |
+-------------------------------------------------------------------------+
| Byte Offset | Data Type   | Field Description                           |
|-------------|-------------|---------------------------------------------|
| 0x00 - 0x07 | 64-bit int  | Header Version: 0x0000000000000002          |
| 0x08 - 0x0F | 64-bit int  | Original File Size in Bytes (64-bit integer)|
| 0x10 - 0x17 | 64-bit int  | Deletion Timestamp (64-bit Windows FILETIME)|
| 0x18 - 0x1B | 32-bit int  | Original File Path Character Count          |
| 0x1C - End  | UTF-16LE    | Original Absolute File Path (Null-terminated|
|             | String      | Unicode string, variable length up to 520B) |
+-------------------------------------------------------------------------+

Example Hex View of $I File Header (Version 2):
Offset  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
000000  02 00 00 00 00 00 00 00  00 40 01 00 00 00 00 00   | Header=0x02, Size=81,920 bytes
000010  60 7A 5B 14 D0 2A DC 01  1F 00 00 00 43 00 3A 00   | FILETIME=Date, PathLen=31, "C:."
000020  5C 00 55 00 73 00 65 00  72 00 73 00 5C 00 41 00   | "\Users\A"

Forensic Analysis Workflow with RBCmd

By pairing $I and $R files, examiners reconstruct the exact pre-deletion scenario:

1. Open $I1A2B3C.docx using Eric Zimmerman's RBCmd.
2. Extract the original path: C:\Users\Alice\Documents\Financials\Budget2026.docx.
3. Extract the exact deletion timestamp: 2026-04-12 14:22:05 UTC.
4. Recover the original uncorrupted file data from companion file $R1A2B3C.docx.
5. If the user subsequent emptied the Recycle Bin, the $R file data may be overwritten in unallocated space, but the small 544-byte $I file often persists in slack space or unallocated MFT records, preserving forensic evidence of what was deleted and when.