Bypassing Defender’s self-protect mechanism

I recently started working as a Red Team lead, and figuring out ways to bypass antivirus engines became a regular thing. I am a huge fan of Microsoft Defender, and it gives me a hard time in every operation I run.
I’ve recently reviewed recent research on disabling Defender, and it seems most threat actors will rely on some of the following to disable Defender:

• The Set-MpPreference PowerShell function
• The MSFT_MpPreference WMI class
• Impersonating Trusted Installer
• Redirecting \Device\BootDevice
• A Kernel driver abuse

One could also try to exploit Known DLLs cache poisoning as PPLDump does, inject yourself into Defender’s memory and run your payload from there.

I challenged myself to find an alternative to the available techniques. As you need administrative access to use any of the options I mentioned, I considered having admin-level access fair game. It’s not like I am James Forshaw anyway 🙃. The other condition was that I should only use the command line.

I started my research looking for basic things, like symbolic symbol exploitation vectors, DLL hijack, etc. Defender main processes are Antimalware Protected Process Light (AM-PPL) processes, so it’s not like they can load unsigned DLLs anyway. On top of that, Defender uses a minifilter driver (WdFilter.sys) to prevent any user, including the SYSTEM authority, from writing to Defender’s launcher folder. This is a self-protection standard feature most antivirus engines employ to avoid attacks like DLL hijack.

After a while, I decided to look at the MpCmdRun tool, which is supposed to be one of the official ways to manage Defender from the command line. I took some time to review its standard arguments and even did some quick reversing to look for hidden ones. I was actually able to find some undocumented command arguments that looked promising, like:
-StopService, -DisableService, and -UninstallServices. Nonetheless, as expected, none of them worked even when running the tool as SYSTEM. I never took the time to understand why they did not work, but my guess is that as the calling process is not protected, it can’t terminate the required services. Following my unfruitful attempt, I decided to dig into the MpCmdRun ability to restore files from quarantine. I had some luck exploiting this type of operation to bypass some antivirus features in the past, so I thought it was worth a shot.

The MpCmdRun -Restore argument allows you to restore files from Defender’s quarantine through the command line. To list all files in the quarantine, one can use the “MpCmdRun -Restore -ListAll” command.

MpCmdRun allows you to restore a file based on its threat name and its original file location. Moreover, it permits specifying a destination path to where the file should be restored. What happens then if you send a file to quarantine and ask MpCmdRun to restore the file to Defender’s launch folder? Well, MpCmdRun sends an event handled by MsMpEng.exe, Defender’s antivirus engine process itself! Despite Defender’s mechanism to protect its launcher folder from modification, the file restoration works.

Furthermore, a temporary exception is created to the restored file. This means that a malicious actor with administrative rights can send a malicious file to quarantine, restore it to Defender’s launch folder, and have an undeletable, at least through conventional methods, malware.
But how can one use this to prevent Defender from starting? Simple enough; look for a DLL Defender tries to load from its working directory, create a malicious file with the same name, restore it from quarantine to Defender’s launcher folder, and either reboot the system or use something like Backstab to terminate Defender’s process. One such candidate is the SLC.dll library.

For platform version 4.18.2201.10–0, the latest at the time of this writing, the following commands can be used to prevent Defender from starting.

After a system reboot, several of Defender’s services should fail to start. On top of that, the malicious DLL won’t be removable through traditional means.

I reported this technique to Microsoft on February 15, 2022, but got the usual “Upon investigation, we have determined that this submission does not meet the bar for security servicing” response back. It seems that although Windows has features to prevent even the local SYSTEM authority from performing malicious actions, a bypass of such a feature is not a big deal.