Bypassing Windows 10 UAC with mock folders and DLL hijacking
Posted by AngelaWong, 01-08-2020
A new technique uses a simplified process of DLL hijacking and mock directories to bypass Windows 10's UAC security feature and run elevated commands without alerting a user.
Windows UAC is a protection mechanism introduced in Windows Vista and above, which asks the user to confirm if they wish to run a high-risk application before it is executed.
As users are repeatedly asked to authorize legitimate processes, which can get annoying fast, starting with Windows 7, Microsoft introduced inbuilt “exceptions” within the UAC framework.
This feature allows trusted system DLLs located under C:\Windows\System32\ to “auto elevate” to higher privileges without displaying a UAC prompt.
This allows system processes that need elevated permissions to execute DLLs and EXEs without requiring them to answer UAC prompts.
Last month BleepingComputer reported how security researcher Wietze Beukema found that 300 Windows executables were vulnerable to DLL hijacking that allows attackers to bypass the UAC security feature.
Building on the same technique, security researcher and pentester Daniel Gebert illustrates how Windows 10 User Account Control (UAC) can also be bypassed through a combination of DLL hijacking techniques and mock directories.
Introducing Windows 10 mock directories
A mock directory is an imitation directory with a trailing space. For example, whereas "C:\Windows\System32" is a legitimate, trusted location on Windows machines, a mock directory would look like "C:\Windows\ System32" (notice the trailing space after Windows\).
When creating mock directories, there are two restrictions:
- Mock directories cannot be directly created from within the Windows Explorer UI, so you'd need a simple script to accomplish the task.
- Not all directories can be mocked:
"A mock directory must include a [subdirectory]. It is not possible to create 'C:\Windows '. But it is possible to create 'C:\Windows \System32'," Gebert explains in his blog post,
To make a mock directory, you can simply use a PowerShell command like:
New-Item "\\?\C:\Windows \System32" -ItemType Directory
When done, the C:\ root folder will now contain two Windows folders, but in reality, the second one has a trailing space, as shown below.

Source: BleepingComputer
What makes mock folders so dangerous is that Windows, in some cases, like using File Explorer, treats "C:\Windows" and "C:\Windows
" as the same folder, as illustrated below.

Source: BleepingComputer
The treating of a mock folder as the actual folder it's named after, is where directories come into play.
A twisted approach
Beukema's original UAC bypass technique relied on finding system EXEs that would make ideal candidates for DLL hijacking. For example, "winstat.exe" is known to look for a bunch of DLLs (such as "d3d10.dll", "d3d11.dll", etc.) in trusted locations upon execution.
Should an attacker be able to rewrite one of these DLLs with a malicious one of their choice, "winstat.exe" would load that malicious DLL from the trusted directory, or a mock directory - depending on where is "winstat.exe" present.
However, to bypass UAC, Beukema's technique required at least some form of rewriting and recompiling of an existing DLL with the attacker's payload.
For many of these trusted DLLs that processes sideload, templates weren't available that pentesters could use. Not to mention, there were also some limitations to the technique.
When searching for DLL hijacking candidates, Gebert started by searching for templates on the web for legitimate Windows DLLs present in trusted directories.
On discovering such templates on GitHub, he compiled one with an added payload to spawn an elevated command prompt.
The template Gebert picked for this PoC was for "version.dll" due to his prior experience using the file in DLL hijacking exploits.

Source: Daniel Gebert's IT blog
After compiling this simple "version.dll", he copied it to the mock directory (C:\Windows \System32
). He additionally copied all legitimate executables (.exe) from the real C:\Windows\System32\ folder into this mock directory.
Therefore, the mock directory now had upwards of 600 Windows EXEs, and the only DLL file, "version.dll".
Then, hoping that one of the 600 EXEs would side-load "version.dll," Gebert started launching these executables one at a time while closely monitoring them.
While none of the EXEs were actively loading "version.dll," some of the EXEs had been looking for a "profapi.dll" file in the mock directory.
By merely renaming "version.dll" to "profapi.dll", Gebert was able to accomplish the trick. In his example, launching the legitimate Windows process, ComputerDefaults.exe from his mock directory successfully launched the altered "profapi.dll" (previously "version.dll") present in the same directory.

Source: Daniel Gebert's IT blog
More Information