Why Defendnot is a Wake-up Call? A Ground Level Analysis – EMS Route

TL;DR

If you are in the Security world, I believe you have heard all about Defendnot and how lethal it can be. The TL;DR is, Defendnot is a research project (by es3n1n), which is a tool that silently disables Defender AV when a 3rd party AV is not installed in the endpoint. When it’s successfully executed, it will register as an AV by tricking the Windows Security Center API (WSC API)and injecting its DLL into Taskmgr.exe and making it a true AV running on the endpoint. This leads the OS to believe there is another AV (primary) running in the endpoint and will disable AV protection in Defender. This is a huge weakness as this shows how a similar or even smarter tool (an actual malware, maybe) can disable endpoint protection and leaving it vulnerable.

Since this is critical regardless of the size of the business because disabling the AV can lead to critical incidents, I want to write how you can proactively set some controls to mitigate this, then and there. yes I was curious to know what this is and how a similar type of incident be notified and stopped.

---

---

Read more

🔗 https://www.blackhatethicalhacking.com/news/new-defendnot-tool-silently-disables-microsoft-defender-using-fake-av-registration/

🔗 https://blog.es3n1n.eu/posts/how-i-ruined-my-vacation/

Bit of a Postmortem

Similar type of an attack is possible as advisories are creative in exploiting vulnerabilities. As the topic says, this is a wake-up call to the Security teams to be proactive if you are managing Defender as the primary AV in your fleet.

Defender AV will look like this

It has the option to pass a custom AV name so it will look legit.

Event Logs

Furthermore, when Defendnot registered itself and Defender moves to the primary AV, there are some logs being generated.

Logs: Microsoft-Windows-Windows Defender/Operational
Source: WindowsDefender
Event ID: 5007

Hex Value	Meaning
0x0	Passive mode or disabled
0x1	Active (real-time protection)
0x2	EDR Block mode (for E5 with Defender for Endpoint)

This shows the Defender has moved from being Active AV to Passive or Disabled mode.

Logs: Microsoft-Windows-Windows Defender/Operational
Source: WindowsDefender
Event ID: 5001

Logs: Windows Logs/Application
Source: SecurityCenter
Event ID: 15

Subsequently, Defendnot’s state will go to ON. But it can be presented with any name. So It’s ideal to check from the Defender state.

Registry Changes

You will see some changes in the Registry as well

Location: HKLM\SOFTWARE\Microsoft\Security Center\Provider\Av

A new Key has been created. This is the proper way of adding the AV info to the registry, and Defendnot acts the same way.

But unfortunately, I can’t track this in Advanced Hunting as it didn’t give any results.

However, running below gave me the changes in Defender AV. This was a good way to find out the same things we saw from the device level.

DeviceRegistryEvents
| where Timestamp > ago(2hr)
| where RegistryKey has @"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender"
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, RegistryValueData, PreviousRegistryValueName, PreviousRegistryValueData

• “0” = Defender AV is active,
• “1” = Defender AV is passive,
• “4” = Defender AV is in “EDR Block Mode”

And of course, the Protection has gone to EDR in Block mode.

If this was reported, you can run the below KQL to find out more on the same.

Since this is a Potential Windows DLL process injection, we need to find out events for those for the whole fleet as well.

AlertEvidence
| where EntityType == "Process" and Title == "Potential Windows DLL process injection"
| project Timestamp, AlertId, Title, ProcessCommandLine, FileName, FolderPath, AttackTechniques

It would be wonderful if an alert can be generated or a detection rule could be created when the Event ID 5007 hits in the endpoint, without having to install Azure Monitor agent and send the Event details to Sentinel for further action.

Actions, Being Proactive

Currently Defender is detecting the file as a malware and blocks then and there, but as I mentioned before the bad actors are always one step ahead.

• EDR in Block Mode MUST be enabled even if Defender is not the primary AV, and in a situation like this, it will still Observe files and send alerts.
• Keeping the AV up to date is important!
• Setup your detection rules using KQL to capture attack techniques like Process Injection, Process Hollowing, Dynamic-link library injection and Portable Execution Injection.
• Device isolation can save this from spreading!
• Be mindful of Suspicious scheduled tasks
• Set up alert notifications for Potential Windows DLL process injection
• Consider Azure Monitor Agent to be installed on client devices > send the Event-specific logs to Sentinel for playbook activations or simply to isolate the device.

An Intune Remediation Script?

Since we need this to be identified sooner rather than later, if the device is enrolled in Intune, we can use a Remediation script to detect and report the event logs. My goal is to detect the Application Event ID 15 and notify it via Microsoft Teams.

I’m using a Webhook to create the script and my report-back method, wrap it as a PowerShell script, and create the remediation script policy in Intune to run hourly. This will look at the latest event and notify. Surely the script can be modified as you need, so it will not flood your alerts.

👉🏽Check here for the remediation script GitHub repo

It looks like below.

Teams notification from the Webhook

Closing

Ideally, if something like this happens, the above will not revert the situation and put Defender AV back in the Primary Mode and the Real-Time Protetction is no longer available and Defender will not be the Primary AV, and therefore ASR rules, AV policy and other Security policies will not be imposed on the device. However, EDR in Block mode will still work on the backend and send the alerts, but being vigilant, up-to-date security software, and taking proactive measures to make sure you are aware of what’s going on in the endpoint matters.