Yes, another excellent question came up by one of my students:
If a user mounts the volume to a mount point, what artifacts could we find for the USB?
Starting I think from Windows 8.1 or 10, a user could mount a volume into an empty directory. Which means, that a USB could be mounted to a directory and then the user accesses the content of the volume using that directory. A feature in the past was only seen on POSIX operating systems, such as Linux. The scenario I will be using for this experiment, is a user mounts a volume (USB) to a directory and also removes the drive letter. I will be using the C:\Mountpoint as the mount point for the USB.
Note(s) before you continue reading:
1. This post does not cover all USB artifacts (registry keys, registry values, events, etc), only the ones needed to answer the question above
2. The experiment in this post was repeated three times and they all led to the same results you will find below
PART#1 – SETUP
First as we can see in figure 1.1, the USB labeled FOR340USB has a drive letter E:, so let’s remove it.
Figure 1.1 – Drives Available
Now let’s add the mount point, which could be done as seen in figure 1.2.
Figure 1.2 – Adding a Mount Point to a Drive
Go ahead and remove the drive letter as seen in figure 1.3.
Figure 1.3 – Removing Drive Letter
Just a check kind of thing! On your Windows Task bar, check that the drive is no longer seen there, as seen in figure 1.4.
Figure 1.4 – USB Drive Not Seen in Task Bar
If you have not checked my previous post about what artifacts you will find or where to find them, when we remove a drive letter? Please check my previous post titled “No Drive Letter, No USB Evidence? Think Again!“.
PART#1 – SYSTEM HIVE
Starting with Registry Explorer and doing a quick check of the USBSTOR as seen in figure 2.1 and the MountedDevices as seen in figure 2.2, we can find the following:
Figure 2.1 – USBSTOR Keys
Figure 2.2 – MountedDevices Keys & Values
??_USBSTOR#Disk&Ven_Kingston&Prod_DataTraveler_3.0&Rev_PMAP#5404A6F4E0A1E2719902006D&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
Breaking it down:
1. Type: Disk, Vendor: Kingston, Product: DataTraveler_3.0, and finally Revision: PMAP
2. Serial Number: 5404A6F4E0A1E2719902006D&0#
3. Disk GUID: 53f56307-b6bf-11d0-94f2-00a0c91efb8b
If we check the Portable Device Enumerator Service (WPDBusEnum) as seen in figure 2.3, we can see that this time the FriendlyName is actually a mount point and not a name as we’ve seen in previous analysis!
Figure 2.3 – WPDBusEnum Keys & Values
Finally, since we are still examining the SYSTEM hive, let us also check for executables seen on the drive by checking the AppCompatCache as seen in figure 2.4 (with a quick Mountpoint filter).
Figure 2.4 – MountedDevices Keys & Values
PART#2 – SOFTWARE HIVE
If we check the Windows Portable Devices keys as seen in figure 2.4, we can find the same FriendlyName, which is a mount point and not a name.
Figure 3.1 – Windows Portable Devices Keys & Values
Not much left, let’s move to the final interesting part :)
PART#3 – NTUSER HIVE
Now we need to check which user had this mount point configured, so we will be loading the NTUSER hive and first go to the MountPoints2 key, we can still see the Volume GUID, but the interesting thing we find this time, is a key under CPC named LocalMOF with the a value pointing to our mount point as seen in figure 4.1.
Figure 4.1 – LocalMOF Keys & Values
The full path: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\LocalMOF
Did the user run something from this mount point (USB Drive)? Well let’s check the UserAssist keys and values. After doing that with a quick filter as seen in figure 4.2, we can see the user ran 3 programs off this location procexp64.exe, a.exe, and DCode.exe and the details in the same figure 4.2.
Figure 4.2 – UserAssist Values
Now another excellent location to check for evidence is the Program Compatibility Assistant keys found under the user registry hives. Yes, here I am referring to AppCompatFlags Registry Keys. Harlan Carvey has a plugin “appcompatflags” for these keys and you can read more about them from Corey Harrell’s post here. After using the plugin with RegRipper, we can see some more entries related to this mount point of our user’s USB drive.
as seen in figure 4.3.
Figure 4.3 – AppCompatFlags Values
And that’s it for this post…
SUMMARY
So were we able to answer the question at the beginning of the blog and here is a summary of findings:
1. SYSTEM HiveControlSet001\Enum\SWD\WPDBUSENUM\
– ContainerID
– FriendlyNameControlSet001\Control\Session Manager\AppCompatCache
2. SOFTWARE HiveMicrosoft\Windows Portable Devices\Devices\SWD#WPDBUSENUM#_??_USBSTOR#\
3. NTUSER HiveSoftware\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\LocalMOF
– Mount pointSoftware\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store
– Values to used executables
Others not mentioned in this post but in previous post:Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU
Useful Resources:
– Assign a mount point folder path to a drive, URL.
– Harlan Carvey’s AppCompatFlags Plugin, URL.
– Revealing Program Compatibility Assistant HKCU AppCompatFlags Registry Keys, URL.
