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 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.
(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.
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.
Fodhelper is obviously meant to be a trusted service in the Microsoft umbrella. It, like so many other Windows functions, like named pipes, have good intentions and are vital to functionality, but those layers upon layers of functions increase the attack surface exponentially. Penetration testers like myself exist to identify holes in the dam like this. We know many of these issues aren’t going to be fixed outright by Microsoft or other vendors, which leaves us to oftentimes provide our best judgement and advice on issues.
If you’re like me, use this exploit when you find an organization isn’t utilizing full UAC protections, and allowing trusted Windows processes to bypass confirmation. If you’re on the defensive security side of the house, require your users to use full UAC protections, inconveniently clicking that yes or no button on the prompt, and teach them what that prompt actually means.
Our testers check for these types of privilege escalation techniques on every penetration test, and will provide feedback on how to remediate if found. For more information Contact Us.