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.
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.
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.