Home » Research » Part 5: USB Device Research – Directory Traversal Artifacts (Shell bagMRU Entries)

Part 5: USB Device Research – Directory Traversal Artifacts (Shell bagMRU Entries)

In this post I will cover artifacts related to directory traversal. In the last post I went over the differences between USB transport protocols for when a USB is first attached to a system. In this post I will continue divulging the findings of my research by going over the directory traversal artifacts for MTP devices and compare them to the better understood MSC devices.

In forensics, when one mentions directory traversal, the artifact that comes to mind is Shell Items. In Windows, shell items keep track of the folders, files and more that a user accesses through Windows Explorer. In this post I will cover bagMRU entries for MSC devices, but only as a way to set up the discussion for MTP bagMRU entries. If you would like to learn more about shell items, feel free to check out the following links:

Shellbag Research
Shell Item Format
Harlan Carvey Shellbags
Will Ballenthin Shellbags
Sans Windows 7 Shellbags
Shell Item Wiki

Currently, there is little information available for shell bagMRU entries related to MTP devices, so I hope to cover much information here.

1.0 Test 2: Traversing Folders in Windows Explorer

The purpose of this test was to compare folder traversal artifacts for MSC and MTP devices so that differences between the two protocols can be identified and analyzed.  Also, keep in mind that the information provided in the analysis of the bagMRU entries may not be complete or entirely accurate as the Shell Item Format is an undocumented Windows structure and research is ongoing in the forensics community. I have provided, to the best of my ability, the most accurate information stemming from the research of others as well as my own personal research.

1.1 Scenario 1: Traversing Folders on an MSC Device in Windows 7

Shell items for MSC devices have been documented and studied in the forensic community, so the reason for including this section is mainly for comparison purposes with MTP devices.

To identify and analyze artifacts, the testing environment consisted of a clean install of Windows 7 with Service Pack 1 running as a virtual machine in VMWare. First, a device was inserted and initial reports were pulled from the system. Then, using Windows Explorer, the mount point associated with the device and several sub-folders were opened. Finally, change comparison reports were captured, and pertinent files were copied and cataloged.

While I will include only one example in this section, this test was run on a variety of MSC devices to ensure that the information to be presented is an accurate representation of what was found in testing.

1.1.2 Example: Traversing Folders on a Flash Drive

A SanDisk Cruzer thumb drive was attached to a VM running Windows 7. Then, Windows Explorer was opened where it could be observed that the device was mounted under “Devices with Removable Storage” and was given drive letter (E:). To populate entries in the registry under the bagMRU key, first E:\ was opened, then the folder “test-folder1″, then “test-subfolder 2″.

MSC-traverse

1.1.2.1 Traversing Directories

As a result, the following entries were created in the UsrClass.DAT hive:

  • E:\ – \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0:
  • “test-folder1″ – \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0:
  • “test-subfolder 2″ – \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0\0:

For an analysis of the registry entries created, see image 1.1.2.2 below.

Analysis

1.1.2.2 Analysis of Registry Entries

1.2 Scenario 2: Traversing Folders on an MTP Device in Windows 7

In Windows 7, when comparing the information found for MSC devices to MTP devices, the overall structure of the Shell bagMRU keys and subkeys were vastly different.

From testing, it was apparent that bagMRU entries for MTP devices is much more complex than MSC devices. In this section, we will look at the bagMRU entries that are populated as a result of traversing directories on a Galaxy S3 phone as our example. For the limited number of MTP devices tested, the bagMRU entries that were generated remained fairly consistent in structure with a few minor differences.

To identify and analyze artifacts, the testing environment consisted of a clean install of Windows 7 with Service Pack 1 running as a virtual machine in VMWare. First, a device was inserted and initial reports were pulled from the system. Then, using Windows Explorer, the mount point associated with the device and several subfolders were opened. Finally, change comparison reports were captured, and pertinent files were copied and cataloged.

You can download the registry files for the MTP devices tested below:

Win7_1-sandisk_sansa_m240.zip
Win7_2-samsung_galaxys3_android.zip
Win7_3-samsung_galaxys4_android.zip

1.2.1 Example: Traversing Folders on a Samsung Galaxy S3 Phone

A Samsung Galaxy S3 phone was attached to a VM running Windows 7 using MTP. Then, Windows Explorer was opened where it could be observed that the device was mounted under “Portable Devices” and was given the name “SCH-I535″. To populate entries in the registry under the bagMRU key, first “SCH-I535″ was opened. After opening the root device, two storage areas were available: “Card” and “Phone”. The storage area “Card” was opened first, then the folder “Android”, then the sub-folder “data” was opened. Next, the storage area “Phone” was opened, then the folder “Alarms” was opened.

mtp-analyze

1.2.1.1 Traversing Directories

After navigating through the directories, the following entries in the registry were created:

  • “SCH-I535″ – UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0:
  • “Card” – UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0:
  • “Phone” – UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\1:
  • “Android” – UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0\0:
  • “data” – UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0\0\0:

It should be noted that even though the folder “Alarms” was opened, it did not create a BagMRU entry. Currently, I am unsure why this is the case and further research will be required.

1.2.2 MTP Shell bagMRU Entries: A Closer Look

The data contained within the key \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7 for value name “0” identifies the DeviceInstance ID (device path) and the FriendlyName (device name) of the device that was mounted.  As shown below, the entry has a considerably different structure than was seen for MSC devices. See image 1.2.2.1 below for a detailed analysis.

1.2.2.1 Root Device: \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0:

1.2.2.1 Root Device: \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0:

For MTP devices, there may be more than one storage area. For example, tablets and smart phone sometimes have two storage areas: internal storage and external storage (a microSD card). If that is the case, each storage area will be mounted within Windows Explorer under the root of the device. By opening the root mount point for the device in Windows Explorer, the storage areas for the device are displayed as separate “drives”. If the device has only one storage area, then only one “drive” will be listed. In the example below, the Samsung Galaxy S3 phone (mounted as SCH-I535) has two storage areas: one labeled “Card” and one labeled “Phone”.

While the format for the Storage ID (begins with “SID”) for a device’s storage area, as shown below, is not known and requires further research, a common feature is that the first comma separated value appears to classify primary and secondary storage areas. Where 10001 represents the devices main storage (or internal) and 20002 represents a secondary storage area on the device.

For the analysis, I have included only the entry related to “Card”. See image 1.2.2.2 below for more details.

1.2.2.1 Storage Area "Card": \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0:

For MTP devices, the folders contained within each storage area also have a very different bagMRU entry structure compared to bagMRU entries for MSC device folders. See the image 1.2.2.3 below for a detailed look at the bagMRU entry created for the folder “Android” found in the storage area “Card”.

7-0-0-0

1.2.2.3 “Android” Folder in “Card”: \Local Settings\Software\Microsoft\Windows\Shell\BagMRU\7\0\0\0:

Conclusion

As seen previously, MTP bagMRU entries are considerably different from their MSC counterparts. Due to the prolific nature of shell items across the Windows operating system, it is important for an examiner to understand the structure of these entries in the event that they were to come across them during an analysis of a system. Currently, not all tools account for MTP devices in the reporting output. Therefore, an examiner may have to manually verify whether these entries exist and the nature of those entries if deemed pertinent to an investigation.

You can download the bagMRU entry analysis in the form of an excel spreadsheet here:

MSC bagMRU Analysis
MTP bagMRU Analysis

 

Coming up…

In the next post of this series, I will cover artifacts generated as a result of opening files from MTP devices, as well as revisiting MSC artifacts related to opening files.

commentscomments

  1. 4n6k says:

    Nicole,

    This is fantastic research; great job. These devices were definitely in need of some further investigation, and you brought that to the table. The visuals are very organized and easy to follow.

    It is strange that the “Alarms” folder did not show up in shellbags. I ran a similar test on a Moto X, but the storage layout was not the same (I don’t have a Galaxy S3 at my disposal at the moment). However, I can confirm the activity that you are seeing. After setting the USB connection as “Media (MTP)” [and later as "Camera (PTP)],” I tried traversing the internal storage. The directory traversed was “Computer\XT1060\Internal storage\DCIM\Facebook.” Now here’s the interesting part: the “Facebook” folder only showed up in shellbags after closing the window or pressing the “back” button in explorer. From my previous testing of shellbags (non-MTP/PTP devices), I was NOT seeing this as a regular occurrence (or a normal occurrence at all, for that matter). This only seemed to happen to the “youngest child” subkeys. That is, I wasn’t seeing the Facebook directory because it was the last directory traversed in that specific path. I saw everything before it in shellbags, though. This would explain why you weren’t seeing the “Alarms” folder. If you close the window, wait a little bit, and then export the UsrClass.dat, do you see the Alarms folder then?

    Thanks for doing this research; it sheds some more light on the behavior of this artifact. MTP device analysis was needed and you went ahead with it quite nicely.

    P.S. I am sure you are familiar with this, but if you haven’t checked out the #DFIR Twitter community, I would suggest hopping on there with the stuff you’ve written; I think your posts would garner the attention they deserve there.

    • Nicole Ibrahim says:

      Hey,

      Thank you for your comment, words of encouragement, and insight.

      The “Alarms” folder not showing up is interesting. I completed what you had suggested, but instead went to the “Alarms” folder then navigated to the root of the device. Looking at UsrClass.DAT, the “Alarms” folder was present even without having to close Windows Explorer. It appears that the last folder visited on an MTP device does not get registered unless you navigate away from that folder within Windows Explorer. I haven’t checked if you have to visit an area on the device itself, or if it will get registered by simply navigating away to any area within Windows Explorer.

      Once again, thanks for reading through my postings. I hope that my findings will be beneficial for you and others in the industry.

      Your feedback and input has definitely helped me understand why the “Alarms” folder was not showing up. And as always, more research is needed to really solidify and explain what is going on.

      I’ll be sure to check out the #DFIR Twitter community. And I’ve read through your blog and you do great work. Thanks for being a valuable resource that I will continue to use.

      - Nicole

      • 4n6k says:

        Hey, thanks for the kind words and the reply. It’s great to see follow-up work being done. Navigating away from the folder in question definitely seems to result in the behavior you’ve described. And as mentioned earlier, this also looks to be unique to MTP devices, as I haven’t seen this behavior on local/removable drive folders.

        Thank YOU for sharing your work. It’s certainly helpful. I truly commend you for putting in the time to research this. So thanks!

        Keep up the great work.

        -Dan

  2. keydet89 says:

    “Currently, not all tools account for MTP devices in the reporting output. ”

    Can you clarify this?

    Thanks.

    • Nicole Ibrahim says:

      Absolutely, what I plan to do is include a section in my final post that will go over some of the popular tools used to parse usb device artifacts and go over what tools do and do not account for MTP devices correctly. Thank you for your comment. I will be sure to address what I mean by that statement in the next post.

      -Nicole

  3. V. Lu says:

    Thank you for an excellent blog series. This has been immensely helpful.

    What is the registry viewer you are using that is offering a “template” type view of the value being viewed ? The color coding is very useful.

    • Nicole Ibrahim says:

      Thank you for your feedback. The “template” view is the product of copying the hex and data from 010 hex editor, pasting into an excel spreadsheet and manually doing the color coding. However, 010 editor does allow you to create your own templates with a similar color coding effect and breakdown of highlighted values.

Leave a Reply