defendnot, a tool developed by es3n1n, represents a unique method for disabling Windows Defender. Unlike conventional methods that attempt to modify registry settings or use administrative policies, defendnot takes a more sophisticated approach by registering an antivirus product. defendnot achieves its objective by leveraging undocumented Windows Security Center (WSC) APIs to register a fabricated antivirus product. This action inherently forces Windows Defender into a disabled state, significantly lowering the barrier for subsequent malware deployment and execution.
This post is not intended as a re-examination of defendnot's core capability—which es3n1n has written a phenomenal blog on—but rather focuses on the defensive perspective: identifying the critical indicators and techniques for detecting this evasion within an enterprise environment. We’ve included Sigma rules that can be used to detect this tool in various stages of execution.
defendnot emerged as a successor to "no-defender," an earlier project by the same developer, which was eventually removed from GitHub following a DMCA takedown notice. The original iteration reportedly reused code from existing commercial antivirus solutions. In contrast, defendnot was rebuilt from scratch, a testament to direct reverse engineering of Windows Security Center (WSC) Component Object Model (COM) methods.
The Windows Security Center (WSC) service is integral to managing security products on Windows systems. Critically, it incorporates undocumented functions and interfaces, access to which Microsoft typically restricts under Non-Disclosure Agreements (NDAs) to legitimate antivirus vendors.
At its core, defendnot exploits the IWscAvStatus COM interface to register a custom antivirus, a technique which Huntress calls a Malicious Security Product AV bypass. This process predominantly relies on two main methods:
Register: This method initiates the registration of the purported antivirus.
UpdateStatus: This method subsequently activates the fake AV, signaling its operational status to the WSC.
However, the WSC incorporates signature validation checks to ensure the legitimacy of registering processes. An arbitrary process cannot simply invoke these COM methods. es3n1n went to significant lengths to reverse engineer and replicate these WSC signature checks. This work yielded a list of potential binaries that, if injected into, would pass these stringent validation routines. defendnot, as implemented, hardcodes Taskmgr.exe (Windows Task Manager) as its designated kVictimProcess for injection prior to initiating the AV registration sequence.
Figure 3: Taskmgr.exe hardcoded as kVictimProcess
To better contextualize the operation, let's visualize the attack progression. While rudimentary, this diagram illustrates the key stages of defendnot execution:
The above attack flow diagram illustrates a multi-phase execution process designed to disable Windows Defender through fraudulent antivirus registration. Each numbered step in this attack chain
presents unique detection opportunities that security teams can leverage to identify and interrupt the malicious activity before the ultimate goal of defense evasion is achieved.
defender-loader.exe execution
This phase represents the initial execution where the primary loader component begins operation. The loader serves as the orchestrator for the entire attack chain, responsible for parsing configuration parameters and initiating subsequent phases.
Key detection considerations include monitoring for newly created processes, especially those with suspicious names or operating from unusual locations. Process creation events should be correlated with file system activities and network connections to establish baseline behavior patterns.
Sigma Rule: defendnot Execution
The successful execution of the defender-loader.exe component triggers the next phase of the attack, where defendnot begins processing its operational parameters.
YARA Rule for defendnot binaries
Parse Arguments / Create ctx.bin
Following initial execution, the tool immediately transitions into argument processing mode, analyzing command-line parameters to determine its operational configuration. During this phase, defendnot generates a context file (ctx.bin) containing configuration data or encrypted payloads necessary for subsequent injection activities.
This transition from execution to configuration represents a critical detection window, as defendnot must perform file system operations that generate observable telemetry. The creation of ctx.bin serves as a preparatory step for the injection phase, containing target process information and payload data.
Sigma Rule: defendnot File Creation
With the configuration file successfully created, defendnot now possesses all necessary components to begin the process injection sequence.
Inject defendnot.dll into victim process (taskmgr.exe by default)
Armed with its configuration data from the previous phase, defendnot now initiates the core injection sequence. The defendnot.dll component, guided by parameters established during argument parsing, targets the Task Manager process (taskmgr.exe) as its default injection victim, though other processes may be specified through command-line arguments.
This injection represents the transition from a standalone process to operating within the context of a legitimate Windows system component, providing both privilege elevation and evasion capabilities.
Sigma Rule: Taskmgr Child Process of defendnot
Figure 8: Sysmon Event ID 7 - Taskmgr Load event
Once successfully injected into the target process, it has privileges and positioning to manipulate Windows security infrastructure.
Related Sigma rules for these behaviors:
Sigma Rule: defendnot.dll Loaded Via Taskmgr
Sigma Rule: Suspicious Image Loaded into Taskmgr
The below shows the resulting telemetry defendnot exhibited when performing process injection. This classic DLL injection technique shows us that
defendnot-loader must first access the taskmgr process (ProcessAccess - Sysmon EID 10), allocation of virtual memory (not seen in Sysmon but could be picked up via the
Threat-Intelligence ETW provider), performing a
memory write action (again, not seen with Sysmon but could be via
Threat-Intelligence ETW provider), and the
creation/execution of the remote thread (CreateRemoteThread - Sysmon EID 8). A couple of things to keep in mind:
The process injection technique can change (from a classic DLL injection to another process injection technique).
defendnot is using TaskMgr as its target process, but there could be a different target process.
Figure 9: Other possible victim processes identified by es3n1n (screenshot courtesy of es3n1n)
Sigma Rule: MsMpEng.exe Process Access defendnot loader
Figure 11: Sysmon Event ID 10 - Process Access defendnot-loader
Register fake AV (Malicious Security Product) via IWscAvStatus Interface
Operating from within the injected process context, defendnot now leverages its elevated position to interact with WSC API IWscAvStatus to register itself as a legitimate antivirus product, beginning the process of security software manipulation.
This phase represents the transition from covert injection to active system manipulation, as it begins establishing its presence within Windows security infrastructure.
The registration request now awaits processing by the Windows Security Center, setting the stage for acceptance as a legitimate security product.
WSC accepts registration (fake AV Registered)
The Windows Security Center processes the fraudulent registration request and accepts it as a legitimate security product (AV). This acceptance marks a critical transition point where an external threat becomes an accepted component of the system's security posture.
This successful registration provides the privileges and necessary mechanism to proceed with disabling competing security solutions without triggering user suspicion.
Sigma Rule: Modification to Security Center AV Registry Key
With its legitimacy established within the security framework, defendnot can now optionally establish persistence mechanisms before proceeding to its primary objective.
Register AutoRun (Optional)
Having successfully been established as a registered security product, the additional option exists to implement persistence to ensure survival across system reboots. This optional phase involves creating autorun registry entries that will reactivate the malicious security product following system restarts.
Sigma Rule: defendnot Scheduled Task Creation - Security
Whether persistence is established or not, defendnot now proceeds to execute its primary mission: neutralizing Windows Defender.
Windows Defender gets disabled
The attack chain culminates with the successful disabling of Windows Defender, leveraging the established position as a registered security product to justify the deactivation of competing protection mechanisms. This final phase represents the achievement of the primary objective: creating an environment where additional malicious activities can proceed without interference from the system's primary security solution.
The successful completion of this phase demonstrates the effectiveness of the entire attack chain, from initial execution through security framework manipulation.
Sigma Rule: defendnot Windows Defender State Toggle Events
With Windows Defender neutralized, the environment is now prepared for follow-on malicious activities, having successfully circumvented the system's primary defensive mechanisms through a sophisticated multi-stage evasion technique.
When considering how to approach detecting any threat, it is important to consider data sources and layers of abstraction, as well as Pyramid of Pain levels, to optimize the methods
for detection. The Summiting the Pyramid framework from MITRE gives further context to detection approaches by looking at detection robustness strategies. The basic
Summiting Levels are:
Level 5: Core to Sub-Technique or Technique
Level 4: Core to Some Implementations of (Sub-)Technique
Level 3: Core to Pre-Existing Tools or Inside Boundary
Level 2: Core to Adversary-Brought Tool or Outside Boundary
Level 1: Ephemeral Values
Robustness & Summiting the Pyramid
Robustness in detection means how resistant a detection is to evasion or trivial changes by an attacker:
Lower Pyramid layers (Hashes, IPs/Domains) are fragile—easy to bypass by recompiling, renaming, or changing infrastructure.
Upper Pyramid layers (Behaviors/TTPs) are robust—hard to change without fundamentally altering the attacker’s workflow or objectives.
Summiting the Pyramid means striving for behavioral/TTP-based detection, which is more robust to attacker changes.
The idea is that the most effective and robust
detections use methods as close to the core of the technique as possible. Rather than focusing on ephemeral values or IOCs like file hashes, use Windows API calls specific to the
technique used by the malware or tool instead. This isn’t always possible, and can be noisy at times. The best method is often to combine detection methods at each level: to be
precise and high fidelity with lower level detections while using more broad higher levels of detection on top of that to cover for evasion techniques of the lower level
detections.
For example, let’s look at some possible methods at various levels to detect the defendnot tool and its technique and compare their effectiveness and robustness.
| Pyramid Layer | Example in defendnot | Detection Source | Robustness Term | Evasion Difficulty |
|---|---|---|---|---|
| Hash | SHA256 of defendnot.dll | File scan, AV, YARA | Weakly related | Trivial |
| Artifact | Scheduled Task, Registry Run | Event Logs, Sysmon, Registry Monitor | Generally related | Moderate |
| Tool | defendnot process/DLL name, usage | EDR, process listing, SIEM correlation | Closely tied to technique | Harder |
| Behavior (TTP) | WSC COM abuse, process injection | Sysmon events, EDR, SIEM, Analytics | Core to the technique | Very Hard |
So, for example, the file hash of the tool is weakly related to the core technique, not very robust, and trivial to evade. While it can be a good and easy way to detect default
use of the tool (so why not use it?), it should not be relied upon to ensure the best defense against other use of the tool. Using process injection detection methods or even
detecting the actual WSC COM abuse occurring is more robust and much harder to evade detection because it is the core technique used by the tool and cannot be changed without
changing the way the tool works (in which case it would be something entirely different with new detection methods needed anyway).
Now let’s look at some of the specific sources that can be used to detect the various characteristics, artifacts left behind, and techniques used by the tool.
| Level | Robustness Layer & defendnot Specifics | OS Abstraction/Source | Adversary Evasion Cost | Data Telemetry Types | Possible Detection Methods & Abstraction | Specific Logs for Detection |
|---|---|---|---|---|---|---|
| 5 | Core Technique: Disabling AV, how it's done. | Kernel/User Mode (System-wide) | Very High (Requires new strategy) | OS event logs, AV health status, process behavior, system calls | High Abstraction: Detects the intent of disabling security products regardless of method. Focuses on the "what" and "why." |
Windows Event Log: System Log (Event ID 7036 for service state changes), Security Log (Event IDs 4697, 4700 for service installation/enabling). Sysmon: Event ID 1 (Process creation related to service control). |
| 4 | Specific Implementation: Undocumented WSC API calls. | Kernel/User Mode (API Monitoring) | High (Requires deep code change) | API call logs, memory forensics, DLL injection logs | Medium-High Abstraction: Detects how the AV is disabled via specific, less common system interactions. |
Sysmon: Event ID 7 (Image Loaded into trusted processes), Event ID 8 (CreateRemoteThread), Event ID 10 (ProcessAccess). Process Data: Unexpected modules in legitimate processes (e.g., Taskmgr.exe).
|
| 3 | Abused Legitimate Tools: Taskmgr.exe abused. | User Mode (Process/Registry) | Moderate (Can change abused tool) | Process activity logs, registry events, file system events | Medium Abstraction: Detects abuse of legitimate tools (e.g., Taskmgr.exe performing unusual actions). |
Windows Event Log: Event ID 4688. Sysmon: Event ID 1, 12, 13, 14. |
| 2 | Adversary Tool: The defendnot binary itself. | User Mode (File/Process) | Low (Easy to recompile/modify) | File creation, process execution, network connections | Low-Medium Abstraction: Detects presence of the defendnot executable or communications. |
Windows Event Log: Event ID 4688. Sysmon: Event ID 1, 3. |
| 1 | Ephemeral Values: Hash of defendnot binary, download IP. | User Mode (File/Network) | Trivial (Just change a value) | File hashes, network connection logs | Low Abstraction: Detects specific, easily changeable indicators. |
Windows Event Log: Event ID 4688. Sysmon: Event ID 1, 3. |
Core to the technique (Behavior/TTPs): Detecting WSC abuse (e.g., unauthorized COM registration activity) or process injection is extremely robust—attackers would need to fundamentally change their approach to evade.
Closely tied to the technique (Tool): Monitoring for defendnot’s known process or DLL names, or seeing Taskmgr.exe as an injection target is robust but still vulnerable to renaming.
Generally related (Artifacts): Autorun tasks, registry keys, and other artifacts are useful, but can be swapped or cleaned up by attackers.
defendnot represents a sophisticated approach to bypassing Windows Defender by taking advantage of legitimate mechanisms (creating a Malicious Security Product) rather than attempting to break them directly. It demonstrates how undocumented APIs intended for use by legitimate security vendors can be reverse-engineered and exploited.
The techniques used by defendnot—particularly the process injection into trusted Windows processes and interaction with undocumented APIs—highlight the need for defense-in-depth strategies that focus on behavioral monitoring rather than simple file-based detections.
For defenders, this tool serves as a reminder of the importance of monitoring system behavior and security product status, as well as the need to continuously evolve detection capabilities to address emerging evasion techniques.
Thanks to Jonathan Johnson (@jsecurity101) for his help in reviewing this blog post.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
