When the security software becomes the shortest path to system compromise, something fundamental is broken. In 2026, we watched this happen twice within the Microsoft ecosystem: zero-days in Defender that hand over SYSTEM privileges, and malware signed by Microsoft's own code signing infrastructure. The lesson is clear — blindly trusting the protector is the real vulnerability.
The antivirus that hands over the keys
Microsoft Defender runs as NT AUTHORITY\SYSTEM. This is not a minor technical detail — it is the reason Defender is the most valuable target on Windows. Whoever compromises Defender does not need a kernel exploit. Defender already has maximum privileges. You just need to make it work for you.
CVE-2026-41091, dubbed RedSun, exploits exactly this. The Malware Protection Engine (mpengine.dll) resolves symlinks before validating the path. An attacker with any local account — even the most restricted one — creates a symlink pointing to a privileged file. Defender follows the link with its SYSTEM privileges and accesses the target. Result: any minimal user becomes NT AUTHORITY\SYSTEM. CVSS 7.8, CWE-59, no user interaction required.
Researcher Nightmare Eclipse published the PoCs on GitHub in April 2026. MSRC had already patched BlueHammer (CVE-2026-33825) in the April Patch Tuesday. But RedSun and UnDefend went 6 weeks without a patch, with active exploitation documented. Six weeks of public zero-day, active in the wild, no fix. No organization should accept that window.
The alarm that disarms silently
The second vulnerability is subtler and, in certain scenarios, more dangerous. CVE-2026-45498, called UnDefend, crashes the MsMpEng.exe service when it processes a crafted file in any writable directory. Defender stops. No alert. No notification. No warning icon in the system tray.
The dashboard shows "updating" or "last scan: X hours ago." Looks normal. It is not. The CVSS 4.0 score is misleading — classifying an attack that disables the antivirus as DoS is like calling the phone line cut before a heist "minor breaking and entering." DoS against antivirus is disarming the alarm before the real attack.
Huntress documented the intrusion in April: the attacker entered through a compromised FortiGate VPN, ran basic reconnaissance (whoami /priv, cmdkey /list, net group), then chained UnDefend and RedSun. First, Defender crashes silently. Then, escalation to SYSTEM. Endpoint blinded and compromised. Zero detection. From the Downloads folder to SYSTEM in seconds, without the admin ever knowing.
When the signature becomes the attack vector
If the zero-days show that Defender can be broken, Fox Tempest shows it can be bypassed by design. Microsoft runs a service called Artifact Signing that issues code signing certificates so Windows trusts software. A criminal group built a malware signing service using that same infrastructure.
The site signspace[.]cloud was the storefront. Criminal clients uploaded binaries. The system signed them with certificates issued by Microsoft Artifact Signing. Certificates lasted 72 hours — short enough to limit detection, long enough to bypass SmartScreen, Defender, and allow-lists that trust signed binaries. Windows saw the Microsoft seal and treated the malware as legitimate software.
The infrastructure behind it: 580+ fraudulent accounts using stolen identities from the US and Canada, hundreds of Azure tenants issuing independent certificates. By February 2026, pre-configured VMs on Cloudzy automated the process: upload malware, receive signed binary. Price: $7,500 in bitcoin. Alias: SamCodeSign on Telegram. Over 1,000 fraudulent certificates issued between May 2025 and May 2026.
Ransomware with a seal of trust
The primary Fox Tempest client was Vanilla Tempest (Rhysida). The attack flow is revealing: a Google ad redirects searches for "Microsoft Teams," the victim downloads MSTeamsSetup.exe signed with a Microsoft certificate, SmartScreen does not alert, Windows trusts it, and the Oyster backdoor installs Rhysida ransomware. Same path with fake AnyDesk, PuTTY, and Webex installers.
Other clients included Storm-0501, Storm-2561, and Storm-0249. Malware distributed: Lumma, Vidar, INC, Qilin, Akira, BlackByte. Sectors hit: healthcare, education, government, and financial services. The Windows trust chain was weaponized — the seal meant to protect became the mechanism enabling execution.
Microsoft DCU acted in May 2026: seizure of signspace[.]cloud, hundreds of VMs taken down, over 1,000 certificates revoked, lawsuit filed in the Southern District of New York. DCU made test purchases of $7,500 in bitcoin to document the operation. But the 72-hour certificates had already done their job. Thousands of machines infected, including 12+ of Microsoft's own.
The threat model nobody revised
The pattern across these incidents is the same: Windows security infrastructure was designed with a threat model that assumes the Microsoft ecosystem is trustworthy by definition. Defender runs as SYSTEM because it needs full access. SmartScreen approves Microsoft-signed binaries. Allow-lists treat signatures as proof of safety.
But code signing attests identity, not safety. When identity verification can be defrauded at scale — as Fox Tempest proved — the signature becomes an attack vector. And when the software meant to detect threats is itself the path to privilege escalation — as RedSun proved — the security architecture needs independent layers.
At Tech86, our position is straightforward: layered security is not a luxury, it is a requirement. An independent EDR with its own telemetry does not depend on the same engine as Defender. When Defender is blind — whether from a crash, a zero-day, or a fraudulent signature — EDR keeps detecting. Monitor Event IDs 2001/2002/2003 for update failures and 4672 for privilege escalation. Verify Engine is at 1.1.26040.8+ and Platform at 4.18.26040.7+. And never treat a signed binary as safe by default.
Security cannot depend on a single provider — especially when that provider is simultaneously the most attacked target and the source of trust that attackers have learned to exploit.