The Next Step: VHD Files and Metadata

Keeping with the theme from my previous blog post of building on what others have done and written about, and of assembling the pieces that are already available to build on a foundation built by others, I found something interesting that seems like a great "next step".

Anyone who's followed this blog for any length of time knows that I'm a huge fan of metadata, and that anytime a threat actor sends you metadata from their endpoint or environment, it's basically free money. For example, my posts on LNK metadata extraction and what can be derived from analysis of this data go back quite a ways. Another great example of the use of LNK metadata to further investigations comes from Mandiant, in this Cozy Bear blog post from Nov, 2018 (see fig. 5 and 6).

Tony Lambert recently shared a blog post where he dug deep into getting intel from VHD file metadata, and then digging in even further to get intel from metadata within the files found within the VHD file, in this case, an LNK file. In his blog post, Troy used EXIFTOOL to extract metadata from both the VHD file and the LNK file.

I used my own toolset and as with EXIFTOOL, found that the LNK file had no available "machine ID" or NetBIOS system name for the host on which it was built; this is one of the elements of an LNK file, based on the documented structure format. However, this may not be unusual or unexpected, because the time stamps embedded in the shell item ID list elements were zeroed out, as illustrated in figure 1.

Fig. 1: Shell Item ID List Time Stamps

If you took a close look at the Mandiant blog post mentioned above, you'd see that the time stamps from the shell item ID list elements were what the analysts used to develop intrustion/threat intel, based on how the time stamps changed between the 2016 and 2018 campaigns. Zero'ing these values out is not difficult (I've done it before), and may actually be scripted, or simply added to the LNK builder.

While the lack of time stamps doesn't give us anything to pivot on or track, there is something else embedded within the available PropertyStoreDataBlock within the LNK file; specifically, a SID, as illustrated in figure 2.

Fig. 2: SID embedded in LNK 

Using this SID, a Yara rule can be used to perform a VirusTotal retro-hunt for similar LNK files, or to scan across local malware repositories. For example, from this LNK file, we can see that it was built on a system using a built-in Administrator account (RID: 500). 

From an intrusion intel perspective, it's pretty clear that if a threat actor sends files to a target, they're very likely sharing a wealth of information about their development environment. When it comes to LNK files, even those embedded in disk image (ISO, VHD) files, a great deal of information about the development environment may be shared (as described by the folks at JPCERT in 2016).

Issues With VHD Files

Two of the issues with image files (ISO, IMG, VHD[X]) is that users can automatically mount them via a double-click, and that ISO files in particular did not not propagate mark-of-the-web (MotW), a security "setting" available on files downloaded from the Internet. The MotW issue with ISO files in particular was addressed in a Nov 2022 security update. If users have no legitimate business reason to automatically mount disk image files via double-clicking them, Huntress has a blog post that addresses disabling this capability, while still permitting programmatic access to the files, such as mounting a VHD or VHDX file via the Disk Manager. Disabling the ability for users to double-click and automatically mount these files as accessible file systems has been available for some time but the Huntress blog makes it a simple matter of copying and pasting the PowerShell code to change the setting.

Shoutz to Tony, not only for his work, but for sharing it with us all! We're all the better for it when we take the time to write about our research or experiences, sharing them with others.

Additional Resources
VHDX metadata table entry