One of the most dangerous developments in April was the publication of a working exploit for Windows Defender.
CISA added CVE-2026-33825 to its Known Exploited Vulnerabilities catalog after a working proof-of-concept was publicly released. Organizations using Microsoft Defender Antimalware Platform versions earlier than 4.18.26020.6 should apply the required update without delay.
Background: A Researcher’s Breaking Point
On April 2, 2026, a security researcher known by the alias Chaotic Eclipse publicly disclosed BlueHammer, a fully functional proof-of-concept exploit for a Windows local privilege escalation vulnerability. The release was not planned, coordinated, or submitted through a responsible disclosure process. According to available claims, the disclosure was driven by frustration with Microsoft’s vulnerability reporting process.
The impact was immediate. BlueHammer appeared on GitHub and security forums, where it was quickly reviewed, adapted, and added to attacker toolkits. In the two weeks following the initial release, Chaotic Eclipse published two more Microsoft Defender vulnerabilities, named RedSun and UnDefend. This significantly expanded the exposure window.
BlueHammer is especially notable because of the way it chains trusted Windows subsystems. The technique makes conventional detection difficult, as the activity largely appears to involve legitimate operating system components.
CVE-2026-33825: Microsoft Defender Antimalware Platform — Elevation of Privilege
A local attacker with limited privileges can escalate to NT AUTHORITY\SYSTEM by abusing trusted Microsoft Defender file-handling behavior and gaining unauthorized access to sensitive system data. Affected versions include Microsoft Defender Antimalware Platform releases prior to 4.18.26020.6.
Attack Chain: Step by Step
BlueHammer is best understood as a multi-stage exploit that takes advantage of the implicit trust Windows gives to its own security processes. Each stage is structured to appear legitimate. From the kernel’s perspective, much of the activity resembles expected system behavior.
Step 1: Update Reconnaissance
The exploit begins by interacting with legitimate Microsoft Defender update content from Microsoft’s CDN. This helps create an execution context that appears consistent with normal Defender update activity.
Step 2: Triggering Defender and Creating a Shadow Copy
The exploit causes Microsoft Defender to initiate scanning activity and uses timing signals to determine when the target workflow is active. It also monitors for the creation of new Volume Shadow Copy objects to identify when a relevant snapshot becomes available.
Step 3: Freezing Defender via the Cloud Files API
The exploit abuses Cloud Files functionality, normally associated with services such as OneDrive, to create a controlled synchronization context. When Defender interacts with the prepared files, the exploit verifies that the activity comes from the Defender service and temporarily pauses the workflow. This creates a narrow timing window for the next stage.
Step 4: TOCTOU Race — Redirecting to the SAM Database
With Defender temporarily held in place, the exploit manipulates the timing of Defender’s update process. During the transition between file validation and file use, a Time-of-Check to Time-of-Use race condition is abused. As a result, Defender is redirected from the expected update file toward sensitive system data inside the shadow copy.
Step 5: Credential Extraction from SAM
After gaining unauthorized read access to sensitive SAM data, the exploit uses related system information to recover local credential material. This enables the extraction of local NTLM hashes.
Step 6: SYSTEM Shell Spawning and Cleanup
The recovered credential material is used to temporarily abuse a local administrator account. The proof-of-concept is then re-executed with NT AUTHORITY\SYSTEM privileges, resulting in a SYSTEM-level console in the active user session. Afterward, the original account state is restored, making the activity harder to notice.
Why Traditional Detection Fails
BlueHammer is dangerous because it relies on legitimate Windows components throughout the chain. It does not depend on writing new malware binaries. It also does not rely on obviously suspicious API usage in isolation. Instead, it abuses the implicit trust that the operating system places in its own security components.
Defender’s update mechanism, the Volume Shadow Copy Service, and the Cloud Files API are trusted, signed, and expected to operate with elevated privileges. By combining legitimate interactions into a coordinated sequence, BlueHammer creates a privilege escalation path that static analysis tools and traditional behavioral detection rules may struggle to identify.
The Compound Problem: Three Vulnerabilities in Two Weeks
If BlueHammer had been the only issue, the situation would already have been serious. However, within 14 days of the BlueHammer release, Chaotic Eclipse also disclosed two additional Defender vulnerabilities: RedSun and UnDefend. This rapid sequence created an unusual challenge for defenders. Organizations were still working to address one actively exploited vulnerability while two more public exploits were already circulating.
This pattern highlights a known but often underestimated risk in responsible disclosure. When researchers lose confidence in vendor response timelines, informal norms around coordinated disclosure can break down quickly. The result is an asymmetric information environment in which attackers gain immediate access to working exploits while defenders are still assessing the 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.
Organizations using WSUS or SCCM-managed update environments should prioritize accelerated deployment of this platform update. Signature update checks alone are not sufficient, because the affected component is the Defender platform version rather than the definitions database.
Monitor for indicators of compromise, including unexpected Volume Shadow Copy creation events, unusual process interactions with VSS, and local privilege escalation alerts from endpoint detection platforms.
To strengthen detection and response on endpoints, you can use Cynet. The XDR platform helps security teams centrally analyze events across the endpoint, network, identity, and cloud layers, as well as automate threat investigation and response. If you would like to get a free trial of Cynet, please leave your contact details in the form below, and our team will contact you.
