On March 26, 2026, a blog called Chaotic Eclipse published its first and only non-technical entry. Its readership that day was likely zero.
The next time anyone paid attention was the day he turned Windows Defender, Microsoft’s own antivirus tool, into a credential theft engine and posted the code for anyone to use.
With this code, anyone on the planet could take complete control of a Windows machine — no administrator password required.
The reason this wasn’t noteworthy wasn’t what he found. It’s what he chose to do with it.
In the bug bounty world, an exploit such as this could be worth anywhere from tens of thousands to over one hundred thousand dollars — life-changing money in almost any economy.
In a world where zero days are more valuable than a house in some countries, they aren’t given out freely. But when the contract that governs both researchers and responders breaks down, the unthinkable can happen.
The true value — and the researcher’s only leverage — is that the flaw is unknown to anyone but them. Companies will pay significant sums, and governments sometimes more, depending on the vulnerability. But that leverage is also a nuclear weapon. The instant a vulnerability is released publicly, it loses all value. Companies, governments, good and bad actors are free to use it however they see fit.
I don’t know where the discussion broke down, but what came next told me not only was it irreparable, but approximately when it happened.
On April 2, 2026, a repository called BlueHammer appeared on a new GitHub account. The same day, a blog post appeared alongside it. Four words: “I was not bluffing.”
Nightmare-Eclipse had just released onto the world an unpatched, high-severity Windows vulnerability affecting millions of deployments worldwide.
The BlueHammer repository as it appeared on GitHub, April 2, 2026. Note the single initial commit.
A working zero day vulnerability very rarely hits the public eye. And even more rarely is the entirety of the source code available anonymously to anyone, anywhere on the planet.
What was to follow can only be described as absolute chaos.
The inner workings of this code and the underlying vulnerability have been explored ad nauseam in the security space since its release. Exploring the technical details is left as a Google exercise for the reader.
What I will tell you is something that has been there all along. You just didn’t notice.
Any analyst can throw this repo at an AI and get a competent technical summary in thirty seconds. That’s not the hard part. Knowing where to look is harder. What I’m doing here is what I’ve done for thirty years. I just didn’t have to crack open a reference book to do it.
What I will say is this: BlueHammer was the first of three repositories dropped by the same researcher across thirteen days. Each one targeted a different behavior in Windows Defender. Together, they form what I’ve come to think of as a suite — three movements, one composer, one grievance.
BlueHammer, RedSun, and UnDefend — the three repositories published by Nightmare-Eclipse between April 2 and April 16, 2026.
BlueHammer — April 2. The opening movement. Local privilege escalation via Defender’s signature update workflow, Volume Shadow Copy, and opportunistic file locks. Sprawling, exploratory, 4MB of code of which approximately 98% is noise.
UnDefend — April 12. The bridge. A Defender denial-of-service tool that locks definition files, preventing signature updates. Thirteen kilobytes. Wholly original. Written fast and angry.
RedSun — April 15. The close. A second local privilege escalation, this time abusing Defender’s cloud file rollback mechanism. Twenty-seven kilobytes. Clean. Deliberate. Reusing the core technique from BlueHammer with the debris cleared away.
The immediate consensus in the security community was that BlueHammer had been intentionally obfuscated with junk code. After reviewing it, I came away with a different opinion.
The most striking example is the WinDefend RPC interface files included in the repository. Four files — windefend.idl, windefend_h.h, windefend_c.c, and windefend_s.c — representing a completely reverse-engineered interface to Windows Defender’s internal RPC communication layer. Almost certainly MIDL-generated: produced automatically by a compiler tool after the researcher reverse engineered the Defender interface, then shipped wholesale because cleaning it up wasn’t the priority.
File size comparison across the BlueHammer repository. The four WinDefend RPC files account for nearly 4MB. The actual exploit is 90KB.
The numbers tell the story cleanly. The four WinDefend files together weigh in at just under four megabytes. The actual exploit code is ninety kilobytes. Of the 236 RPC procedures defined across those files, exactly one is called anywhere in the exploit — Proc42_ServerMpUpdateEngineSignature. The other 235 are dead weight.
Strip the project down to its functional core and BlueHammer is roughly 105 kilobytes of actual exploit. The remaining 98% of the codebase is noise — not planted there to confuse analysts, but left there because the work was done and shipping was the priority.
The dead functions tell the same story. ThrowFunc throws zero and is never called. CUST_FNOPEN is a cabinet file callback from an earlier implementation approach that was superseded. FreezeVSS and CfCallbackFetchPlaceHolders are remnants of attack primitives that evolved into something else. These aren’t padding — they’re archaeological artifacts of a researcher working through a problem in real time.
By the time RedSun shipped, the debris was gone. Same primitive, fully understood, executed cleanly. The progression from BlueHammer to RedSun is not the work of someone obfuscating. It’s the work of someone who found their footing.
The proof-of-concept screenshot included in the RedSun repository. Windows 11 24H2, fully patched. The spawned shell shows NT AUTHORITY\SYSTEM.
The why, the when, and the how of it all are self-evident. So with only a single mystery left, I set out to answer — who would do such a thing?
Part 2 — The Evidence — coming soon.