ShellBag Forensics: Tracking User Folder Interactions

 

ShellBags are among the most intricate and analytically demanding registry artifacts encountered in Windows digital forensic examinations. Nevertheless, their evidentiary yield justifies the analytical investment, furnishing robust corroboration of the existence of files and folders, user awareness, and interaction provenance. These artifacts are particularly instrumental in resolving complex questions of data enumeration, assessing the scope of exfiltration or destruction in intrusion investigations, reconstructing the contents of defunct removable media, and documenting access to previously mounted encrypted volumes or synchronized cloud storage directories. Critically, ShellBags frequently preserve references to deleted folders and volumes, delivering high-value intelligence regarding artifacts no longer resident within the active file system.

Windows maintains ShellBags to record user-specific preferences governing the graphical presentation of folders and shell objects within File Explorer. This encompasses column visibility and ordering, view modes (icons, details, list, tiles, content), sorting criteria, and window geometry. The persistence of these customizations upon subsequent access exemplifies the functionality of ShellBags. Notably, Windows treats numerous non-traditional entities as shell folders, including compressed archives, mobile device file systems, Control Panel applets, and virtual network locations. Beginning with Windows 11 22H2, native Explorer support was significantly expanded to encompass nearly a dozen additional archive formats—such as 7-Zip, RAR, TAR, and Gzip—via integrated libarchive handling. Given threat actors’ increasing reliance on native tools to minimize forensic footprints, this enhancement is anticipated to yield substantial probative evidence in future investigations. Creation or modification of ShellBags entries requires explicit interaction through the Windows GUI, most commonly via File Explorer.

The mere presence of a ShellBags subkey corresponding to a specific folder or shell namespace object attests that the associated user account actively interacted with it. Leveraging the LastWrite timestamps inherent to registry keys, examiners can establish precise temporal boundaries—specifically, the initial interaction time and most recent update—while cross-correlating these with embedded shell item target MAC timestamps. Because substantial portions of this interaction data reside exclusively within the ShellBags structure, the artifact has achieved paramount importance in modern Windows forensic workflows.

Location of ShellBags Data

The storage location of ShellBags data evolved with the release of Windows Vista. In Windows XP, the primary data resided within the NTUSER.dat hive. From Windows Vista onward, the preponderance of ShellBags information was relocated to the USRCLASS.dat hive, although residual artifacts—particularly those related to desktop items and mapped network shares—persist in NTUSER.dat. Comprehensive analysis, therefore, necessitates examination of both registry hives. The specific keys are listed as follows.

Windows Vista and Later (Including Windows 7, 8, 10, and 11)

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags

(Live analysis)

NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU
NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags

(Disk analysis)

Stores data for folders accessed from the network (UNC path).

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags

(Live analysis)

UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags

(Disk analysis)

Stores data for folders accessed locally and on removable drives.

C:\Users\USER\AppData\Local\Packages\APP_PACKAGE_NAME\SystemAppData\Helium\User.dat\ (Disk analysis)

Stores data for folders accessed from the network (UNC path) from a specific app.

C:\Users\USER\AppData\Local\Packages\APP_PACKAGE_NAME\SystemAppData\Helium\UserClasses.dat\ (Disk analysis)

Stores data for folders accessed locally and on removable drives from a specific app.

Windows XP

HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam

(Live analysis)

NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam

(Disk analysis)

Stores data for folders accessed locally.

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell

(Live analysis)

NTUSER.DAT\Software\Microsoft\Windows\Shell

(Disk analysis)

Stores data for folders accessed from the network (UNC path).

The core ShellBags artifacts manifest under the following primary keys in USRCLASS.dat:

• BagMRU: Constructs a hierarchical representation of accessed shell namespaces through a cascading series of numbered subkeys that mirror the folder structure traversed by the user.
• Bags: Contains the associated view and configuration preferences for each corresponding entry in BagMRU.

The colloquial designation “ShellBags” derives directly from these two keys (Shell + Bags). A foundational concept in ShellBags analysis is that all data originates from registry keys, each of which bears a LastWrite timestamp that updates upon modification. These timestamps form the evidentiary basis for determining “First Interacted” and “Last Interacted” temporal markers.

ShellBags Analysis

Analysis typically commences with the BagMRU key. This structure is distinctive in that it replicates the folder hierarchy using sequentially numbered subkeys (0, 1, 2, …), wherein each subkey represents a child namespace object. Identification of each folder’s identity and properties requires inspection of its parent key, which maintains binary values named according to its children. These values encapsulate the shell item data, including folder names and associated metadata.

MRU (Most Recently Used) lists within the BagMRU key consist of ordered sequences of hexadecimal values that establish the relative recency of user interaction with shell namespace objects. As the name implies, these lists provide a chronological ordering of items interacted with based on the sequence in which they appear.

Each MRU entry is represented by a four-byte (DWORD) value stored in little-endian byte order. The list is terminated by the sentinel value 0xFFFFFFFF. The first four-byte segment identifies the most recently interacted item, the second segment identifies the next most recent, and so forth. In BagMRU implementations, the MRUListEx value is typically utilized for this ordering.

Because subkeys within the BagMRU hierarchy are named using decimal integers (e.g., “0”, “1”, “5”), forensic examiners must convert the hexadecimal values extracted from the MRUListEx into their decimal equivalents. This conversion is essential to accurately map the MRU ordering to the corresponding numbered subkeys, thereby enabling the correct reconstruction of the interaction sequence and hierarchical relationships.

This ordering mechanism is forensically critical, as it allows examiners to determine not only which folders or shell items were interacted with, but also the sequence and relative recency of those interactions—information that significantly enhances temporal analysis when correlated with registry LastWrite timestamps.

As illustrated in the figure above, the MRUListEx value establishes the following chronological order of user interaction with the shell namespace objects:

1. Entry 1
2. Entry 0
3. Entry 4
4. Entry 2
5. Entry 29
6. Entry 12
7. … (and so on)

This sequence reflects the Most Recently Used ordering, with the leftmost entry representing the most recent interaction and subsequent entries indicating progressively less recent access. By mapping these decimal values to their corresponding numbered subkeys under the BagMRU hierarchy, examiners can reconstruct the precise sequence in which the user navigated or interacted with the folders, providing critical behavioral context when combined with associated LastWrite timestamps and embedded shell item metadata.

Reading the Data Field in the BagMRU

Prior to examining the subkeys in greater detail, it is essential to first analyze the binary content of the Data field within the BagMRU values. A clear understanding of this structure is necessary to accurately reconstruct the underlying file system namespace hierarchy and associated shell items.

This analysis draws upon the seminal research conducted by Joachim Metz, as well as the comprehensive LIFARS White Paper on ShellBags, which remains an authoritative reference for interpreting these complex binary data structures. For the purposes of this examination, focus will be restricted to the second BagMRU entry to establish foundational parsing concepts before progressing to more intricate hierarchical relationships.

The initial two bytes of the 'Data' field denote the total size of the shell item structure. This is immediately followed by a one-byte Class Type Identifier and a one-byte Sort Index. The 'Sort Index' serves as an internal reference, designating specific virtual or special shell folders (e.g., This PC, Users, Games, Documents, or Network Locations). According to Joachim Metz’s authoritative Windows Shell Item format specification (the primary reference for parsing these structures), the known Sort Index mappings include:

Sort Index	Identifier	Description
0x50	My Computer	This PC / Computer
0x44	Users	Users folder
0x48	My Documents	Documents
0x58	Network	My Network Places
0x60	Recycle Bin	Recycle Bin
0x80	My Games	Games folder

After the Sort Index is a 16-byte GUID (Globally Unique Identifier), which is terminated by two NULL bytes (0x00 0x00). Because the 'Data' field consists of raw binary data, the hexadecimal representation must be properly interpreted—typically by converting the byte sequence into standard GUID notation (e.g., {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx})—to accurately identify the referenced shell namespace.

Shell Size: 0x14 
Class Type Identifier: 0x1F (Root Folder Shell Item)
Sort Index: 0x50 (This PC)
GUID (raw): E0-4F-D0-20-EA-3A-69-10-A2-D8-08-00-2B-30-30-9D
GUID (correctly translated): {20D04FE0-3AEA-1069-A2D8-08002B30309D}

This GUID can then be resolved against known Windows Shell GUID tables to determine the precise object it represents, providing critical context regarding the nature and location of the folder or virtual namespace with which the user interacted.

With the preceding structural analysis of the Shell Item, the hierarchical path associated with the most recently accessed namespace can now be more clearly resolved. Specifically:

BagMRU\1 == Desktop \ This PC

This mapping indicates that the root-level entry under the BagMRU key corresponds to the virtual shell namespace path beginning at the user’s Desktop and descending into the “This PC” (formerly “My Computer”) container. Such resolution is critical for accurately reconstructing the user’s navigation path through both standard file system directories and special shell folders.

Upon navigating to the subkey BagMRU\1 (resolved as “This PC”), a new MRUListEx value is presented for analysis (see figure below). Consistent with the established methodology, the examination will focus exclusively on the first entry in this MRU list.

Shell Size: 0x19
Class Type Identifier: 0x2F

A significant structural deviation is observed beginning at the third byte 0x2F within this Shell Item. This byte explicitly signals that the subsequent data represents a drive letter reference (volume identifier). Inspection of the hexadecimal dump confirms this interpretation, revealing the characteristic signature and formatting used by Windows to denote mounted volumes within the Shell namespace.

BagMRU\1\0 == Desktop\This PC\C:

This transition from virtual folder GUID-based items (such as “This PC”) to volume-specific Shell Items is a common pattern when descending from “This PC” into individual drive letters (e.g., C:\, D:\, etc.). Accurate recognition of this offset and structure is essential for correctly mapping the user’s navigation path through physical and logical volumes.

Having established that Shell\BagMRU\1\0 equates to This PC\C:\, further traversal is possible by selecting this subkey and repeating the process. In this instance, the key contains fifteen values, indicating fifteen child folders, with matching subkeys “0” through “14” present beneath it in the registry hierarchy. As always, we start with the MRUList to find our first entry.

The Data field for this Shell Item is notably longer and more complex than those observed in prior virtual folder entries. Analysis begins at offset 0x02 (third byte), which identifies the item type as a file system folder. The byte at offset 0x03 remains of undetermined purpose in this context. Offsets 0x04 through 0x07 contain the reported file size. As expected for a folder, this value is 0x00000000. The subsequent four bytes (0x08–0x0B) store the last modified timestamp, encoded in FAT32 format and expressed in UTC.

This is followed by two bytes representing the file attributes, which in this instance are set to 0x0030. The file attribute value 0x0030 in a Shell Item structure (as seen in BagMRU ShellBags entries) signifies the combination of two standard Windows file attributes:

• 0x0010 — FILE_ATTRIBUTE_DIRECTORY
• 0x0020 — FILE_ATTRIBUTE_ARCHIVE

This attribute pair helps forensic examiners validate that the reconstructed path points to a real directory on a volume, and it provides additional behavioral context—the folder was likely created or had content changes before being accessed via Explorer. The Archive bit is commonly set by the operating system when a folder or its contents have been created or modified since the last backup. It signals to backup software that the item should be included in the next backup operation.

The next eight bytes typically encode the folder’s short name (8.3 DOS-style format). Advancing further into the structure, the full folder name is located toward the terminal portion of the Shell Item data, usually preceded by its character length and stored in Unicode. This detailed binary layout is characteristic of File Entry Shell Items and supplies critical metadata—including MAC timestamps, attributes, and both short and long names—enabling forensic examiners to accurately reconstruct the target folder’s identity and temporal properties as they existed at the time of user interaction.

While illustrative, this manual enumeration process becomes exceedingly laborious when applied to the hundreds or thousands of nested entries typically present within the BagMRU hierarchy. Comprehensive reconstruction necessitates systematic interrogation of each parent key, parsing of the binary values containing child shell items, and recursive descent into the associated subkeys.

This hierarchical reconstruction is forensically significant because it identifies specific folder namespaces with which the user account has interacted. Such interaction includes opening, navigating, creating, modifying, renaming, deleting, or copying operations within the Windows shell environment. Mapping a user’s traversal through the file system can yield critical behavioral intelligence. For example, it may reveal unauthorized access to other user profiles, interaction with removable media exhibiting suspicious naming conventions (e.g., F:\), or navigation to sensitive directories hosted on network shares, SharePoint sites, or synchronized cloud storage containers such as OneDrive. When combined with registry LastWrite timestamps and embedded shell item MAC times—addressed subsequently—this data provides precise temporal attribution of user activity within the namespace.

Due to ShellBags' inherently complex, non-intuitive binary structure, manual analysis is highly impractical and error-prone. Forensic examiners must therefore rely on specialized parsing utilities to extract, interpret, and present the data in a forensically actionable format. While numerous digital forensic suites offer varying degrees of ShellBags parsing capability, two of the most robust and widely adopted dedicated tools are:

• ShellBags Explorer (GUI edition)
• SBECmd (command-line edition)

Both utilities were developed by Eric Zimmerman and represent de facto standards within the digital forensics community for ShellBags analysis. ShellBags Explorer provides a full graphical interface optimized for interactive examination and visualization, while SBECmd delivers equivalent parsing functionality through a lightweight, scriptable command-line interface—ideal for automation, batch processing, and integration into large-scale forensic workflows. Both tools support targeted parsing of individual registry hives as well as recursive processing of entire directory structures containing multiple NTUSER.dat and USRCLASS.dat files. When executed with administrative privileges, they can also parse the live registry of the currently logged-on user, enabling rapid triage on live systems.

ShellBags Timestamp: Last Interacted

The derivation of temporal artifacts within ShellBags often appears counterintuitive to the uninitiated and stems directly from the fundamental architectural constraints of the Windows Registry, specifically the reliance on registry key LastWrite times. It is essential to recall that each registry key maintains a single FILETIME timestamp, whereas individual registry values are stateless in terms of temporal metadata. Consequently, when a parent key encapsulates multiple values—each potentially representing distinct forensic artifacts—analysts encounter an inherent scarcity of reliable timestamps during registry-based forensic examinations.

This limitation is particularly evident in ShellBags analysis. Each BagMRU key maintains an enumerated list of subordinate folders alongside a Most Recently Used (MRU) ordering that reflects the sequence of user interaction. Consistent with the temporal attribution methodology observed in other MRU-centric keys (such as RecentDocs), the value occupying the highest MRU position (#0) is assigned the LastWrite timestamp of its parent key. This derived timestamp, designated as the "Last Interacted" time, provides the most precise indicator of when the user last engaged with that specific folder.

A critical forensic implication of this mechanism is that only a single child folder per BagMRU key can be directly associated with a Last Interacted timestamp. In instances where a parent key contains numerous child entries—for example, ten subfolders—definitive temporal attribution remains possible for only the most recent entry, leaving the interaction chronology of the remaining entries indeterminate through this artifact alone.

The figure below illustrates this principle with clarity. In the tabular view of ShellBags Explorer, sixteen folders are enumerated (six of which are visible due to truncation). Notably, only the folder named Hackware is populated with a Last Interacted timestamp, corresponding precisely to its MRU position #0—an expected finding in accordance with standard MRU implementation.

The lower portion of the figure presents the corresponding raw binary data extracted from the UsrClass.dat registry hive. Here, the parent key contains sixteen child entries (six of which are visible due to truncation). Parsing of the MRU list reveals an access sequence of 0, 1, 2, ... 16, confirming that value "0" represents the most recently used item. Examination of its binary content discloses the folder name "Hackware". As the apex MRU entry, it legitimately inherits the parent key’s LastWrite timestamp—2026-05-28 06:17:28 UTC—which aligns exactly with the value displayed in ShellBags Explorer. This nuanced understanding of ShellBags timestamp derivation is indispensable for accurate timeline reconstruction and user activity attribution in digital forensic investigations.

ShellBags First Interacted Timestamps: Forensic Derivation and Distinction

The identification and attribution of First Interacted timestamps in ShellBags diverge substantially from the methodology employed for Last Interacted times, reflecting a more nuanced application of registry key creation semantics.

Only BagMRU keys that function as terminal nodes—those possessing no subordinate child entries—may be associated with a reliable First Interacted timestamp. The underlying mechanism is as follows: upon the initial addition of a folder entry to the BagMRU structure, the Windows Registry creates a new key. The LastWrite time of this newly instantiated key is recorded at the moment of creation and corresponds directly to the user’s first interaction with that folder.

Provided that no child folders beneath this entry are subsequently accessed by the user, the original LastWrite timestamp remains unmodified. This preservation renders it a stable and forensically valuable artifact representing the precise time of first user engagement.

It is important to distinguish this from Last Interacted timestamps, which are exclusively attributed to the most recently used (MRU position #0) child entry of a parent BagMRU key. In contrast, when a folder constitutes a leaf node within the ShellBags hierarchy (i.e., it has no children), its original key creation timestamp is retained and serves as the authoritative First Interacted time. This differential timestamp behavior is critical for accurate chronological reconstruction in digital forensic examinations, particularly when establishing the earliest point of user interaction with specific directories independent of subsequent activity.

ShellBags Timestamps: Target (Shell Item) Times

The nomenclature “ShellBags” aptly reflects the presence of embedded Shell Items for each represented folder. Although these Shell Items generally contain less granular metadata than those in LNK files or Jump Lists, they preserve pertinent file system attributes of the target folder, regardless of its location—whether on local media, removable devices, or remote systems. Of primary forensic significance are the target timestamps captured within these Shell Items. These timestamps are recorded at the moment of first interaction and are not routinely updated thereafter. Specifically:

• "Created" denotes the original creation time of the folder on its originating file system.
• "Modified" typically reflects the most recent alteration to the folder’s content, such as the addition or deletion of files or subfolders.
• "Accessed" provides an indication of when the folder was last opened or its contents were read.

These preserved target timestamps assume heightened evidentiary value in scenarios where the original folder is no longer accessible—due to deletion, relocation to removable media, or existence on external or network-attached systems. They also serve as highly effective pivot points during timeline analysis. Sorting ShellBags entries by these columns can reveal behavioral patterns, such as clusters of newly created folders with anomalous naming conventions on removable media coinciding with an employee’s termination date or multiple folder modifications temporally aligned with a known external intrusion window.

Beyond temporal data, Shell Items frequently record additional file system metadata, most notably the Master File Table (MFT) Entry Number and Sequence Number for the folder. This information is readily accessible in the Details tab of ShellBags Explorer. These values enable reliable filesystem identification:

• NTFS: MFT Entry Number > 0 and MFT Sequence Number > 0.
• FAT: MFT Entry Number > 0 and MFT Sequence Number = Null.
• exFAT: Further validation through "Access" timestamp granularity (automatically performed by ShellBags Explorer).

Distinguishing filesystem types carries direct investigative implications. System drives are rarely formatted as FAT or exFAT, thereby assisting in the differentiation between internal volumes and removable or external media. Furthermore, precise MFT metadata can facilitate definitive correlation between ShellBags artifacts and specific devices, such as USB drives or network shares.

Forensic Limitations and ShellBags Reuse

Despite its richness, ShellBags analysis is subject to important constraints. A critical caveat is the potential for entry reuse. ShellBags keys are indexed by absolute path, inclusive of drive letter—a design shared with LNK files that precludes absolute uniqueness guarantees.

When a folder is deleted, its associated ShellBags entries (BagMRU and Bags keys) persist. However, if a new folder is subsequently created at the identical path with the same name, Windows reuses the existing ShellBags structures. While First and Last Interacted timestamps are updated to reflect activity on the new folder, the embedded Shell Item target timestamps and MFT metadata remain unchanged—retaining the original folder’s information. This creates a risk of temporal misinformation, where the displayed Created, Modified, and Accessed times pertain to a prior, unrelated folder.

This phenomenon is particularly prevalent with removable media. Multiple devices assigned the same drive letter (e.g., successive USB drives) that contain identically named folder paths will collide within the same ShellBags entries. Investigators must remain cognizant of this behavior to accurately interpret anomalies and provide defensible explanations during reporting. This comprehensive understanding of Shell Item target timestamps, their derivation, and inherent limitations is essential for robust timeline reconstruction and the avoidance of interpretive errors in digital forensic examinations.

Windows Updates and Registry Timestamps: Impact on ShellBags Artifacts

Commencing with Windows 10, Microsoft implemented a semi-annual major feature update cadence. These substantial updates have introduced significant modifications to numerous artifacts traditionally relied upon in digital forensic analysis. ShellBags provide a particularly conspicuous illustration of this phenomenon, as virtually all related subkeys are affected.

A common manifestation is the mass synchronization of timestamps, wherein multiple ShellBags First Interacted and Last Interacted times are uniformly reset to an identical value. Such a pattern—evident in the figure below, where dozens or even hundreds of folders appear to have been accessed at precisely the same moment—should immediately prompt forensic scrutiny. It is inherently implausible that such a volume of distinct folders would exhibit simultaneous user interaction.

When confronted with anomalous or temporally improbable timestamp clusters, examiners should systematically evaluate potential systemic causes. In contemporary Windows 10 and 11 environments, major feature updates represent a primary vector for such widespread artifact alteration.

Forensic Implications

In practical terms, First Interacted and Last Interacted timestamps within ShellBags—derived exclusively from registry key LastWrite times in both the UsrClass.dat and NTUSER.dat hives—retain evidentiary value only for activity occurring after the most recent major Windows update. Because these timestamps are directly tied to registry metadata, they are routinely overwritten during update processes.

During analysis, practitioners should first identify any conspicuous alignment of timestamps across numerous ShellBags entries. Cross-referencing these values against known Windows Update installation timestamps (available via Windows Event Logs, registry keys such as Software\Microsoft\Windows\CurrentVersion\WindowsUpdate, SYSTEM\Setup\Source OS, or update-related artifacts) is essential. Where a ShellBags-wide reset is confirmed, pre-update timestamps cannot be relied upon for accurate folder access attribution. However, any timestamps post-dating the update remain forensically significant, as they reflect genuine user activity thereafter. In the figure below, the last InstallTime update for the system matches within minutes of the strange timestamps seen for the ShellBags entry. This confirms a system update is almost certainly to blame.

It is noteworthy that Shell Item target timestamps (Created, Modified, and Accessed) are unaffected by this behavior, as they are embedded within the binary Shell Item data and not derived from registry LastWrite times.

Mitigation and Cross-Validation

While major updates inevitably result in the loss of historical temporal resolution within ShellBags, this limitation underscores a foundational tenet of digital forensics: no single artifact should be interpreted in isolation. Examiners are advised to corroborate ShellBags findings with independent sources that may preserve original timestamps, including LNK shortcut files, AutomaticDestinations Jump Lists, and RecentDocs registry keys.

This phenomenon also serves as a broader cautionary principle. Similar reset behaviors can affect other registry-derived artifacts. The ability to recognize unusual timestamp patterns, contextualize them within system events, and adapt analytical methodologies accordingly distinguishes rigorous forensic examination and enhances overall investigative reliability.

BagMRU and Bags Keys—Forensic Significance

The most probative artifacts within the ShellBags structure reside in the BagMRU key. This key furnishes essential details, including folder names, associated timestamps, and the Most Recently Used (MRU) ordering that reflects the sequence of user interaction. For deeper forensic insight, the corresponding Bags key offers supplementary value. These two keys are intrinsically linked through the NodeSlot value present within each BagMRU entry. As illustrated in the figure below, the NodeSlot numeric identifier directly maps to a corresponding subkey under the Bags hierarchy.

The primary function of the Bags subkeys is to store user-specific configuration metadata for the associated folder. This includes folder view type, displayed columns, sort order, icon sizing, and other view-state preferences. While the precise layout of a folder is seldom of direct investigative interest, the presence of such configuration data constitutes compelling evidence that the user actively engaged with the folder’s contents.

Distinguishing Exploration from Mere Interaction

It is noteworthy that a folder may generate a ShellBags entry without the user having visually inspected its contents. Certain Windows behaviors—such as viewing folder properties, navigating directly to a deeply nested subfolder (e.g., via TypedPaths in File Explorer), or performing operations like deletion, copying, or renaming—can instantiate ShellBags entries. This necessitates the use of the more encompassing term “interacted” rather than “accessed” when interpreting these artifacts. Parent folders in a hierarchical structure may also be recorded to preserve the required key topology, even if they were never directly opened.

Research by Vincent Lo has documented that folder deletion, copy, and rename operations can all trigger ShellBags creation. Complementing this, findings by David Cowen and Eric Zimmerman establish that the presence of substantive settings values within a folder’s dedicated Bags key serves as a strong indicator of actual user exploration. ShellBags Explorer automates this assessment via the “Has Explored” column. The tool evaluates whether at least two configuration values exist within the associated Bags key; a checkmark denotes a higher probability that the user opened and interacted with the folder’s interior. As with all forensic artifacts, examiners must exercise caution against absolute conclusions based on isolated indicators. Modern operating systems exhibit complex behaviors, and edge cases may result in configuration data appearing without direct user visibility—or vice versa. For findings of critical importance, corroboration with independent artifacts—such as LNK files referencing files opened from the folder—is strongly recommended.

Folder Type Identification via GUIDs

As an ancillary detail, each Bags\<#>\Shell\ subkey may contain a GUID-designated entry that identifies the assigned folder type. Common examples include:

• {5C4F28B5-F869-4E84-8E60-F11DB97C5CC7} – Generic folder
• {7D49D726-3C21-4F05-99AA-FDC2C9474656} – Documents folder
• {B3690E58-E961-423B-B687-386EBFD83239} – Pictures folder

These GUIDs provide additional context regarding the intended view state and the likely categories of files previously present within the folder. Eric Zimmerman maintains a current reference document for GUID-to-folder-type mappings to support tool development and manual analysis. Mastery of the interplay between BagMRU and Bags keys, coupled with the “Has Explored” determination, significantly enhances the precision of user activity reconstruction in digital forensic investigations.