WOFProvider

Note: Deploying an uncompressed WIM file (that is, created with DISM using the /Compress:none flag) will cause a BSOD on your machine when setting it as an external data source. Therefore, it is always recommended to compress the WIM file before deploying it. I leave the call stack related to the crash below in case anyone wants to investigate it:

nt!ExAllocateFromNPagedLookasideList
Wof!WimFSFAllocateReadCompletionContext+0x8f
Wof!WimFSFAllocateReadCbReadParameters+0x1d
Wof!WimFSFLoadResource+0x6e
Wof!WimFSFLoadOffsetTableHash+0x33
Wof!WimFSFAddFileOverlay+0x3cf
Wof!WimFSFRemountWim+0x146
nt!KxSwitchKernelStackCallout+0x2e
nt!KiSwitchKernelStackContinue
nt!KiExpandKernelStackAndCalloutOnStackSegment+0x2a3
nt!KiExpandKernelStackAndCalloutSwitchStack+0x188
nt!KeExpandKernelStackAndCalloutInternal+0x33
nt!KeExpandKernelStackAndCalloutEx+0x1d
Wof!WimFSFAcquireRundownAndRemount+0x7a
Wof!WimCbUpgradeReparseData+0x8f
Wof!WofPreFsctlSetExternalBacking+0x3a0
Wof!WofPreFileSystemControlCallback+0x3a8
FLTMGR!FltpPerformPreCallbacksWorker+0x58f
FLTMGR!FltpPassThroughInternal+0xc0
FLTMGR!FltpPassThrough+0x29f
FLTMGR!FltpFsControl+0xe0
nt!IopfCallDriver+0x5b
nt!IofCallDriver+0x13
nt!IopSynchronousServiceTail+0x1c5
nt!IopXxxControlFile+0x99c
nt!NtFsControlFile+0x5e
nt!KiSystemServiceCopyEnd+0x25
ntdll!NtFsControlFile+0x14
KERNELBASE!DeviceIoControl+0x1cc
KERNEL32!DeviceIoControlImplementation+0x75
WofUtil!WofSetFileDataLocation+0x136

The idea of this solution is to use it as an alternative method to drop malware instead of using the SyncProvider project for this purpose. WOFProvider makes it possible to use wofapi to set a WIM file as an external data source. Ultimately, this allows the content of a file on disk to be obtained not from the local file system itself, but from this external WIM file at access time. All this functionality is provided by the Wof minifilter (default altitude: 40700).

A WIM file is a disk image format created by Microsoft to store one or more compressed images in Windows. In short, it is a "compressed" file with a particular structure that allows storing and deploying a set of files. It is widely used as installation media and in maintenance tasks, although we are going to use it to store malware that goes unnoticed and that we can deploy without it being statically analyzed.

The idea is to create a WIM file with the Windows DISM utility from a directory that contains the malware we want to deploy. This will create the container file while preserving the original directory tree, except that the malware content will not be in clear text as such, but will be compressed and stored following the WIM file format. This means that, when dropping the WIM file to disk, unless the protection solution is forced to perform a manual scan, the malware will not be detected because the WIM file will be analyzed as a normal file without taking its particular storage structure into account (similar to what happens with other types of image container files such as ISO or VHDX).

Once the WIM is present on the system disk, we will create a placeholder file (similar to what we did with the Cloud Filter API) and set the WIM file as the data source for this file, so that when it is accessed the content is obtained from the WIM file and not from disk. This effectively allows performing the action of "writing malware to disk without it being statically analyzed". Now, to later execute the payload without it being analyzed at runtime, it is necessary to combine this deployment technique with the bindlinks technique already described here.

With all this, the malware deployment method would be as follows:

1. Create a WIM container file with DISM from a directory where we have stored the files we want to deploy on the target. In this case, again, we will use mimikatz.exe as the malware to deploy.

C:\Path\To\Puzzle\bin>dism /Capture-Image /ImageFile:C:\temp\file.wim /CaptureDir:C:\temp\wof_src /Name:"TestWOF" /Compress:fast

This will create a C:\temp\file.wim file with the content of everything under C:\temp\wof_src stored inside an image named TestWOF (index 1 can also be used to access the image).

2. We also need to know the SHA-1 hash of the malware we want to execute on the target, since it will be requested when creating the placeholder. We can easily obtain this with Powershell. Additionally, in the Scripts folder we can find the get_wim_hash.py file, which allows us to analyze the information of a WIM and of a file contained inside it in more detail (requires execution on Linux and previously installing wimlib-imagex):

PS C:\Path\To\Puzzle\bin>Get-FileHash -Algorithm SHA1 -Path "C:\temp\wof_src\dirA\notmimi.exe"
Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA1            E3B6EA8C46FA831CEC6F235A5CF48B38A4AE8D69                               C:\temp\wof_src\dirA\notmimi.exe

3. With all this, we can now drop the WIM on the target system and use WOFProvider to set it as an external data source for a placeholder that we will create specifically for this target:

C:\Path\To\Puzzle\bin>wof_provider.exe
> Wim file path: C:\random\folder\file.wim
> Placeholder path: C:\temp\notmimi.exe
> Resource hash: E3B6EA8C46FA831CEC6F235A5CF48B38A4AE8D69
> Image index: 1 (or TestWOF)

[+] WIM data provider sucessfully registered. Data source id: 1.
[+] Placeholder is now backed by a system data provider.
[-] Press any key to exit...

4. This will create a placeholder at C:\temp\notmimi.exe which, when accessed, will execute in this case the code corresponding to the file with hash E3B6EA8C46FA831CEC6F235A5CF48B38A4AE8D69 contained inside C:\random\folder\file.wim. This entire process of parsing and accessing the content of the WIM file will be performed transparently by the Wof minifilter. As happened with deployment through the sync provider, this technique is useful for dropping the malware without it being analyzed, but it is essential to combine it with the creation of a bindlink to execute the malware through its FRN.

5. Finally, when you want to remove the WIM as an external data source, simply press Enter to finish execution.

As an additional note, it should be clear that if the WIM file is analyzed explicitly (that is, Right click -> Scan file) with Microsoft Defender (and probably other security solutions, I did not test it), then the WIM parsing engine provided by the operating system will indeed be used and the malware contained in the WIM file will be detected. However, this will not happen if we simply write the WIM to disk and use it as an external source.