First entry: Welcome and fileless UAC bypass

welcome to my blog about Windows and scripting in Windows. This is my first entry and I would like to start with a post about an UAC bypass which I found.

I’m a German student and began reading a lot of things about User Access Control (UAC) bypasses for my master’s thesis and I started investigating my own system environment. A few days ago, I found an UAC bypass I want to share with you.

Please note: It is a proof of concept and is not intended for illegal usage.

Tested on: Windows 10.0.15063

Tested on Windows 10.0.15063

Attack vector:

fodhelper.exe

Preconditions:

The current user is member of the local administrator group

The operating system is Windows 10

Implementation:

Fodhelper.exe was introduced in Windows 10 to manage optional features like region-specific keyboard settings. It’s location is: C:\Windows\System32\fodhelper.exe and it is signed by Microsoft.

As you can see in the picture above, the program is allowed to elevate itself to run in a high integrity context automatically. There is no need for any user interaction to allow the process to elevate. This means that if we are able to tamper the behavior of the binary to load a file of our choice, this file may start in a high integrity context, too.

How to investigate the behavior of the file to find a concrete attack vector? => Process Monitor!

When initiating the start of fodhelper.exe, process monitor starts to capture the process and reveals (among other things) every read- or write-activity to the registry and filesystem. One of the interesting activities are the read accesses to registry, although some specific keys or values are not found. Especially registry keys in HKEY_CURRENT_USER are great to test how the behavior of a program may change after the creation of a not yet existing registry key, because we do not need special privileges to modify entries.

E.g. fodhelper.exe is looking for “HKCU:\Software\Classes\ms-settings\shell\open\command”. By default this key does not exist in Windows 10.

Output of Process Monitor: HKCU:\Software\Classes\ms-settings\shell\open\command – NAME NOT FOUND

After creation of the key: “HKCU:\Software\Classes\ms-settings\shell\open\command”, fodhelper.exe will find it and will start looking for the value: “HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute” which it would not look for, if the mentioned key did not exist. As soon as the value “DelegateExecute” exists, it will be found, too, even if it is empty.

Output of Process Monitor: HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute – NAME NOT FOUND

Once the value “DelegateExecute” is created, fodhelper.exe will look for the default value in: “HKCU:\Software\Classes\ms-settings\shell\open\command\”.

Output of Process Monitor: HKCU:\Software\Classes\ms-settings\shell\open\command\(Default)- NAME NOT FOUND

This value is the critical point. The registry value “shell\open\command\(default)” enables us to provide to the program additional instructions what to do when the program opens.

In this scenario, I set the value of “shell\open\command\(default)” to: “C:\Windows\System32\cmd.exe /c powershell.exe”. After this modification, fodhelper.exe will lookup the (default)-value and follow the instructions how to behave after the process starts. => start cmd.exe which starts powershell.exe (just checking if it is possible to pass parameters to cmd.exe, too)

As you can see, fodhelper.exe reads the (default)-value and starts cmd.exe with the provided parameters.

Output of Process Monitor: Process Start – cmd.exe

The result is an cmd.exe starting in a high integrity context which starts a powershell.exe in a high integrity context. In the picture below, you can see both the exact registry structure needed for this proof of concept and the cmd.exe started as an administrator.

High integrity cmd.exe

To demonstrate this vulnerability, I created and published a script on Github, which will create the registry keys, opens up “C:\Windows\System32\cmd.exe /c powershell.exe” and which deletes the registry keys.

This technique is based on a similiar flaw, found by Matt Nelson (https://enigma0x3.net/) and has the following benefits:

There is no need to drop a file on disk.

There is no need to hijack any .dll file

There is no need for any suspicious action on the operating system which could alert an antivirus software.

Ways of mitigation:

Do not use a local administrator account if you do not have to. Restricted users are not able to execute and elevate such programs.

Set the UAC level to “Always notify”, which leads to a prompt that needs to be accepted by the user.

Hey! Awesome write-up. I’m a cyber student myself (fairly new). I’m wondering, when it comes to UAC bypasses like this one, how do they work in the wild. My intuition is that you would need to already have access to a machine to even run the powershell script, and even then, powershell scripts dont run without user interaction by default, if I am not mistaken. So then presumably the use for such an exploit requires first that you (1) gain remote access as administrator, (2) force registry changes by some method, e.g. Metaspoit, (3) upload an executable to the host (also Metasploit), (4) fire off the executable with reduced suspicion and no UAC prompt by calling fodhelper.exe instead of your malicious executable, but have your exe linked to fodhelper in the registry. Does this sound right, or am I missing a more powerful use-case? Thanks!

instead of making it so complicated, you can make it full base64ed powershell payload like for example… in this case ill use powershell empire’s launcher .. while delivering malicious regkey .. ill simply extend command one which is shown in this article .. “HKCU:\Software\Classes\ms-settings\shell\open\command” => “reg add HKCU\\Software\\Classes\\mscfile\\shell\\open\\command /ve /t REG_SZ /d /f” and when ill restart fodhelper.exe i must expect an elevated agent 🙂

My thoughts here are that the attacker already has local admin access and the war is already lost. Attempting to prevent a local admin from doing anything is a fruitless exercise as there are many ways to circumvent UAC once this level of access is obtained.

For instance, one could simply set the EnableLUA registry key to 0 and bounce the system. I suppose your method does not require bouncing the system which is nice but it seems like a lot of work when most users don’t think twice when windows randomly goes down for a reboot (think updates/blue screens).

If you can come up with a transparent UAC bypass that does not require admin creds that would be useful but with admin access being required there really isn’t anything preventing an attacker from doing whatever they want (including disabling UAC and any AV that may alert on their activity).

Great job! I’m also investigating about UAC bypasses as part of my Master’s Thesis and, like you, I’ve discovered another way to perform an UAC bypass based on the one developed by Leo Davidson. Check it out on my github: github.com/L3cr0f/DccwBypassUAC

Also, I would like to recommend you another repository (if you don’t know it yet), UACME, which contains more than 30 UAC bypasses and, may be, it would be nice that your PoC appeared here.