Windows Explorer Preferences in Shellbags

This blog post is in response to David Cowen’s Weekly Challenge as seen in his Daily Blog #610.

The three questions I will be answering in this post include the following:

1. What within a ShellBags entry would tell you how the user had set their directory viewing preferences?

2. What is the default view if no settings are changed?

3. If a user attempts to access a directory where they are not permitted, what directory viewing settings are left behind?


What are these Shellbags we speak of? There are a lot of great resources published about an in-depth analysis of Shellbags, which made some introductory research of this topic easy to jump into. Shellbags are an artifact where the actions of the user are tracked when elements such as folders and ZIP files are accessed, renamed, clicked, cut, copied, or even deleted. This allows a forensicator to understand what folders or places a suspected user has accessed. After investigating further, these questions will pursue the other information that can be found within Shellbags. Since Windows tracks almost everything, it should be no surprise that there is some content about Shellbags that can be expanded on.

For my explanation, I’ve decided to use Windows 10 1709 (Build 16299.15) in a virtual machine. The system is freshly installed. Tools on this machine include FTK Imager, Procmon, Eric Zimmerman’s ShellbagsExplorer and RegistryExplorer.

So, onto those questions!

1. What within a ShellBags entry would tell you how the user had set their directory viewing preferences?

To start breaking down this question, I will first explain a little background information about the ways in which Shellbags are stored. There are quite a few locations that need to be checked and cross-referenced to get the answer to these questions.

Since I’m using Windows 10, the primary locations where I will be focusing are the following:

  • %UserProfile%\NTUSER.dat
  • %UserProfile%\AppData\Local\Microsoft\Windows\UsrClass.dat

The purpose of Shellbags in NTUSER.dat is to store information for the Desktop, shared network folders, remote machines, and remote folders. As on the other hand, the purpose of UsrClass.dat is to store some similar information from the Desktop and shared folders, but most importantly information about ZIP files, local folders, and remote folders (Lo, 2014). There are some key differences between the multiple locations of the artifacts regarding content, therefore, we should always keep both in mind when investigating.

Three components of Shellbags I would quickly like to cover are BagMRU, NodeSlot, and Bags.

BagMRU is the parent registry key, which then has multiple sub-keys. Within these sub-keys, there can be more child entries which represent a deeper folder structure. An example shows this below.

Figure 1. The folder structure, Shellbags in BagMRU, and the translated BagMRU in Shellbags Explorer

To briefly break down Figure 1: a folder named ‘Apple’ was created and contains many sub-folders. On the far left is the ‘tree’ command run to show the original folder structure. The middle is the representation of UsrClass.dat when loaded into Registry Explorer. When loading this hive into Registry Explorer, you can find this key at 

Local Settings\Software\Microsoft\Windows\Shell\BagMRU. On the far right is Shellbags Explorer which does all of the hard work by parsing out and interpreting the information from BagMRU in UsrClass.dat. This also includes some time information and also the ‘Key-Value name path’ which directly aligns with the registry structure.

However, the meat and potatoes — and most relevant part of what is contained here is ‘Node Slot.’ The node slot tells us what sub-key we need to look for in the ‘Bags’ key. This is interesting because each sub-folder (ie. Apple, Banana, Cherry, etc) has its own Node Slot. This means we will have access to information about user preferences from each folder… To move forward to the answer of this first question, I will focus on Node Slot 11 (The folder named ‘Elderberry’). Any information provided in it’s “Bags” entry will include information about the folder’s view preferences.

Figure 2. Display of the folder settings for the ‘Elderberry’ folder.

I located the 11 key in the Bags key, and clicking the generated GUID (This GUID tells us the folder type). After clicking, we are now provided with many fields that can be observed and broken down to determine what they do. However, *spoiler*, they relate to user preferences. 

I’ve created a list below to show my understanding of what these values relate to. Some pretty extensive testing was performed to figure out what values would change when compared to the current Explorer settings. I even played around with Procmon to see what values changed, and what they may relate to. I’ve only included the most relevant fields for the sake of this question.

FFlags

This value has changed multiple times from the Desktop (Icon View) to Explorer itself in Details View. Some consistent values that I documented in Windows 10 are shown below. An additional resource I found was from Ivanti, however, I’m not sure what version of Windows 10 this refers to as my findings were different, but consistent. These values can definitely show some of the user settings when using the desktop, or if the user was within Windows Explorer it self.

Default View Options on Desktop0x40200224 (1075839524)
Default View Options in File Explorer0x41200011 (1092616209)
View Options -> Show Item Checkboxes0x49200001 (1226833921)
View Options -> Align Icons to Grid0x40200220 (1075839520)

From my limited research, these were the only FFlag values I consistently received. There were other flags I was not able to identify.

IconSize

This says it all in the name! The size of the icon is here and consistently changes with the current View setting. The value converted to decimal represents the thumbnails size in pixels. (ie. 16 = 16×16…)

Sort

Understanding how the sort order is saved to UsrClass was interesting. The last 8 bytes of the sort value will determine which column is being sorted, along with its desired order. 

Figure 3. Hex view of the “Sort” value inside a Bags entry.

The leading four bytes (0A 00 00 00) represent the column (je, Name, Date Modified). As where the second four bytes (01 00 00 00) indicate that the column was ascending in order.

0A 00 00 00 01 00 00 00

Red = Column ID being sorted by. (Name in this case)

Blue = Order in which it is sorted. (Descending in this case)

Some results of the default columns I was able to generate are below. There are hundreds of more columns you can add to File Explorer, therefore I only covered the default columns.

Column Identifiers:

Date Modified0e 00 00 00
Item Type0b 00 00 00
Size0c 00 00 00
Name0a 00 00 00

Order Identifiers:

Ascending01 00 00 00
Descendingff ff ff ff


Another example: Sort value ending in (0b 00 00 00 ff ff ff ff) will be sorted by the “Item Type” column in descending order. More column values are to be determined!

ColInfo

Unfortunately I was unable to decode the format in which this data is stored in. It appears to be a structure, but nothing that is human-readable. If you happen to figure this out please reach out to me!

GroupByKey:PID

This value is set for the “Group by” functionality in Windows Explorer.

Figure 4. Windows Explorer group functionality

This functionality will show us any potential grouping settings that were set in Explorer. It took some time, but I was able to decode most of the default values 🙂

CategoryGroupByKey:PID value
Name10
Date modified14
Type4*
Size12
Date created15
Authors4*
Tags5
Title2

*It is still unknown why these two values were the same.

Direct Response to Question 1:

There are many additional user options that can be determined when viewing the ‘Bags’ key inside UsrClass.dat. The sort order can easily be determined, along with the order in which the column is being sorted. We can also easily find the size of the thumbnails that are currently in use by referring to the ‘IconSize’ value. This will change if the user changes their view settings to Extra Large (256), Large (128), Medium (48), Small (32) or Details/Anything-alike (16). By understanding how Windows will display files within explorer, the investigator can make a definite prediction of the folder preferences.


2. What is the default view if no settings are changed?

There are two views that need to be taken into consideration. We have the view of the Desktop, and the view of the File Explorer. Both present the items in Windows differently by default. As where the Desktop is an icon-based approach with a grid, it is completely different than the list/icon view of the File Explorer. 

After reloading my VM to out-of-the-box settings, I proceeded to find the proper default settings for the two views.

Defaults of the Desktop:

  • FFlags set to Dec. 1075839524
  • Icon size set to 48×48
  • Sort order is by name (0x0A000000) and is descending (0x01000000)
  • The desktop is not grouped by default.
Figure 5. Bags view of Desktop view settings (From NTUser.dat)

Defaults of File Explorer:

  • FFlags set to Dec. 1092616209 
  • IconSize: 16
  • Sort: By Name, Decending
  • File Explorer is not grouped by default.

The only differences in this case were the FFlags Value and the Icon Size value. However, do note that the File Explorer key contains values for ‘Vid’ and ‘ColInfo.’

Figure 6. Bags view of a folder located in UsrClass.dat

3. If a user attempts to access a directory where they are not permitted, what directory viewing settings are left behind?

In a research paper published on the SANS Reading Room in 2014 (Windows Shellbags Forensics In-Depth by Vincent Lo), it was documented that in Windows Vista, 7, 8, and 8.1, a Shellbags folder will be created when a folder is created, clicked, right-clicked, opened, renamed, deleted, or copied (Lo, 2014). The subfolder will only be generated once the folder is opened, however, a base entry will still be added when the folder is clicked, even if the content (or lack thereof) is not shown to the user. 

I am targeting System Volume Information, which is a folder where which we cannot access the contents, however, we can still interact with the folder by clicking on it, double clicking it, and right clicking it. We do not have permission to perform any of the other operations, however, this will be enough to get some data generated.

So, when double-clicking the folder, we receive the following, as expected.

Figure 7. Denied access to a folder

So to find the answer to the question, the UsrClass.dat file was extracted to get more information about the settings left in Shellbags. 

Figure 8. Information in Bags relating to view settings

Immediately I found that the folder was added to the BagMRU list. I then took the Node Slot, and examined it in  the ‘Bags’ key in UsrClass.dat. As previously explained we cannot go into another sub-folder past the “Shell” folder because we do not have access to the System Volume Information folder, so it cannot have been generated. But there is some basic information that we do have. The two values here include KnownFolderDerivedFolderType and SniffedFolderType. There is little information to be found about these. But in his research, Lo mentioned that the SniffedFolderType value will provide information about the type of folder. But to no surprise, we are given ‘Generic’ for this case. 

A very limited amount of information is provided here as the full capabilities of Shellbags could not have been generated due to lack of permissions. These values will likely only provide information that is external to the folder. If you can’t access it, you can’t generate the artifact in this case.

Conclusion

Yes, in fact there is a lot that can be found inside the Bags key that are generated along with Shellbags. Not only can Shellbags tell us what folder locations have been accessed, but also the many preferences that were set in a specific folder, along with icon sizes, and user preferences. This was a very interesting topic to dive into, and I really enjoyed doing this research!

Adam Ferrante

@ferran7e

Reference Material:

https://www.sans.org/reading-room/whitepapers/forensics/paper/34545

Ali Hadi’s Challenge #3 | Solved!

Today I’ll be discussing and walking through my solution to Ali Hadi’s “Mystery Hacked System” challenge located on his website, here. I am told that this challenge has remained unsolved until now, and I am happy to announce and release how I completed it! It was quite interesting because of the small amount of evidence that was given, and a deep dive needed to be taken to reveal exactly how the attacker gained access to the machine. This post will cover my several hours of digging, and I hope you learn something along the way! Let’s go.

As for some background for this challenge: We are tasked with performing an IR investigation from a user who reported they’ve found a suspicious note on their system. We are given only the contents of the message (seen below) without its file path, and also no time at which the note was left. The evidence is given as a ~25GB E01 image. To start the investigation, I found the suspicious file located at C:\Tools\README.txt.

Since we can understand that this note was of concern to the user, it is very important to start developing a time frame of before the note was created to understand what led to this point. This will allow the investigator to find the root cause efficiently.

From here it was decided to start pulling some key artifacts to start analyzing. I first pulled the common registry files including SAMSOFTWARESYSTEM, and SECURITY. When viewing the SAM file I found there were only two users on the machine that had previously logged in (master and Administrator). With this being said, each user’s NTUSER and UsrClass files were extracted. Event logs were also extracted, which were eventually used to confirm some actions and events that took place.

I like to familiarize myself with the evidence before digging in too deep. In this case, I noted some important information that I thought would be useful. Some notes include:

Information about the machine to provide context
*All dates in UTC

As I started to go along, a small timeline was developing. Since I believe this dataset was generated for demonstration purposes, I now understood that we will likely find how the attacker got into the system by focusing from 7:03:15 PM to 7:24:39 PM on 12/11/15 (Time between system install date and “README” created time – this would be unrealistic if given a larger time period.).

To dig into some of the main artifacts, I started to analyze Shellbags from each user to understand some basic every-day actions that may have been performed. This will identify any possible notable locations where the user been when using File Explorer, which may even include USB devices that may have been plugged in, or even zip files that could’ve been opened. An additional note was found at C:\Users\master\Desktop\Docs\README.txt as a result of looking at each user’s visited locations. This added to the timeline further of more suspicious activity.

An additional README located within C:\Users\master\Desktop\Docs.

With minimal signs of how the attacker got into the system, looking for suspicious executions was next. When looking for traces of execution, I often use an outwards-in approach by viewing system-wide artifacts first, and then attributing them to a specific user. I started out by looking at the Shimcache. After loading the SYSTEM hive into Eric Zimmerman’s Registry Explorer (thanks Eric!), sorting the entries by time, and focusing in on the narrowed-down time period, the following entries were listed:

The machine’s Shimcache entries

When sorting through these logically at first, there was nothing suspicious that I noticed here. The first four entries look to be running the common tools one would see with VirtualBox’s Guest Additions. The fifth item in the list is Magnify.exe, the program launched when using the Magnifier Accessibility Feature. At first this file does not seem suspicious. However, when analyzing the Shimcache, it is important to understand what can be parsed. Part of each entry in the Shimcache contains the $STANDARD_INFORMATION last modified time of the target file (ref). When looking at Magnify, it shows this timestamp as 12/11/2015 7:18:54 PM. This time aligns perfectly within our suspected timeline as mentioned above — which is suspicious. This program is never modified through a Windows installation, but in this case it was modified. Worth a further look? I think so!

C:\Windows\System32\Magnify.exe

At first I thought this was going to be another investigative rabbit hole, so I extracted this file and put it into a virtual machine for further analysis. I generated an MD5 hash of Magnify.exe and ran it through VirusTotal to just get an idea of what I was looking at. Without having to upload the program to VT, it looks like it already scanned in the past, and returned clean results. However, the most interesting part of my results was the fact that this came back with a filename of cmd.exe. So at this point, I realized exactly what was going on. Magnify was a covert cmd executable!

This file was placed to easily spawn a cmd prompt by using the hotkey from the Windows Magnifier hotkey (Ctrl and +). The attacker placed this file to be able to gain access to a shell from the lock screen or from any place on the computer with local administrator access. This is likely how there was unauthorized access to the machine without leaving traces of some of the common execution artifacts. If a command prompt can be launched at the lock screen, it will not be attributed to a user, therefore those artifacts will not be left on the machine.

After replicating this within my own virtual environment, I was able to swap Magnify.exe for cmd.exe and perform actions with an system level prompt from the lock screen at anytime. This is pretty scary, and definitely worth nothing for future investigations. (After a few attempts, interestingly enough Windows Defender picked up on this access and eventually removed Magnify.exe). But system level access? Wow.

So… how did the attacker gain access? After replicating this within my own environment, the only way this could be done is by changing the owner of the Magnify.exe executable and swapping it out with another file of choice. In this specific case, I am unsure if the file was swapped out while the machine was off (files may have been accessed while the machine was off). However, one contradiction is evidence of an INDX record with the filename “cmd.exe”, which means cmd.exe was copied and likely renamed to Magnify (maybe the machine was running). Either way, physical access looks to be the final conclusion. However, I believe this can attack can be accomplished in a few other ways.

Thank you for spending the time to read about my work, I really hope that this clarifies any confusion for anyone else who takes a stab at solving this case. I also covered a guide of this challenge in video format if you’d like to check it out!

Stay tuned for more soon!

Adam Ferrante

@ferran7e

Alternate solutions:

Harlan Carvey’s Writeup