BlueHammer: The Unpatched Windows Zero-Day That Weaponizes Microsoft Defender Against Your Own System

On April 3rd, 2026, a security researcher operating as "Chaotic Eclipse" pushed a Windows local privilege escalation exploit to GitHub. No CVE request. No coordinated disclosure. No patch waiting in the wings. Just working exploit code and a pointed message to Microsoft's Security Response Center: "I was not bluffing Microsoft, and I'm doing it again."

The exploit is called BlueHammer. Howler Cell at Cyderes investigated it, fixed bugs in the published proof-of-concept code, and ran it end-to-end against patched Windows 10 and 11 systems. A low-privileged user shell escalated to NT AUTHORITY\SYSTEM in under a minute. No administrative rights required to start. No kernel exploit involved.

The vulnerability remains unpatched. Microsoft's only public response: a statement that it "supports coordinated vulnerability disclosure." The disclosure was anything but coordinated, which Microsoft's phrasing acknowledges without saying.

What Makes BlueHammer Different

Most privilege escalation exploits attack a specific bug: a memory corruption in a kernel driver, a type confusion in a system call, a bounds check failure in a privileged process. You find the bug, you write shellcode or craft a payload, you exploit it.

BlueHammer does none of that. No shellcode. No heap spray. No race against the kernel.

The exploit chains four legitimate, documented Windows features together in a sequence that produces a privileged access window nobody designed for and nobody checks for. Each component works exactly as Microsoft intended. The vulnerability only appears when they interact.

The four components:

• Microsoft Defender's update and remediation workflow, which temporarily creates a Volume Shadow Copy snapshot during certain operations
• Volume Shadow Copy Service (VSS), which creates that snapshot with elevated access to registry hive files
• Cloud Files API, which lets applications register as cloud sync roots and receive callbacks when Defender accesses files in those directories
• Opportunistic locks (oplocks), which let the attacker hold Defender in a blocked state at a precise moment
  Chain them in the right order and you get a window where Defender has created a privileged snapshot of the system, frozen itself waiting for a callback that never arrives, and left the SAM, SYSTEM, and SECURITY registry hives – normally locked at runtime – sitting accessible in that snapshot.

The Exploit Chain, Step by Step

Howler Cell published the full technical breakdown. Here is how the chain operates:

Step 1: Verify a pending Defender signature update

The exploit queries Windows Update COM interfaces to find a pending Defender signature update. Without one in the queue, the exploit halts. The entire chain depends on triggering Defender's update-and-remediation workflow, which only fires when an update is available to install.

Step 2: Download and unpack the Defender update package

The exploit fetches a legitimate Defender update executable directly from Microsoft's update URL. It parses the PE file in memory, extracts the embedded CAB archive from the .rsrc section, and unpacks all files in memory. These extracted files become the update source for spoofed Defender RPC calls via ServerMpUpdateEngineSignature, with NTFS junctions redirecting the update path toward an attacker-controlled directory.

Step 3: Bait Defender into scanning and creating a shadow copy

The exploit creates a temporary directory, drops an EICAR test file named foo.exe to trigger Defender scanning, and opens RstrtMgr.dll with a batch oplock as a tripwire. When Defender accesses RstrtMgr.dll, the oplock breaks, signaling that Defender is active and has likely started creating a Volume Shadow Copy as part of its remediation workflow. A worker thread runs concurrently, enumerating \\Device with NtQueryDirectoryObject to track new HarddiskVolumeShadowCopy* devices as they appear.

Step 4: Freeze Defender via Cloud Files callbacks and oplocks

The exploit registers the current directory as a Cloud Files sync root using CfRegisterSyncRoot and CfConnectSyncRoot. A randomly named .lock placeholder drops inside the sync root, waiting for Defender to find it. When Defender enumerates the directory and touches the placeholder, the CfCallbackFetchPlaceholders callback fires, checks the caller PID, and confirms the request comes from the WinDefend service process.

At that moment, the exploit acquires a second batch oplock on the .lock file. The callback refuses to return until it holds the oplock. Defender stalls, blocked on GetOverlappedResult(hlock, &ovd, &nwf, TRUE). The callback never completes. Defender cannot proceed.

The Volume Shadow Copy Defender created moments before is still mounted. The window is open.

Step 5: Read registry hives from the shadow copy

With Defender frozen, the exploit opens the registry hives directly from the shadow copy device path:

\\Device\\HarddiskVolumeShadowCopy12\\Windows\\System32\\Config\\SAM
\\Device\\HarddiskVolumeShadowCopy12\\Windows\\System32\\Config\\SYSTEM
\\Device\\HarddiskVolumeShadowCopy12\\Windows\\System32\\Config\\SECURITY

These files are normally locked and inaccessible to unprivileged processes at runtime. From the shadow copy, an unprivileged user can read them directly.

Step 6: Extract the boot key and decrypt NTLM hashes

The code reads the SYSTEM hive keys JD, Skew1, GBG, and Data from Control\Lsa, reconstructs the 16-byte boot key, and uses it to decrypt the LSA secret key. This is standard Impacket-style credential extraction -- the same approach used in tools like secretsdump. The difference here is that it runs against a live shadow copy that Defender itself created and then got stuck watching.

The Password Encryption Key comes from the SAM hive. AES and DES routines decrypt the stored NTLM password hashes for local accounts. The exploit now has everything it needs.

Step 7: Escalate, spawn a SYSTEM shell, and clean up

The exploit calls SamiChangePasswordUser from samlib.dll to forcibly change a local Administrator account's password to an attacker-controlled value. It logs in as that administrator with LogonUserEx, duplicates the security token, assigns SYSTEM integrity levels, and uses CreateService to register a temporary malicious Windows service. That service executes the PoC again, but this time spawns a cmd.exe instance running as NT AUTHORITY\SYSTEM in the user's current session.

Then, to avoid detection, the exploit calls SamiChangePasswordUser a second time to restore the original NTLM hash. From the user's perspective, their password never changed. The only trace is a SYSTEM shell the attacker controls.

Why the Published PoC Has Bugs and Why That Does Not Matter

The researcher, Chaotic Eclipse, published the exploit after becoming frustrated with MSRC. Microsoft allegedly dismissed the report after the researcher declined to submit a required video demonstration. The published PoC contained bugs that affected reliable execution.

Howler Cell resolved those bugs and confirmed full end-to-end exploitation. Principal vulnerability analyst Will Dormann of Tharros independently confirmed the exploit functions, noting that it is not trivial to weaponize but is operationally relevant.

The bugs in the published code create a reliability problem for someone who copies and pastes without understanding what they are running. For anyone who reads the code, understands the technique, and patches the issues – as Howler Cell did and as any competent threat actor will – the path to SYSTEM is clear. Ransomware operators and APT groups routinely weaponize public LPE proof-of-concept code within days of release. This exploit has been public since April 3rd.

Microsoft's Detection Response and Why It Falls Short

Defender now detects the original PoC binary as Exploit:Win32/DfndrPEBluHmr.BB. That signature flags a compiled sample from the published source code. It does not detect the technique.

BlueHammer roots in how Windows components interact, not in any specific binary. Recompiling from slightly modified source code bypasses the signature entirely. The behavioral TTPs remain undetected by Defender. Signature detection on the published PoC binary is theater -- useful for keeping script kiddies out, inadequate against anyone with programming capability.

Microsoft has not assigned a CVE. Microsoft has not issued a patch. The vulnerability is unpatched on all current Windows 10 and 11 installations.

What Defenders Should Monitor

Howler Cell recommends behavioral detection and hardening while waiting for Microsoft to issue a fix. Specifically:

VSS enumeration from non-system processes. Unexpected calls to NtQueryDirectoryObject targeting HarddiskVolumeShadowCopy* from user-space processes indicate BlueHammer-style reconnaissance. Legitimate software that enumerates shadow copies is almost exclusively system and backup tooling. User-space processes doing this are suspicious by default.

Cloud Files sync root registration by untrusted processes. CfRegisterSyncRoot calls from processes outside known cloud sync software (OneDrive, Dropbox, Box) warrant investigation. This API call is central to the timing trap BlueHammer sets. General-purpose applications do not call it.

Low-privileged processes spawning Windows Services or acquiring SYSTEM-integrity tokens. BlueHammer uses CreateService to briefly register a malicious temporary service. Non-administrative user processes calling service creation APIs should trigger in EDR telemetry.

Rapid consecutive password changes on local Administrator accounts. BlueHammer calls SamiChangePasswordUser twice in quick succession -- once to set the attacker's password, once to restore the original hash. Security event IDs 4723 and 4724 (password change events) firing in rapid sequence on a local Administrator account have almost no legitimate explanation.

Restrict Cloud Files API and VSS access for standard user accounts. BlueHammer requires local access to execute. Limiting what compromised standard user accounts can interact with reduces the attack surface before the root cause gets addressed.

The Architecture Is the Vulnerability

Howler Cell's conclusion deserves quoting in intent even if not in literal words: BlueHammer is a time-of-check to time-of-use race condition, but the execution is unusual. Defender creates and exposes a VSS snapshot before it holds exclusive control over it. That gap is the vulnerability. Cloud Files callbacks and oplocks widen that gap to a reliable, exploitable window.

No kernel exploit. No memory corruption. The attack works because Defender can be forced into pausing itself at the worst possible moment, leaving privileged resources accessible with nothing watching them.

This is what modern privilege escalation increasingly looks like. The attack surface is not a broken function. The attack surface is the design. When documented, supported Windows features combine in a sequence nobody modeled during threat analysis, the result is a SYSTEM shell from a standard user account in under 60 seconds.

The exploit is public. The PoC is on GitHub. The patch does not exist.

Apply the behavioral detections Howler Cell outlined. Watch your service creation events. Monitor your shadow copy enumeration. And push your vendor contacts at Microsoft for a timeline on the fix.