In this post we will look at the basic principals involved in UAC (User Account Control) bypass attacks. I will not go into to much detail on what Microsoft says UAC is or is not except here in the introduction.
UAC, introduced with Windows Vista, enables Admin users to operate their Windows machine with standard user rights as opposed to Administrative rights.
A direct benefit of UAC is that it protects Admin users from, or alerts them to, malicious, elevated, actions performed by software components. Administrators normally run with least user privileges, but they can self-elevate to perform administrative tasks by giving explicit consent with the Consent UI.
In their least-privileged state, administrators are referred to as Protected administrators. In their elevated state, they are referred to as Elevated administrators. By contrast, Standard users can’t elevate by themselves, but they can ask an administrator to elevate them using the Credential UI. The Built-in Administrator account doesn’t require elevation.
So, if we open a CMD prompt using an admin account, we are in fact opening CMD terminal as “Protected Administrator” and if we try to execute “mmc.exe” we will get the following prompt:
We can check our current “Protected Administrator” user privileges:
If we open now a CMD with “Run as administrator” command, we can verify that we have much more privileges because the CMD is running as “Elevated Administrator”:
How does Windows differentiate and isolate different processes with different permissions, executed under the same user? For this UAC makes use of Integrity control or MIC (Mandatory Integrity Control).
Each process has an associated integrity level and therefore a system object with a lower integrity level will not be able to access an object with higher integrity level.
Using the Sysinternals tool “Process Explorer” we can see how both CMD processes run with different integrity levels. Medium for the protected administrator and High for elevated administrator.
By default, in Windows there are some programs that run elevated automatically when the user belongs to the group of administrators. This feature was introduced in Windows 7 to improve usability and mitigate criticism against the UAC in its day by launching it in Windows Vista
To find out if a program has the option to auto-elevate, we should look at its Manifest file, see if it has the option “autoElevate” to True.
You can use Microsoft’s “Sigcheck” or “Strings” tools to obtain information on binaries and their Manifest. We can use the following command to check if a binary has “autoElevate” property:
sigcheck.exe -m C:\Windows\System32\Taskmgr.exe | findstr autoElevate
You can use the following command to list all binaries with autoElevate property inside a directory:
strings.exe C:\Windows\System32\*.exe | findstr /i autoelevate
As we can see, there are several Windows binaries with that property. For example, if we launch eventvwr.exe as protected administrators, no UAC prompt will come up and the process will be running with High integrity level.
Another binary with that property is “fodhelper.exe” and is one of the Windows binaries that can be exploited to bypass UAC control. This binary is launched when you click “Manage optional features” from Apps & Features.
If we use Sysinternals tool “Process Monitor” to debug “fodhelper.exe” activity we will see that it reads several registry keys hosted on HKCU. Current user has total permission to create or modify any key on HKCU registry and this is why this binary is exploitable.
The following checks are performed in the registry upon start of fodhelper.exe:
It seems the binary tries to execute some command defined in that registry key. Since these registry entries doesn’t exist the current user can create this structure in the registry in order to manipulate fodhelper to execute a command with higher privileges bypassing the User Account Contol (UAC).
After creating HKCU\Software\Classes\ms-settings\Shell\Open\command entry with “cmd /c mmc.exe” value we see that now binary tries to read “HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute” entry:
Now if we add that “DelegateExecute” registry entry leaving it in blank and try again, we will get now the command executed properly. Finally the registry should look like this:
Now the process reads properly the command and opens the Management console “mmc.exe” without getting the UAC prompt:
Now we can execute elevated commands without UAC being prompted 🙂 We can even automate the process with the following code in Powershell, we only need to replace $program variable with the command that we want to execute bypassing UAC:
#Command to be executed
[String]$program = "cmd /c mmc.exe" #default
#Create registry structure
New-Item "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -Force
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(default)" -Value $program -Force
#Perform the bypass
Start-Process "C:\Windows\System32\fodhelper.exe" -WindowStyle Hidden
#Remove registry structure
Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force
This particular technique can be remediated or fixed by setting the UAC level to “Always Notify” or by removing the current user from the Local Administrators group. Further, if you would like to monitor for this attack, you could utilize methods/signatures to look for and alert on new registry entries. Some examples are:
sdctl.exe – HKCU:\Software\Classes\exefile\shell\runas\command\isolatedCommand
eventvwr.exe – HKCU\Software\Classes\mscfile\shell\open\command
I hope this helps you to protect your infrastructures.
Until the next post.