A researcher’s dissatisfaction with Microsoft’s disclosure process led to one of April’s most dangerous moments: a working privilege escalation exploit for Windows Defender that turns the operating system’s most trusted security component against itself.
Active Exploitation Warning
CISA added CVE-2026-33825 to the Known Exploited Vulnerabilities catalog following public release of a working proof-of-concept. Organizations running Microsoft Defender Antimalware Platform versions prior to 4.18.26020.6 should patch immediately.
Background: A Researcher’s Breaking Point
On April 2, 2026, a security researcher operating under the alias Chaotic Eclipse publicly released BlueHammer, a fully functional proof-of-concept exploit for a Windows local privilege escalation vulnerability. The release was not scheduled, coordinated, or disclosed through any responsible disclosure process. Allegedly, the disclosure was ultimately an act of frustration with Microsoft’s vulnerability reporting process.
The fallout was immediate. BlueHammer landed on GitHub and security forums and was quickly analyzed, weaponized, and incorporated into attacker toolkits. Within the two weeks following the initial release, Chaotic Eclipse published two additional Microsoft Defender vulnerabilities named RedSun and UnDefend, compounding the exposure window significantly.
What makes BlueHammer particularly noteworthy is its elegance. The exploit chains together multiple trusted Windows subsystems in a way that makes traditional detection deeply difficult.
CVE-2026-33825: Microsoft Defender Antimalware Platform — Elevation of Privilege
A low-privileged local attacker can escalate to NT AUTHORITY\SYSTEM by abusing Microsoft Defender’s trusted file handling workflow and obtaining an arbitrary read handle to the SAM database. Affected versions: Microsoft Defender Antimalware Platform prior to 4.18.26020.6.
Attack Chain: Step by Step
BlueHammer is best understood as a multi-stage exploit that abuses the implicit trust Windows grants to its own security processes. Each stage is designed to look legitimate, because it largely is, at least from the kernel’s perspective.
Step 1: Update Reconnaissance
The exploit begins by fetching legitimate Microsoft Defender update content from Microsoft’s CDN. This establishes a legitimate execution context, making the subsequent stages appear to be part of a normal signature update process.
The exploit retrieves legitimate Defender update content used later in the chain.
Step 2: Triggering Defender and Creating a Shadow Copy
An EICAR test file is dropped to bait Defender into scanning activity. Simultaneously, RstrtMgr.dll is placed with a batch oplock as a timing marker. A worker thread monitors for new HarddiskVolumeShadowCopy objects, confirming when Defender enters the target workflow and a new VSS snapshot is ready.
Defender is triggered using an EICAR test file, while RstrtMgr.dll and shadow-copy monitoring are used as timing signals.
Step 3: Freezing Defender via the Cloud Files API
The working directory is registered as a fake cloud sync root using CfRegisterSyncRoot and CfConnectSyncRoot, APIs normally used by OneDrive and similar services. A .lock file is placed inside. When Defender touches it, the CfCallbackFetchPlaceHolders callback fires, verifies the caller is the WinDefend service, and holds Defender in a paused state using a coordinated batch oplock, creating a precise timing window.
CfCallbackFetchPlaceHolders is triggered when Defender reaches the fake Cloud Files sync root and confirms that the requesting process is WinDefend
FreezeVSS places a batch oplock on the .lock file and waits for Defender to access it again, effectively freezing Defender and signaling that the new Volume Shadow Copy is ready.
Step 4: TOCTOU Race — Redirecting to the SAM Database
With Defender frozen, the exploit triggers Defender’s update engine with legitimate files. As Defender creates a new definition directory and resolves mpasbase.vdm, a Time-of-Check to Time-of-Use (TOCTOU) race condition is exploited: the resolved path is swapped so Defender opens the SAM database inside the shadow copy instead of the expected update file.
Step 5: Credential Extraction from SAM
With a read handle to the SAM hive, the exploit reconstructs the Windows boot key from HKLM\SYSTEM\CurrentControlSet\Control\Lsa, decrypts the SAM password encryption material, and recovers local NTLM hashes.
The exploit reconstructs the Windows boot key so the leaked SAM data can be decrypted.
Step 6: SYSTEM Shell Spawning and Cleanup
Recovered NTLM hashes are used to temporarily change a local admin account’s password. A temporary Windows service re-runs the PoC as NT AUTHORITY\SYSTEM. A SYSTEM console launches in the active user session. The original password is then restored using the recovered hash, leaving the user’s credentials unchanged and the attack largely invisible.
The exploit begins the final privilege escalation stage by preparing attacker-controlled credentials for account abuse.
Why Traditional Detection Fails
BlueHammer’s danger lies in its use of legitimate Windows components at every stage. The exploit never writes novel malware binaries. It never calls overtly suspicious APIs in isolation. What it does is abuse the implicit trust the operating system places in its own security components.
Defender’s update mechanism, the Volume Shadow Copy Service, the Cloud Files API, all are trusted, signed, and expected to operate with elevated privileges. By orchestrating a chain of legitimate interactions, BlueHammer creates a privilege escalation path that static analysis tools and traditional behavioral rules are poorly positioned to detect.
The Compound Problem: Three Vulnerabilities in Two Weeks
If BlueHammer alone were the story, it would be serious enough. But Chaotic Eclipse followed up with two additional Defender vulnerabilities, RedSun and UnDefened, within the 14 days after BlueHammer’s release. This rapid succession created an unusual situation where defenders were racing to patch one actively-exploited vulnerability while two more public exploits were already circulating.
The pattern reflects a known but underappreciated risk in responsible disclosure: when researchers become frustrated with vendor response timelines, informal norms around coordinated disclosure can break down rapidly. The result is an asymmetric information environment where attackers gain immediate access to working exploits while defenders are still assessing impact.
Mitigation
Update Microsoft Defender Antimalware Platform to a version later than 4.18.26030.3011. This update is delivered through Windows Update and Microsoft Defender platform updates.
For organizations with WSUS or SCCM-managed update environments, prioritize accelerated deployment of this platform update. Do not rely solely on signature update checks — the affected component is the Defender platform version, not the definitions database.
Monitor for indicators of compromise including unexpected volume shadow copy creation events, unusual processes interacting with VSS, and any local privilege escalation alerts from endpoint detection platforms.