DLL Hijacking with DeviceCensus.exe on Windows 11

Summary

Tested on Windows 11 10.0.22000 N/A Build 22000.

During January I was investigating Windows 11 and some of the binaries that were installed by default to identify behaviors that could be used for malicious purposes.

The binary DeviceCensus.exe located in C:\Windows\System32, when is copied to another different path and it is executed, it tries to load more or less 11 DLLs in the directory where it was executed. Let's say that if you try to execute this binary from AppData path, then it tries to load the DLLs from AppData. However, if the DLL doensn't exists in AppData, then it tries to load from System32.

Then, if you copy this binary in AppData and create a DLL with the same name that tries to load, the DLL is loaded.

info

I would like to say that I reported this to MSRC and they told me that it is not a vulnerability. They sent me the following information explaining why it is not a vulnerability :).

Thanks MSRC for explaining!

Reference 1: https://devblogs.microsoft.com/oldnewthing/20150527-00/?p=45024

Reference 2: https://msrc-blog.microsoft.com/2018/04/04/triaging-a-dll-planting-vulnerability/

Testing the behavior

First, I moved the binary DeviceCensus.exe to AppData path and executed it.

As you can see, there are different DLLs that the binary is trying to load from the path where it was executed. However, some of them can't be loaded during the execution.

Focusing in the DLL called umpdc.dll, we can see how it was loaded because the first option of load doesn't work. It is known as DLL Hijacking.

However, for this PoC, I've created a DLL called umpdc.dll with a MessageBox. Instead of a MessageBox, it can establish a reverse shell or whatever action (drop another binary and execute it, load in memory malicious code, process injection, etc.)

Also, for this PoC, I’ve created a VBS to do the following chain attack:

1. Connect to GitHub and Download a DLL
2. Drop the DLL in %appdata%
3. Copy DeviceCensus.exe from system32 to %appdata%
4. Load DeviceCensus.exe in order to load the malicious DLL from path where is executed.

The initial access could be whatever, either spearphising with link or spearphishing with attachment. The typical scenario is a office file with macros, which after the execution, connects to remote servers to download a second-stage payload. In this case, I've executed directly wscript.exe to load the VBS file.

The above image show the Sysmon Events IDs (EVID) for each step of the PoC. This can help you to create detections rules for similar scenarios, not focusing only in the DLL and binary. The sysmon configuration used was the one of SwiftOPneSecurity adding Image Load events.

PoC

When the VBS file is executed on the target machine, we can see the following events made by wscript.exe. After the execution, the first thing to do is connects to GitHub and download the DLL into the local system.

Then, the DLL is created in the AppData path, because we configured it in the VBS script. Also, the file DeviceCensus.exe is copied from C:\Windows\System32 to AppData.

The last task that the VBS does, is run DeviceCensus.exe, which after the execution it can load the UMPDC.dll.

The message will appear on the screen when the DLL is loaded.

The full activity on Sysmon looks like this.

VBS Script

Download from gist: https://gist.github.com/jstnk9/c0f8861cf1247741812f9f0210b591ee

DLL

Download from git: https://github.com/jstnk9/Research/blob/main/UMPDC.dll

DLL code from gist: https://gist.github.com/jstnk9/034d6add18a2692e451b254472a823f9

Contact

Twitter: https://twitter.com/Joseliyo_Jstnk

LinkedIn: https://www.linkedin.com/in/joseluissm/