Detecting Malicious Security Product Bypass Techniques

Figure 11: Sysmon Event ID 10 – Process Access defendnot-loader

AV evasion registration

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.

AV registration acceptance

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.

Figure 13: Sysmon Event ID 13 – Registry Key set

Figure 14: Sysmon Event ID 13 –  Additional registry key set

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.

Persistence (Optional)

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.

Figure 15: Scheduled Task Creation

Sigma Rule: defendnot Scheduled Task Creation – Security

Figure 16: Scheduled Task Updated

Whether persistence is established or not, defendnot now proceeds to execute its primary mission: neutralizing Windows Defender.

Defense evasion outcome

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.

Figure 17: Windows Event ID 15 – Defender State Off

Figure 18: Windows Event ID 15 – Defender State On

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.

Figure 19: GUI Settings for Defender have been altered

Figure 20: Fake AV has been successfully registered

Detection layers

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.

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

Levels of robustness applied to defendnot

Figure 21: Levels of Robustness applied to defendnot

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.

defendnot detection methods and sources with host-based event robustness levels applied

Key takeaways for building detections on defendnot

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

Conclusion

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.

References: