BlueHammer: Inside the Windows Zero-Day

Summary

On April 3rd, 2026, a security researcher operating under the alias "Chaotic Eclipse" dropped a fully functional Windows local privilege escalation exploit on GitHub - no coordinated disclosure, no CVE, no patch. 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.”

Howler Cell investigated the vulnerability, dubbed BlueHammer, which exploits the Windows Defender update process through Volume Shadow Copy abuse to escalate a low-privileged user to NT AUTHORITY\SYSTEM. The vulnerability remains unpatched. No CVE has been assigned. Microsoft’s only public response was a statement that it “supports coordinated vulnerability disclosure” - notable phrasing given that the disclosure was anything but coordinated.

Key Findings 

• Howler Cell investigated BlueHammer, a publicly released, unpatched Windows zero-day that allows a low-privileged local user to escalate to NT AUTHORITY\SYSTEM. Full proof-of-concept source code is live on GitHub and has been independently confirmed to work by vulnerability researcher Will Dormann of Tharros.
• The exploit requires no kernel bug, no memory corruption, and no code execution inside Defender. It abuses the interaction between Microsoft Defender’s update workflow, Volume Shadow Copy Service, the Windows Cloud Files API, and opportunistic locks - all legitimate, documented Windows features. Each component works as designed. The vulnerability only emerges when they are chained together in the right order.
• During certain Defender update and remediation workflows, Defender creates a temporary Volume Shadow Copy snapshot. BlueHammer uses Cloud Files callbacks and oplocks to pause Defender at precisely the right moment, leaving the snapshot mounted and the SAM, SYSTEM, and SECURITY registry hives accessible - files that are normally locked at runtime.
• Successful exploitation allows an attacker to read the SAM database, decrypt NTLM password hashes, take over a local administrator account, and spawn a SYSTEM-level shell, all while restoring the original password hash to avoid detection.
• Recent Defender signature updates now detect the original PoC binary as Exploit:Win32/DfndrPEBluHmr.BB. Because the weakness lives in how Windows components interact, not in any single file, an attacker can modify the implementation and reach the same result, bypassing this Defender detection.
• The disclosure was uncoordinated. The researcher, operating as Chaotic Eclipse, published the exploit after reportedly becoming frustrated with MSRC,  which allegedly dismissed the report after the researcher declined to submit a required video demonstration. Microsoft has not issued a patch or assigned a CVE. Ransomware operators and APT actors routinely integrate public LPE PoC code within days of release.
  

The published PoC contained bugs that prevented reliable execution. The Howler Cell team resolved those issues and ran the exploit end-to-end against patched Windows 10 and 11 systems. The video below is our verification run - a low-privileged user shell escalating to NT AUTHORITY\SYSTEM in under a minute, with no kernel exploit and no administrative rights required to start.

Video: BlueHammer exploitation verification run 

The full technical breakdown of how the exploit chain operates follows below.

What is the Vulnerability? 

BlueHammer is a design flaw and race condition rooted in how Microsoft Defender, Volume Shadow Copy Service, Cloud Files callbacks, and opportunistic locks interact under specific timing conditions. It was independently confirmed as functional by Will Dormann, principal vulnerability analyst at Tharros, who noted the exploit is not trivial to weaponize, but works well enough to be operationally relevant.

This is not a traditional exploit. No shellcode. No heap spray. No race against the kernel. The PoC abuses timing and system behavior. The researcher acknowledged the published code contains bugs that may affect reliability and noted he may fix them later. Howler Cell reproduced and verified full exploitation after resolving those issues.

Three separate Windows features become dangerous when combined:

• During update and remediation workflows, Defender temporarily creates a VSS snapshot, a privileged side-door into the filesystem.
• Cloud Files callbacks give an attacker precise control over when Defender receives a file response, effectively a programmable pause button on the antivirus process.
• Opportunistic locks (oplocks) let the attacker hold Defender in a blocked state at a precise, reproducible moment while the snapshot remains mounted and readable

Each feature is legitimate on its own and well-documented by Microsoft. The vulnerability only materializes when they are chained together in the right order. The steps above are covered in detail in the Technical Analysis section below.

Technical Analysis

The goal of the exploit chain is straightforward: force Microsoft Defender to create a new Volume Shadow Copy, pause Defender at precisely the right moment, then access sensitive registry hive files from that snapshot before Defender can clean up. What follows is a step-by-step breakdown of how the PoC achieves this.

Check for a pending Defender signature update 

The code (Figure 1) queries the Windows Update COM interfaces to enumerate available updates, looking specifically for entries classified under both “Microsoft Defender Antivirus” and “Definition Updates.” If no Defender signature update is pending, the exploit chain halts. The update is a prerequisite; Defender won’t trigger the VSS-creating workflow without one in flight.

Figure 1: Check for Pending Defender Signature Updates

Download and unpack the Defender update package 

The exploit fetches a legitimate Defender update executable directly from Microsoft’s update URL https://go.microsoft[.]com/fwlink/?LinkID=121721&arch=x64

The PE is parsed in memory, the embedded CAB file update.cab from the .rsrc section is extracted and all files are unpacked in memory. These extracted files are then used as the update source for spoofed Defender RPC calls via the internal ServerMpUpdateEngineSignature method, with NTFS junctions redirecting the update path toward an attacker-controlled directory.

Trigger Defender to start a scan and create a shadow copy

The code (Figure 2) creates a temporary directory and drops an EICAR test file named foo.exe to bait Defender into scanning. It also opens RstrtMgr.dll with a batch oplock, which serves as a tripwire. When Defender accesses RstrtMgr.dll, the oplock breaks, signaling that Defender is active and has likely begun creating a new Volume Shadow Copy as part of its remediation workflow.

A worker thread continuously enumerates \\Device with NtQueryDirectoryObject and records all existing HarddiskVolumeShadowCopy* devices.

Figure 2: Trigger Defender to start a scan

Freezing Windows Defender via VSS and Cloud Filter API

The exploit registers the current directory as a Cloud Files sync root using CfRegisterSyncRoot(...) and CfConnectSyncRoot(...). A randomly named .lock placeholder is dropped inside the sync root and left for Defender to find. When Defender enumerates the directory and accesses the placeholder, the CfCallbackFetchPlaceHolders callback fires and checks the caller PID. When it confirms the request is coming from the WinDefend service process, it signals that Defender has entered the trap.

Once Defender touches the .lock file, the exploit immediately acquires a second batch oplock on that same file. The callback refuses to return until the oplock is held. Defender stalls waiting for a response that never comes, blocked on GetOverlappedResult(hlock, &ovd, &nwf, TRUE); The VSS snapshot Defender created moments before is still mounted. The window is open.

Access files inside the new shadow copy

With Defender frozen, the exploit opens the registry hives directly from the shadow copy device path - files that are normally locked and inaccessible to unprivileged processes at runtime. The paths accessed include:

\\Device\\HarddiskVolumeShadowCopy12\\Windows\\System32\\Config\\SAM

\\Device\\HarddiskVolumeShadowCopy12\\Windows\\System32\\Config\\SYSTEM

\\Device\\HarddiskVolumeShadowCopy12\\Windows\\System32\\Config\\SECURITY

Recover the boot key and decrypt LSA secrets

Figure 3: Recover the boot key and decrypt LSA secrets

The code (Figure 3) 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 - but the twist here is that it’s being done against a live shadow copy that Defender itself created and then got stuck watching.

The Password Encryption Key is then extracted from the SAM hive, and AES and DES routines are used to decrypt the stored NTLM password hashes for local accounts. At this point, the exploit has everything it needs.

Privilege Escalation, Cleanup, and Shell Spawning

With NTLM hashes in hand, the exploit pivots to full SYSTEM. The steps are deliberate and self-cleaning:

• It uses the samlib.dll function SamiChangePasswordUser to forcefully change a local Administrator's password to an attacker-controlled value ($PWNed666!!!WDFAIL) as shown in Figure 4.
• It logs in as that Administrator using the new password (LogonUserEx).
• It duplicates the security token of the Administrator, assigns it SYSTEM integrity levels, and uses CreateService to create a malicious temporary Windows Service.
• This service executes the PoC executable again, but this time it spawns a cmd.exe instance running as NT AUTHORITY\\SYSTEM in the user's current session.
• Finally, to hide its tracks, it uses SamiChangePasswordUser again to restore the original NTLM password hash it dumped earlier, leaving the user's password unchanged from their perspective.

Figure 4: Privilege Escalation