Loughlin Lavery
Overview
Cybersecurity threats are evolving faster than ever—especially with the rise of accessible AI tools. One recent concern is the DefendNot tool, which can quietly disable Microsoft Defender on Windows systems without user awareness. This blog outlines the risks associated with DefendNot and offers practical steps to help you monitor and mitigate its impact.
What is DefendNot?
Released just a few weeks back from time of writing, DefendNot is a new threat that targets Windows systems by turning off Microsoft Defender, leaving devices vulnerable to malware and cyberattacks. Knowing how it works—and how to defend against it—is essential for maintaining a secure environment.
How it works
DefendNot takes advantage of a Windows vulnerability to disable Defender. It uses an undocumented Windows Security Center API (WSC API)—normally used by antivirus software to report protection status—to trick the system. By injecting a malicious DLL into Taskmgr.exe (a trusted Microsoft process), it registers a fake antivirus. This causes Defender to shut down, leaving the system exposed.
One saving grace of the is that the injection of DLL to mimic the registration of a genuine antivirus is that this action requires local admin privileges on the machine in question. So, if you are running a well-managed zero trust environment where end users have no local admin privileges then things should be good.
Why it matters
Once Defender is disabled, attackers can move in undetected. This kind of stealthy behaviour makes DefendNot especially dangerous, as it bypasses standard security alerts and protections.
Unfortunately, with no Defender monitoring you will be entirely dependent on security logs from the endpoints being ingested into a SIEM with pertinent and intelligent endpoint behaviour monitoring rules that can help you monitor for this threat. Often though, these security logs are only used for the enrichment of EDR alerts, as the mindset is why bother with an intelligent ruleset when I have a purpose-built built intelligent monitoring agent.
As part of the payload, DefendNot will also introduce a Windows scheduled task to ensure it auto restarts with the boot of the machine in the case of a power cycle. This can make a seamless interaction with your endpoint where if it is affected by DefendNot, you might not become aware till it is too late!
What you can do
- Establish a baseline: Know which machines should be running Defender and monitor for any that deviate.
- Restrict local admin rights: Prevent unauthorized DLL injections by limiting admin access.
- Use Defender XDR: Actively monitor Defender enrolment and status through the XDR portal.
Monitoring and detection
Monitoring and detection are the best form of defence for this threat. The Defender 365/ Defender XDR Portal has some inbuilt functionality to assist you in monitoring for this threat. In the report section of the portal, you will find a Defender antivirus health tab to help you track which devices are not in an AV active mode.
Information on how the modes work can be found at the below link:
Establishing what a healthy baseline looks like is essential as a first step, this will allow you to be able track any deviations from this baseline for further investigations.
Then running regular Defender XDR reports to identify machines where Defender is in an inactive state.
Microsoft has released threat intelligence signatures for this threat — if detected by Defender, the threat will appear as Win32/Sabsik.FL.!ml and be quarantined automatically. Of course, Defender's ability to identify the threat will be entirely dependent on the local Defender signatures being up to date on the machine.
Updating these signatures should be a priority of yours regardless of this threat.
Broader implications
This threat is a direct result of Microsoft auto disabling to Defender to accommodate the installation of third-party vendors.
The rise of this threat has highlighted an unsettling trend that Microsoft’s business strategy has been easing us towards for several years now. In an effort to make their operating systems and software more accessible and compatible to third parties, they are opening the door to new security threats such as DefendNot.
While this accommodation of third parties has improved their attractiveness to the wider market and assisted their market monopoly, is it beneficial for the security of the product range as whole?
Final thoughts
While local admin is needed for the injection of the DLL, monitoring is always a good strategy and there is never a bad time to check that your machines are configured to receive regular Defender signature updates.
For the next month, consider increasing your monitoring efforts. Investigate any systems where Defender has failed and take action to restore protection. Keeping Defender signatures up to date across all devices is one of the simplest and most effective defences.
As a leading managed IT services company, we empower organisations to thrive in the digital landscape by providing tailored, reliable, and secure connectivity.
