Windows Defender, the built-in antivirus running on every Windows machine, has a zero-day exploit with full source code sitting on GitHub. No patch, no CVE, and confirmed working on fully updated Windows 10 and 11. A researcher who says Microsoft went back on their word just handed every attacker paying attention a privilege escalation that takes any low-privileged account straight to NT AUTHORITY\SYSTEM. On Windows Server the result is different but still serious: a standard user ends up with elevated administrator access. 😏

The vulnerability is called BlueHammer. On April 2nd the researcher posted the public disclosure on a personal blog, and on April 3rd the full exploit source code went live on GitHub. Both published under the alias Chaotic Eclipse, also known as Nightmare Eclipse, with a message to Microsoft’s Security Response Center that comes down to: I told you this would happen.

Before getting into the technical side, there is a backstory here worth knowing.

In late March, the same researcher opened a blog with a single post explaining that they never wanted to come back to public research. Someone had made an agreement with them and then broke it, knowing exactly what the consequences would be. The post says it left the researcher without a home and with nothing. A week later, BlueHammer went live on GitHub with a message that specifically thanks MSRC leadership for making it necessary. That is not someone annoyed with a slow review process. That is someone with nothing left to lose.

Now to the exploit itself, because this one is genuinely worth understanding.

BlueHammer is not a traditional bug, and it does not need shellcode, memory corruption, or a kernel exploit to work. What it does is chain five completely legitimate Windows components together in a sequence that produces something their designers never intended. Those five components are Windows Defender, Volume Shadow Copy Service, the Cloud Files API, opportunistic locks, and Defender’s internal RPC interface. One practical limitation worth knowing: the exploit needs a pending Defender signature update to be available at the time of the attack. Without one in the queue, the chain does not trigger. That makes it less reliable than a push-button exploit, but it does not make it safe to ignore.

Here is how the attack chain works.

When Defender runs an antivirus definition update, part of that process involves creating a temporary Volume Shadow Copy, which is the same snapshot mechanism Windows uses for backup and restore. That shadow copy contains files that are normally completely locked during regular operation, including the SAM database, which stores the password hashes for every local account on the machine.

BlueHammer registers itself as a Cloud Files sync provider, the same kind of thing that OneDrive or Dropbox uses to sync files. When Defender touches a specific file inside that folder, the exploit gets a callback and immediately places an opportunistic lock on that file. Defender stalls, blocked, waiting for a response that is never coming. The shadow copy it just created is still mounted. The window is open.

With Defender frozen in place, the exploit reads the SAM, SYSTEM, and SECURITY registry hives directly from the snapshot. It decrypts the stored NTLM password hashes using the boot key pulled from the SYSTEM hive, changes a local administrator account’s password, logs in with that account, copies the administrator security token, pushes it to SYSTEM level, creates a temporary Windows service, and spawns a command prompt running as NT AUTHORITY\SYSTEM. Then, to cover its tracks, it puts the original password hash back. The local account password looks completely unchanged. No crash, no alert, nothing.

The whole chain runs in under a minute from a normal user session.

The Cloud Files provider name hardcoded in the exploit source code reads IHATEMICROSOFT. The administrator password used during the escalation is hardcoded as $PWNed666!!!WDFAIL. These are not bugs left in by accident. They are messages, written directly into the code, and there is only one intended reader.

Will Dormann, principal vulnerability analyst at Tharros, tested the exploit and confirmed it works well enough to be a real threat.

Microsoft has been cutting costs. Experienced analysts who knew how to look at a complex exploit and actually understand it have been replaced with staff following rigid process checklists. One of those checklist requirements is a video demonstration of the exploit. Researchers who refuse to make a video get their reports closed. Dormann said on Mastodon that he would not be surprised if Microsoft closed the case because the researcher refused to submit a video, since that has apparently become an MSRC requirement.

Microsoft’s only public response to BlueHammer has been a statement about supporting coordinated vulnerability disclosure. Take a moment with that. The whole point of this situation is that Microsoft’s own process broke the coordination. Responding to that by saying you support coordination is not an answer.

Microsoft pushed a Defender signature update that detects the original BlueHammer binary as Exploit:Win32/DfndrPEBluHmr.BB. That signature does not fix the vulnerability. It flags the compiled sample from the published source code. Recompile the same code with any small change and Defender does not flag it at all. The detection catches that one specific file. The technique itself, which runs entirely through normal Windows components doing exactly what they were built to do, stays completely undetected. Until Microsoft fixes the root cause, a signature is not protection.

The Howler Cell research team at Cyderes fixed the bugs in the original PoC and ran the full exploit against patched Windows 10 and 11. It works. SYSTEM shell from a restricted user session in under a minute.

There is still no CVE and no patch. The exploit code is public, the GitHub repository already has more than 100 forks and nearly 300 stars, multiple researchers have fixed the original bugs and confirmed it works, and ransomware groups and APT actors tend to pick up public LPE code and put it to use within days of it going live.

→ Monitor for VSS enumeration coming from regular user processes. Calls to NtQueryDirectoryObject targeting HarddiskVolumeShadowCopy objects from anything outside of backup or system tooling is a red flag with almost no innocent explanation.

→ Watch for Cloud Files sync root registration by unknown processes. CfRegisterSyncRoot being called from anything other than OneDrive, Dropbox, or Box is worth checking immediately. That call is exactly how BlueHammer sets up its trap.

→ Alert on low-privileged processes creating Windows services or grabbing SYSTEM-level tokens. BlueHammer uses CreateService to briefly register a malicious service during the escalation, and that shows up in EDR telemetry.

→ Watch for quick back-to-back password changes on local administrator accounts. BlueHammer resets the password, uses it, then resets it back. Security event IDs 4723 and 4724 firing twice in quick succession on the same account does not have a normal explanation.

→ Keep permissions tight. BlueHammer needs a local session to run, so every permission a standard user does not actually need is attack surface that can be removed.

→ Keep watching Microsoft security advisories for a patch. When it comes, treat it as high priority.

Understanding how privilege escalation works, how attackers get from a basic foothold to full system control, and what post-exploitation actually looks like is exactly what I cover in my ethical hacking course. BlueHammer is a real-world example of the kind of techniques that come up in penetration testing all the time.

(The link supports me directly as your instructor!)

Hacking is not a hobby but a way of life.

Sources: Chaotic Eclipse — Public Disclosure · BlueHammer — GitHub