Home
5 min read read

Bypass UAC Using FodHelper

UAC Windows FodHelper Red Team Privilege Escalation PowerShell
Cover: Bypass UAC Using FodHelper

In this proof of concept, we demonstrate a technique to bypass UAC by silently elevating from medium to high integrity. This bypass works on recent Windows versions (10 1709+).

What Is FodHelper?

FodHelper is a Microsoft support application for managing language and feature changes. The binary runs with high integrity on Windows 10 1709 and higher. By abusing how it reads registry keys, we can run a command of our choice with high integrity without a UAC prompt.

FodHelper Manifest Analysis

We need to inspect its application manifest, which is an XML file that describes and identifies the shared and private side-by-side assemblies that an application should bind to at the run time. We will inspect the manifest using the sigcheck utility from sysinternals

   sigcheck.exe -a -m c:\\windows\\system32\\fodhelper.exe

-a argument to obtain extended information and -m to dump the manifest

   <!-- Copyright © Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
  <assemblyIdentity type="win32" publickeyToken="6595b64144ccf1df" name="Microsoft.WIndows.Fodhelper" version="5.1.0.0" processorArchitecture="x86"/>
  <description>Features On Demand Helper UI </description>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="requireAdministrator"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <DpiAware>true</DpiAware>
      <autoElevate>true</autoElevate>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

As we can see in the results, the application is meant to be run by administrative users and requires the full administrator access token. The AutoElevate flag is set to true, so the executable can auto-elevate to high integrity without prompting the user.

Process Monitor: Finding the Registry Key

Now, we will use Process Monitor from the sysinternals suite to gather more information about this tool as it executes.

After you run procmon.exe we will run fodhelper.exe again and set filters with a search for “REG” which procmon uses to mark registry operations as we are only interested in how this application interacts with the registry keys that can be modified by the current user.

Now that we got the result, we need to narrow our focus more to check if the fodhelper.exe is attempting to access registry entries that do not exist. If this is the case and the permissions of these registry keys allow it, we may be able to tamper with those entries and potentially interfere with actions the targeted high-integrity process is attempting to perform. Since we need to focus on a registry that we can control, we will narrow our search to only the HKCU hive, to which the current user has read-write access.

According to this output, we see something rather interesting. the fodhelper.exe attempts to query HKCU:\Software\Classes\ms-settings\shell\open\command registry key, which does not exist.

Process Monitor (Procmon) output showing fodhelper registry access

To better understand why this is happening and what exactly this registry key is used for, we’ll modify our search and look specifically for any access to entries that contain ms-settings\shell\open\command. If the process can successfully access that key in some other hive, the results will provide us with more clues.

The output contains an interesting result. when fodhelper does not find the ms-settings\shell\open\command registry in the HKCU, it immediately tries to access the same key in the HKCR hive, and since that entry does exist, the access is successful.

Fodhelper is opening a section of the windows settings application through the ms-settings application protocol. An application protocol on windows defines the executable to launch when a particular URL is used by a program. These URL Application mappings can be defined through registry entries similar to the ms-setting key we found in HKCR. In this case, the application protocol schema for ms-settings passes the execution to a COM object rather than a program. This can be done by setting the DelegateExecute key value to a specific COM class ID as detailed in the MSDN documentation

This is interesting because fodhelper tries to access the ms-setting registry key within the HKCU first. Previous results from procmon clearly showed that this key does not exist in HKCU, but we should have the necessary permissions to create it. This could allow us to hijack the execution through a properly formatted protocol handler. Let’s try to add this key with the REG utility:

   REG ADD HKCU\Software\Classes\ms-settings\Shell\Open\command

We run procmon again, but this time the result is different. fodhelper.exe attempts to query a value (DelegateExecute) stored in our newly created command key. This did not happen before we created our fake application protocol key. However, since we do not want to hijack the execution through a COM Object, we’ll add a DelegateExecute entry, leaving its value empty. We hope that when fodhelper discovers this empty value it will follow the MSDN specifications for application protocols and will look for a program to launch specified in the Shell\Open\command\Default key entry.

We will use REG ADD with /v argument to specify the value name and /t to specify the type:

   REG ADD HKCU\Software\Classes\ms-settings\Shell\Open\command /v DelegateExecute /t REG_SZ

To verify that fodhelper successfully accesses the DelegateExecute entry we have just added, we will search for “SUCCESS” to show only successful operations and restart the process again, and as expected, fodhelper finds the new DelegateExecute entry we added, but since it value is empty, it also looks for the Default entry value of the Shell\open\command registry key. The Default entry value is created as null automatically when adding any registry key. We will follow the application protocol specifications and replace the empty default value with an executable of our choice, cmd.exe this should force fodhelper to handle the ms-settings protocol with our own executable

   REG ADD HKCU\Software\Classes\ms-settings\Shell\Open\command /d "cmd.exe" /f

Registry keys used for FodHelper UAC bypass

After setting the value and running fodhelper.exe once again, we are presented with a command shell. Run whoami /groups and you should see that this is a high-integrity command shell. The next and last step would be to change the admin password to see if we can successfully bypass UAC:

   net user admin EvilPassword

The password change is successful and we have successfully bypassed UAC!

Automated Script

A PowerShell script that automates this process and opens a high-privilege shell, tested on Windows 11:

GitHub: nadimjsaliby/fodhelper-bypass