Every now and again, I see a crazy tweet that feels like it just can’t be true. Many of them are not true or are folks making overblown statements about something cool they found—this is part of the research game, and folks are entitled to be excited about what they are learning. Recently, however, I saw something that I thought needed more attention. There was a tweet by @0gtweet claiming that one could suspend Windows Defender and then straight up run Mimikatz. This kicked off a fun little research effort that I’d like to share.

Does suspending Defender work?

Simply put: yes, you can suspend Defender but not without issue. When Defender is disabled, the entire system will grind to a halt. Explorer will start to freeze up, and the act of starting a new process will hang for minutes, if it works at all. Without diving into a bunch of disassembly, one can assume that any action that would trigger a request for scanning/analysis by Defender is what’s blocking and waiting for a result that won’t come. 

That said, results speak for themselves.

Two (2) beacon object files (BOFs) were used to avoid steps that would normally freeze Windows. The first was TrustedSec’s own suspendresume from our public CS-Remote-Ops-BOF repository. The second was the excellent NanoDump by Fortra. Using these BOFs, one can initiate a minidump of lsass.exe in a short enough period that a standard user may just assume their computer glitched. Some other ways of accomplishing this same goal, such as using an EXE on disk, were much more unreliable and took long enough that a user would likely force reboot or call support. 

Why does this work?

For anyone unfamiliar with process protections on Windows, it’s worth knowing that Defender runs using a technology called Protected Process Light (PPL). This can be observed using a tool such as Process Explorer.

PPL is intended to limit what a non-protected process can do to a protected process. Microsoft kindly documents what is and is not allowed. This means that a normal process can request and potentially be granted the following access rights to a PPL process:

• PROCESS_QUERY_LIMITED_INFORMATION
• PROCESS_SUSPEND_RESUME
• PROCESS_TERMINATE
• SYNCHRONIZE

But wait—PROCESS_TERMINATE is in that list, and I can’t just kill Defender, so what gives? Most AV/EDR products are split into two (2) or more components. A kernel component can use kernel callbacks to examine new/duplicated handles, file writes, etc., and a userland component may be responsible for sending logs, responding to userland hooks, or interacting with the user. 

When a handle to an object is created, the driver component can examine it using a kernel callback. A driver implementing this callback has the opportunity to examine what userland processes are requesting access to and perform further filtering than what is done by Windows itself. It is this additional filtering that denies a request to kill Defender. This appears to be an oversight and is the reason I would like to draw more attention to it. I’m not aware of a reason to grant suspend/resume privileges to an arbitrary process in relation to a PPL process. Those implementing AV/EDR drivers could additionally filter suspend/resume permissions and reject them, as they already do with terminate permissions.

In researching the limited set of AV/EDR products that I have access to, I can state that Defender is not the only AV/EDR solution vulnerable to this temporary blinding. However, I’ll leave generating a full list to others.

Where else can I use this?

This problem has further reach than it might seem at first glance. Additional testing revealed that numerous processes are vulnerable to this type of suspension. Sometimes this leads to system instability, and other times it does not. Sysmon can be suspended in this way, and even if it has rules to report on process suspensions, that reporting will not occur until after the process is resumed. What other logging or log forwarding applications might be vulnerable to being suspended? Overall, this seems like an overlooked idea, and I’d encourage developers of security products to take a second look to make sure their products can’t be arbitrarily suspended.

Closing

This technique has likely been found prior to the referenced tweet. With that said, it seems highly effective and is difficult to mitigate without vendors closing gaps in their own products. The primary purpose of this post is to raise awareness of said security gap and encourage vendors to examine if they truly intended to allow suspension of their products.

As a general user, you can attempt to use a tool like Sysmon to catch usage of this technique. Example rules to detect this are here. Those rules may need to be expanded to account for other access combinations. Remember that if an attacker is aware of this technique, they could also simply suspend Sysmon first. This means a multilayered defense-in-depth strategy is required such that suspension of a single tool does not cause a system-wide blind spot.

References:

1. https://twitter.com/0gtweet/status/1638069413717975046
2. https://twitter.com/0gtweet
3. Process Explorer - Sysinternals | Microsoft Learn
4. https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights
5. https://github.com/trustedsec/CS-Remote-OPs-BOF
6. https://github.com/fortra/nanodump
7. https://github.com/olafhartong/sysmon-modular/blob/master/10_process_access/include_process_suspend_resume.xml