BlueHammer, RedSun, UnDefend: Three Windows Defender Zero-Days and How to Protect Your Endpoints

Between April 3 and April 16, 2026, a single security researcher published three separate zero-day exploits targeting Microsoft Defender. Not three variations of the same bug. Three distinct attack paths, each abusing different internal mechanisms in Microsoft's built-in endpoint protection, each granting SYSTEM-level access from an unprivileged user account on fully patched Windows 10, Windows 11, and Windows Server systems.

The first, BlueHammer, exploits a race condition in Defender's file remediation logic to overwrite arbitrary system files. The second, RedSun, targets Defender's cloud file rollback mechanism to achieve the same privilege escalation through a completely different code path. The third, UnDefend, does not escalate privileges at all. Instead, it lets a standard user silently disable Defender's signature update pipeline or, in some configurations, turn the antivirus off entirely.

Huntress confirmed active exploitation of all three starting April 16. Microsoft patched BlueHammer (CVE-2026-33825) in the April Patch Tuesday release on April 14, but RedSun and UnDefend remain unpatched as of this writing. If your organization runs Windows endpoints with Defender as the primary antivirus, you need to act now.

How BlueHammer Works

BlueHammer is a textbook time-of-check to time-of-use (TOCTOU) race condition, but the implementation is far from textbook. The exploit chains together four legitimate Windows features that individually work as designed. The vulnerability only materializes when they interact in a specific sequence.

The attack begins by placing a file that triggers a Defender detection, typically an EICAR test string. When Defender's real-time protection engine detects this file and begins its remediation workflow, it creates a Volume Shadow Copy snapshot as part of the cleanup process. This is normal Defender behavior. The snapshot is temporary and is supposed to be destroyed after remediation completes.

The exploit uses a batch opportunistic lock (oplock) to pause Defender's file operation at the exact moment the snapshot exists but before Defender has finished its work. During this pause, the exploit registers the working directory as a Cloud Files sync root using the Windows Cloud Files API and drops a placeholder file. When Defender enumerates the directory and touches this placeholder, a callback fires. The callback checks whether the calling process is the WinDefend service. If it is, the exploit acquires a second oplock on the same file, creating a deadlock that freezes Defender indefinitely.

With Defender stalled, the Volume Shadow Copy remains mounted and accessible. The exploit opens the SAM, SYSTEM, and SECURITY registry hives directly from the shadow copy path. These files are normally locked at runtime and inaccessible to any process, but the shadow copy makes them readable. From the SAM and SYSTEM hives, the attacker extracts NTLM password hashes, takes over a local administrator account, and spawns a SYSTEM-level shell.

Vulnerability analyst Will Dormann confirmed the exploit works end-to-end. Cyderes published a detailed breakdown confirming they resolved reliability issues in the original proof-of-concept and achieved full exploitation. No kernel bug, no memory corruption, no code execution inside Defender itself. Just a timing window that should not exist.

RedSun: The Second Escalation Path

RedSun targets a completely different Defender subsystem. When Defender detects a file tagged with a specific cloud attribute, it attempts to restore the original file to its previous location as a rollback mechanism. The problem is that Defender does not validate the target path during this rollback operation.

The exploit creates a crafted file that triggers a detection, then replaces it with a cloud placeholder using the Windows Cloud Files API. As Defender initiates the rollback, the attacker uses NTFS junction points and opportunistic locks to redirect the target path from the working directory to C:\Windows\System32. Defender follows the junction and writes the file with SYSTEM-level privileges, overwriting a system binary. The overwritten service binary executes on the next restart or service trigger, granting SYSTEM access.

RedSun is functionally equivalent to BlueHammer in outcome but exploits different internal logic. This matters because patching one does not fix the other. The April 14 patch addressed CVE-2026-33825 (BlueHammer). RedSun uses a separate code path that remains unpatched.

UnDefend: Killing the Antivirus From User Space

The third exploit, UnDefend, does not grant privilege escalation. Instead, it allows a standard user account to block Microsoft Defender from receiving signature updates. If a major Defender engine update is pending, UnDefend can exploit the update flow to disable Defender entirely.

From a defensive standpoint, this is arguably more dangerous than the privilege escalation exploits. An attacker who already has a foothold on a system can silently degrade the primary endpoint protection without needing administrative rights. Signature updates stop arriving. Detection rules go stale. The attacker's tools, which Defender would normally flag, stop being detected. And because Defender's UI may still show a healthy status, neither the user nor the security team realizes the protection is degraded.

UnDefend is unpatched. Microsoft has not assigned a CVE to it as of April 18.

What the Huntress Observations Tell Us

Huntress observed exploitation of all three tools in the wild on April 16. The attacker's methodology provides a template for what we should expect going forward:

1. The exploit files were dropped into the user's Pictures and Downloads folders, common staging locations that are unlikely to be monitored by basic file integrity rules.
2. Files were renamed to avoid suspicion.
3. Before running the exploits, the attacker executed reconnaissance commands to map user privileges, discover stored credentials, and enumerate the Active Directory structure.
4. The exploit was one step in a larger post-compromise chain, not the initial access vector.

This matches the pattern we see in every engagement. Privilege escalation exploits are not the beginning of an attack. They are the pivot point. The attacker already has a foothold through phishing, a compromised VPN credential, or an exposed RDP service. BlueHammer and RedSun turn that initial access into full domain compromise.

Immediate Hardening Steps

The April 14 patch addresses BlueHammer (CVE-2026-33825). Confirm your Defender platform version is 4.18.26040.9 or later. This can be verified with PowerShell:

Get-MpComputerStatus | Select-Object AMProductVersion, AntivirusSignatureVersion, AntivirusSignatureLastUpdated

For RedSun and UnDefend, which remain unpatched, apply the following mitigations:

Monitor for anomalous Defender behavior. Watch for MsMpEng.exe performing unexpected writes to C:\Windows\System32 immediately after a malware detection. This is the behavioral signature of both BlueHammer and RedSun. Your EDR should flag any Defender process writing to protected system directories outside of its normal update flow.

Alert on Cloud Files sync root registration by untrusted processes. Calls to CfRegisterSyncRoot from processes other than known cloud sync software (OneDrive, Dropbox, Box) are a direct indicator of BlueHammer-style exploitation. This API is central to the timing trap and is not commonly called by general-purpose applications.

# Osquery hunt for suspicious NTFS junction points
SELECT * FROM file
WHERE type = 'junction'
AND (path LIKE 'C:\ProgramData\Microsoft\Windows Defender\%'
  OR path LIKE 'C:\Users\%\AppData\Local\Temp\%')
AND target_path LIKE 'C:\Windows\System32\%';

Monitor for VSS enumeration from non-system processes. Any user-space process querying HarddiskVolumeShadowCopy* objects outside of backup tooling should trigger an alert. This behavior has no legitimate use case in standard user workflows.

Watch for service creation from low-privileged accounts. BlueHammer uses CreateService to register a temporary malicious service as the final escalation step. Any non-administrative user process calling service creation APIs should be investigated immediately.

Enforce least privilege aggressively. Both BlueHammer and RedSun require local access. Limiting user permissions on endpoints, particularly restricting interactions with Cloud Files APIs and VSS interfaces, reduces the available attack surface.

Deploy layered endpoint protection. If Defender is your only endpoint security product, UnDefend represents a single point of failure. Consider deploying a secondary detection layer that operates independently of Defender's signature pipeline. This could be an EDR agent, a HIPS solution, or application whitelisting.

Why This Matters Beyond the Patch

The BlueHammer, RedSun, and UnDefend trilogy is not a story about three CVEs. It is a story about architectural assumptions. Microsoft Defender runs as a SYSTEM-level service and performs privileged file operations during remediation. That design is foundational. The exploit chains do not attack Defender's detection logic. They attack its response logic, the operations that run after Defender has already done its job and identified a threat.

For organizations that rely on Defender as their primary (or sole) endpoint protection, this is a wake-up call. The antivirus is simultaneously a detection tool and a privileged attack surface. When an attacker can coerce the antivirus into performing arbitrary file writes as SYSTEM, the protection layer becomes the escalation path.

The fact that a single researcher found three distinct abuse paths in the same product within two weeks suggests there may be more. If your security strategy depends on Defender being intact and functional, now is the time to add depth.