Last Updated on Thu Feb 16, 2023
No more Access Denied - I am TrustedInstaller
A regular day at FourCore:
How would you suppress alerts from an EDR?
An average answer:
- Bypass AMSI
- Event Tracing for Windows
- DLL Unhooking and more
A typical Giga-chad reply: Kill the EDR.
How would one do that? When most organisations use Tamper Protection.
According to Microsoft, Tamper protection essentially locks Microsoft Defender Antivirus to its secure default values and prevents your security settings from being changed through apps and methods such as:
- Configuring settings in Registry Editor on your Windows device
- Changing settings through PowerShell cmdlets on your device
Therefore, disabling the service or modifying the configuration won’t work.
Taking it a step further, how about deleting the Defender executable all together?
We attempt to delete or rename the C:\Program Files\Windows Defender folder. However, we received an "Access Denied" message even when we were logged in as an Administrator. Let’s delve deeper into the nuisance known as TrustedInstaller.
Enter TrustedInstaller
Looking at the Security Properties of the folder, it turns out we don't own the Windows Defender folder on our Computer. Rather TrustedInstaller does.
Introduced in Windows Vista, TrustedInstaller is a built-in service account in the Windows operating system with the highest permissions. It is responsible for managing system files, installing and uninstalling applications, and performing critical system updates. TrustedInstaller ensures that important system files are not tampered with or modified by unauthorized users. This is accomplished by assigning ownership of system files to the TrustedInstaller account, which means that even an administrator cannot make changes to these files without first taking ownership of them.
TrustedInstaller is a Service Account, meaning the service must be running when files owned by it are modified, and only the TrustedInstaller.exe can modify them.
We can explore the token associated with the executable by starting the service manually and looking at it in Process Hacker. Notice that the token user is NT AUTHORITY\SYSTEM, and we have the NT AUTHORITY\TrustedInstaller group associated with it.
If we can create a process using the token from this TrustedInstaller.exe, we might become TrustedInstaller, and then we can delete the Defender Directory.
Standing on the Shoulders of Giants
James Forshaw from Google Project Zero did this in 2017, and you can read his blog on The Art of Becoming TrustedInstaller for more details. In short, you cannot steal a token from the TrustedInstaller process because the token you get only has TOKEN_QUERY access, and we need at least TOKEN_DUPLICATE to create a primary token. Only with a primary token can we create new processes.
If we can't use the stolen token, the other approach is to create a new process with TrustedInstaller.exe as the parent. The parent's child inherits its privileges, and now we have our malicious process with the same privileges as TrustedInstaller.exe. The only requirement is to have SeDebugPrivilege, as this gives you full access to the process, including the right to create child processes.
Deleting Windows Defender
We wrote a small POC which starts TrustedInstaller, opens a handle to it, and creates a new child process. The code spawns a cmd.exe shell with the privileges of TrustedInstaller and the user as NT Authority/System. So there you go, one more method out of countless of becoming System from Administrator, and you are also TrustedInstaller.
This allowed us to remove the Defender Directory without receiving an "Access Denied" message.
This attack and a few variants and simulations are already present on our Platform for the customers to quickly validate your detections and whether you can detect Privilege Escalation attempts in your organizations in a few clicks.
References
