# Shellbags

**Windows DFIR notes are no longer maintained on InfoSec-Notes. Updated versions can be found on:** [**artefacts.help**](https://artefacts.help/)**.**

### Overview

Location (starting from `Windows 7`):

* Files:

  `%SystemDrive%:\Users\<USERNAME>\NTUSER.dat`

  `%SystemDrive%:\Users\<USERNAME>\AppData\Local\Microsoft\Windows\UsrClass.dat`
* Registry keys:
  * `UsrClass.dat`:

    `HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU` `HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags`

    \=> Information related to `Windows Explorer` activity.
  * `NTUSER.DAT`:

    `HKCU\Software\Microsoft\Windows\Shell\BagMRU` `HKCU\Software\Microsoft\Windows\Shell\Bags`

    \=> Information related to Desktop and Network Locations activity.

    `HKCU\Software\Microsoft\Windows\ShellNoRoam\Bag` `HKCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU`

    \=> Unclear usage and limited forensic research.

Yield information related to **files and folders access**.

The `Shellbags` are `Windows Registry keys` designed as an user experience enhancing feature to keep track of Windows explorer graphical display settings on a folder-by-folder basis. For instance, a `Shellbag` entry is used to store the `View` mode of a folder (details, list, small / medium / large icons) as well as the column displayed (entry names, dates, sizes, etc.) and their order.

`Shellbags` contain folders and network shares to which a given user has navigated (using the `Windows Explorer`), but not files or subdirectories if they were not accessed. An exception is for `ZIP` files opened directly as folders through the `Windows Explorer`, that are stored as if they were folders (with their content thus partially referenced depending on the related activity). `Shellbags` entries are also generated by access to the `Control Panel` settings, on an interface-by-interface basis. The `Shellbags` entries related to the `Control Panel` can notably be useful to detect possible `Windows Firewall` (`Control Panel\All Control Panel Items\Windows Defender Firewall\Customize Settings`) or `Credential Manager` (`Control Panel\User Accounts\Credential Manager`) operations.

Various kinds of user activity may generate or update `Shellbag` entries (with different level of data depending on the activity):

* **first access** or renaming of folders, removable devices, or network shares through the `Windows Explorer` **systematically generate a `Shellbag` entry**
* graphical opening of compressed archives or `ISOs`
* access to the `Control Panel` interface
* modification of the folder view preferences
* etc.

`Shellbag` entries are stored in registry as a tree-like data structure, with the root target having the topmost `BagMRU` key. Each sub-target (sub directory for example) of the parent target are then represented with both:

* A registry subkey, named with a numerical value (starting from `0`).
* A registry value (in the parent target's registry key), named with the same numerical value and associated with binary data that notably contains the target's name.

Each `Shellbag` `BagMRU` registry key also contains a `MRUListEx` value, that maintains the entries visited order, i.e the order in which the sub targets of a target were accessed (the last sub target accessed having a `MRU position` of 0).

For example, `My Computer` will be associated with the topmost `BagMRU` key, `C:` to `BagMRU\0` if it was access first, `C:\Users` to `BagMRU\0\2` if it was accessed third, and so on and so forth. A hierarchical view of the `Shellbag` entries can thus be established.

### Information of interest

As the `Shellbags` entries are stored in user's specific registry hives, **targets** (folders, `Control Panel` interfaces, etc.) **access can be tied to a given user** through its `Shellbags`. `Shellbags` entries are populated only upon interaction (i.e are not prepopulated), the mere presence of a `Shellbag` entry for a target is thus evidence that the user interacted with the given target. `Shellbags` entries are not automatically deleted upon deletion of the related folders and can thus be a **source of historical information**.

The `Shellbags` entry for a given target yield the following information of forensic interest:

* the **target name and absolute path**.
* the **target `Modified, Access, and Created (MAC)` timestamps** (`UTC`), retrieved from the `$MFT` at the `Shellbag` entry creation (and not further updated).
* each entry in `ShellBags` `BagMRU` maintain a `MRUListEx` list, which records **the order in which the sub targets of a target were accessed** (the last sub target accessed having a `MRU position` of 0).

The **first and last interacted timestamps** can be **indirectly deducted for some targets**:

* The `First Interacted` timestamp can be inferred for some targets thanks to the tree like data structure of `ShellBags` entry. Indeed, for entries that do not have subkeys (i.e directory for which no subdirectory were accessed) the `First Interacted` timestamp is equal to the key's `LastWriteTime` timestamp. This is due to the fact that the key is created when a target is first accessed, and further activity for that target (such as display settings modifications) will only update the key's values. In such circumstances, the `LastWriteTime` timestamp reflect the timestamp of the key initial creation (as it is not updated upon updates to a key's values). When a subkey is created for the target (i.e when a subdirectory is accessed for that particular directory), the timestamp becomes unreliable as it reflect the creation of the subkey.
* The `Last Interacted` timestamp can be deducted for **the sub target that was last interacted with**. Indeed, as each `Shellbag` entry corresponds to a registry key, the key's `LastWriteTime` timestamp indicates when the `Shellbag` entry was last updated. The child-bag / sub-target that was last interacted with being known (`MRU position` of 0), this timestamp correspond to the last interaction timestamp for the sub target that was last interacted with.

Note however that major updates of the Windows operating system may result in modification of `ShellBags` entries, resulting in updated last written timestamp.

### Parsing

Eric Zimmerman's `ShellBagsExplorer.exe` and `SBECmd.exe` tools (`KAPE`'s `SBECmd` module) can be used to parse `ShellBags` entries.

`ShellBagsExplorer.exe` displays the `ShellBags` entries in a graphical user interface that allow browsing of the referenced targets, in a similar manner to `Windows Explorer`.

```
# Recursively enumerates the users' registry hives in the specified directory and parses their ShellBags entries.
SBECmd.exe --csv <CSV_DIRECTORY_OUTPUT> -d <C:\Users\<USERNAME> | C:\Users\ | DIRECTORY>

# Parses the ShellBags entries in the live registry.
SBECmd.exe --csv <CSV_DIRECTORY_OUTPUT> -l
```

***

### References

<https://www.sans.org/reading-room/whitepapers/forensics/windows-shellbag-forensics-in-depth-34545>

<https://www.sans.org/blog/computer-forensic-artifacts-windows-7-shellbags/>

<https://lifars.com/wp-content/uploads/2020/04/LIFARS-WhitePaper-Windows-ShellBags-Forensics-Investigative-Value-of-Windows-ShellBags.pdf>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://notes.qazeer.io/dfir/windows/_artefacts_overview/shellbags.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
