The file contains 12M+ of rows, each containing a set of popular hashes, and a file name extracted from my ‘good files’ repo (some dups may be found if f.ex. file name changes, but hashes don’t). These are primarily Windows-centric hashes (none or almost none of other OSes, firmwares, but occasionally some might have sneaked in). I can’t guarantee that all these hashes are good, but most come from reputable sources: (S)FTP and HTTP(S) locations made available by many software vendors, and software downloading sites over last 20 years.
The set is watermarked hence you have been warned. You cannot use this set for any commercial reason. You cannot ingest it to use for cross-referencing in any way and/or form. The only exception are: fully unlimited use by law enforcement, and for educational and non-commercial research purposes only.
We often hear of attackers bringing in their payloads via virtual drive images (f.ex. vhd,vhdx) in an attempt to bypass security solutions. The WIM files can be used to smuggle in tools and payloads to the target, too. In my previous post I discussed the $WIMMOUNTDATA Alternate Data Stream that is created by dism.exe when we use it to mount a WIM image.
Now, the way the WIM images are mounted is interesting for many reasons:
they are mounted read-only, so once mounted, can’t delete files they provide access to
the files they expose to the OS are not ‘created’ in any telemetry sense, so there are no ‘File Created’ events for them – it’s just a file system tunnel
they are tiny, and can even be easily encrypted/decrypted using available lolbin tools, or powershell
the .wim files themselves, once mounted, can’t be deleted
interestingly, when you create .WIM files from sources that include Zone.Identifier ADS (typically after downloading the files from the internet), these ADS will make it to the WIM image as well; so, have to be mindful of it
Here’s an example mimikatz.wim (pass: mimi) WIM image (it actually has a decent detection rate on VT). Its file list indicates it was created from a directory that included old mimikatz files downloaded directly from github (hence, ADS are present):
Combining the knowledge from this and previous post, one can start wondering…
If we mount an innocent WIM image first, one that lists only good (or at the very least – dummy) files, and then, we export the mounted directory’s $WIMMOUNTDATA ADS, modify it to point to a different WIM file, the bad one, then we write it back to the directory’s ADS… what will the system see/do?
Turns out, that modifying the ADS alone is NOT ENOUGH to fool the OS to ‘redirect’ the tunnel to a different image 🙁
Looking for other angles, we can search the Registry and we can discover that this whole WIM mounting business is nicely documented here:
under the following key:
HKLM\SOFTWARE\Microsoft\WIMMount\Mounted Images\
So, what about we change the WIM Path value to point to the bad WIM image, and restart the system?
Nothing.
The ‘mounted’ directory will still list the files from the original ‘neutral’ WIM image only.
Okay, so it’s time we explore the actual $MFT of the C: drive where we mounted our WIM image to. To our surprise, the $MFT does include FILE records for every single file from our neutral WIM image!
Oops. Our original assumption that there are no ‘File Create’ events in our telemetry was wrong!
Literally, the dism.exe is reading the WIM image file and then it is recreating its codified directory structure by writing it to a destination folder, recursively; and for each directory or file, or even ADS, it is triggering the “File Create” events:
And there is one more wrong assumption we need to address:
the WIM images are mounted as read-only
The dism.exe program tells us it is not true when we try to remount the WIM image that is already mounted:
Exploring the mounted directories, you can easily delete files and directories.
Oops.
At this stage, you probably realize that this post is written from a perspective of an unreliable narrator…
