Defender BlueHammer (CVE-2026-33825) Now Actively Exploited — CISA KEV Deadline May 6

Introduction

BlueHammer — the Microsoft Defender local privilege escalation zero-day that shipped without a CVE on April 3, then got patched on April 14 as CVE-2026-33825 — is now being used against real targets with the public proof-of-concept. Huntress has confirmed in-the-wild exploitation starting April 10, with additional activity on April 16. CISA added the bug to its Known Exploited Vulnerabilities catalog on April 22 and set a federal patching deadline of May 6, 2026. The flaw tricks Defender into copying the SAM database out of its protected location, lets a local attacker decrypt NTLM hashes, and pivots to SYSTEM via pass-the-hash. If Defender is your malware-prevention layer, it is now your privilege-escalation vector until you confirm the signature platform update is applied.

What Happened

On April 3, a researcher using the handle Chaotic Eclipse / Nightmare-Eclipse publicly dropped a working local privilege escalation exploit against Microsoft Defender on GitHub — no prior coordinated disclosure. Within 72 hours, Cyderes' Howler Cell team fixed bugs in the original code, published a documented reimplementation (SNEK_BlueWarHammer.exe), and confirmed reliable execution on fully patched Windows 10, Windows 11, and Windows Server. Two companion techniques from the same researcher, RedSun and UnDefend, landed alongside it.

The core BlueHammer technique abuses Defender's signature update path:

  1. An oplock (opportunistic lock) is placed on a file inside Defender's scan/staging directory.
  2. A signature update is triggered (via Windows Update Agent COM interfaces).
  3. The TOCTOU race combined with path confusion tricks Defender into writing into restricted directories and, via symbolic links and Volume Shadow Copy, exposing the Security Account Manager (SAM) hive.
  4. The exploit parses SAM, decrypts local account NTLM hashes, briefly resets a local administrator password, logs in with the new password, duplicates that admin's security token, elevates it to SYSTEM integrity, and creates a temporary service that spawns cmd.exe as NT AUTHORITY\SYSTEM.

RedSun uses the same signature-update workflow to drop a file into System32 by impersonating the quarantined-file restoration path, then spawns a SYSTEM shell. UnDefend disables Defender entirely by locking definition update files the moment they are downloaded, stopping Defender from loading signatures and keeping it in a broken state.

Microsoft patched the underlying issue on April Patch Tuesday (April 14) as CVE-2026-33825 (CVSS 7.8, "insufficient granularity of access control in Microsoft Defender"). The fix is shipped as Microsoft Defender Antimalware Platform version 4.18.26050.3011 or later and distributed automatically via Defender's signature update channel — which means on hosts where Defender itself has been broken (UnDefend, tampering, or policy blocks), the patch is not actually applying.

Huntress first caught in-the-wild exploitation on April 10 — four days before the patch — and observed follow-on activity on April 16, with attackers staging binaries in low-privilege directories such as %USERPROFILE%\Pictures and two-letter subfolders under Downloads. In one case, initial access came via a FortiGate SSL VPN connection, and the operator performed hands-on-keyboard reconnaissance before running the PoC. CISA added CVE-2026-33825 to KEV on April 22 with a federal remediation deadline of May 6, 2026.

Why It Matters

Defender's signature update path runs as SYSTEM, is trusted by the OS, and is difficult for endpoint security tooling to treat as hostile because "Defender writes files" is the normal behavior. BlueHammer takes that trust and uses it to walk through the SAM database in broad daylight. The attack requires only low-privilege local code execution to start — any RCE, any tricked user running a malicious binary, any remote shell — so it chains perfectly with the initial-access techniques defenders already worry about. And because exploitation artifacts include Volume Shadow Copy creation, brief password changes on local accounts, and Defender writing to unusual output directories, the evidence is subtle unless you know where to look.

For Windows Server, exploitation is less reliable and tends to stop at local Administrator rather than SYSTEM — still more than enough to pivot laterally.

Who Is Affected

  • All Windows 10 / 11 endpoints running Microsoft Defender
  • Windows Server hosts (exploitation is less reliable but feasible)
  • Environments where Defender auto-update has been blocked, delayed, or broken by the UnDefend technique
  • Organizations behind FortiGate and other SSL VPN footholds that have been seen used for initial access
  • Federal civilian agencies — CISA binding operational directive, deadline May 6

How to Protect Yourself

Step 1: Verify the Defender Antimalware Platform version is 4.18.26050.3011 or later on every endpoint.

PowerShell:

Get-MpComputerStatus | Select-Object AMProductVersion, AMEngineVersion, AntispywareSignatureVersion, AntivirusSignatureVersion, NISSignatureVersion, RealTimeProtectionEnabled

AMProductVersion below 4.18.26050.3011 means the host is still vulnerable.

Step 2: Force a Defender signature and platform update.

Update-MpSignature
# Full update path (useful if the hosts were affected by UnDefend-style tampering)
& "C:\ProgramData\Microsoft\Windows Defender\Platform\<version>\MpCmdRun.exe" -SignatureUpdate -MMPC

If AMProductVersion will not advance, investigate — the UnDefend technique locks definition files to keep the platform stuck. A reboot plus an sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth can unblock it.

Step 3: Fleet-wide compliance check. For Intune-managed endpoints, create a compliance policy that requires AntimalwareClientVersion >= 4.18.26050.3011. For Configuration Manager:

-- CM compliance query
select Name0, AMProductVersion0
from v_GS_ANTIMALWARE_HEALTH_STATUS
where AMProductVersion0 < '4.18.26050.3011'

Step 4: Hunt for exploitation artifacts. On every endpoint, look for:

  • Volume Shadow Copy creation events (Event IDs 8193, 8194, 8198, 8224) outside scheduled backup windows. Correlate with the Cloud Files driver (cldflt) being in the same event window:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=8193,8194,8198,8224} -MaxEvents 200 |
    Where-Object { $_.TimeCreated -gt (Get-Date).AddDays(-30) } |
    Format-Table TimeCreated, Id, Message -AutoSize
  • Defender engine writing to unusual output directories (Pictures, short two-letter folders under Downloads, Temp):
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 500 |
    Where-Object { $_.Message -match "Pictures|Downloads\\[A-Za-z]{2}\\" } |
    Select-Object TimeCreated, Id, Message
  • Unexplained password changes on local accounts in a short window — check Event ID 4723/4724 in the Security log.
  • Short-lived Windows services spawned under unusual parent processes:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 500 |
    Where-Object { $_.TimeCreated -gt (Get-Date).AddDays(-30) } |
    Format-Table TimeCreated, Id, Message -AutoSize

Step 5: Make the exploit less useful.

  • Enable Credential Guard (Virtualization-based Security → Credential Guard). Even with SAM hashes in hand, pass-the-hash against a Credential-Guard-protected system fails.
  • Turn on LSASS Protected Process Light (PPL) — this raises the bar for subsequent credential theft.
  • Block Volume Shadow Copy creation by non-admin processes via AppLocker or WDAC rules that allow only vssadmin, the Volume Shadow Copy service, and legitimate backup tools to invoke VSS.
  • Monitor the SNEK binary and related hashes at the EDR layer. Huntress published indicators; ingest them into your EDR's blocklist or detection logic.

Step 6: Patch the initial-access path. Huntress saw the attack chain to BlueHammer start with an SSL VPN foothold on a FortiGate. Make sure FortiOS is current, MFA is enforced on SSL VPN, and VPN login activity is monitored for unusual source countries and credential stuffing.

Source