Six Working Windows Zero Days and the Researcher Microsoft Called a Criminal

Six working Windows attacks are sitting in the open right now, three of them already seen in a real intrusion, and the researcher who published them did it after he says Microsoft refused him, deleted the account he reported bugs through, and paid him nothing. Microsoft removed his account, called his actions criminal, and pointed at its crime unit. Both stories are out there, and the security world cannot agree on who is more to blame.

He goes by a few names. On GitHub he was Nightmare-Eclipse, most of the coverage calls him Chaotic Eclipse, and his blog runs under the name Dead Eclipse. Nobody has confirmed who he is. There are rumours he once worked at Microsoft, but a rumour is all it is. What is on the record is the pace: in roughly six weeks he published six working zero-days. Six. The GitHub account he used is gone now, removed by Microsoft, which is where the conflict turns sharp.

A zero-day is a flaw the vendor has not fixed yet, sometimes one they did not even know existed. The dangerous part is the timing. When working attack code goes public before there is a patch, every defender starts the race already behind, and every attacker who grabs the code starts ahead. That gap, between the code being out and the fix being ready, is where the damage happens. And that gap is what this fight is about.

Here are the six, and what each one actually does.

The first one turns the antivirus against the machine it is supposed to guard. It is called BlueHammer, tracked as CVE-2026-33825. Windows Defender, the built-in antivirus, runs with the highest power a Windows machine has, the SYSTEM account, because it needs that to scan everything. BlueHammer tricks Defender into reading files it should not touch, reaches the part of Windows where passwords are stored, pulls the password data out, and walks away with that same SYSTEM power. The guard hands over its own keys. Microsoft fixed this one in the April update, so on an up-to-date machine it is closed. And here is a detail that stings: when Microsoft credited the fix, the names they put on it were two other researchers, Zen Dodd and Yuanpei Xu, not the person who actually published the bug. I wrote up BlueHammer in full when it dropped in April.

The second one is RedSun, tracked as CVE-2026-41091. It goes after Defender too, but the other way around. Instead of reading secrets out, it drops attacker-chosen files into protected system folders that are supposed to be off limits. It does this by fooling a Windows storage service with a trick called a directory junction, which points Windows at a folder it was never meant to write to. It worked on fully updated Windows 10, Windows 11, and Server 2019. RedSun sat unpatched for about six weeks while it was already being used in attacks, and Microsoft only put out a real fix on May 21, an out-of-band update outside the normal monthly schedule. The researcher says Microsoft quietly fixed it even earlier without telling anyone, while the bug was live, which would be its own kind of mess if it is true. Either way, six weeks is a long time to leave a hole open that people are already getting hit through.

The third one does not break in at all. It just switches off the alarm. It is called UnDefend, tracked as CVE-2026-45498. It slowly cuts Defender off from its updates so the protection gets weaker and weaker, and it does this without setting anything off. Worse, it can lie to your security dashboard, so the console tells you Defender is up to date and running fine when it is neither. The Cloud Security Alliance flagged exactly this, telling admins to check the Defender version by hand instead of trusting what the dashboard says, because UnDefend can fake it. The machine looks perfectly fine from the outside while its defence quietly stops working. Chained behind one of the privilege attacks, an attacker gets in as SYSTEM and then makes sure the security software keeps getting worse at spotting whatever they do next. RedSun and UnDefend both got their out-of-band fix on May 21, the same day, after sitting open for weeks. I covered the pair back in April when they first dropped.

The fourth one made people sit up, because it beats the thing most people count on to protect a stolen laptop. It is called YellowKey, tracked as CVE-2026-45585, and it gets past BitLocker, the full-disk encryption built into Windows. With about a minute of physical access and a normal USB stick, an attacker drops straight into a SYSTEM command shell on an encrypted drive, no password, no recovery key. It does not crack the encryption, and that part matters. The math behind BitLocker is fine. The weak spot sits in the Windows Recovery Environment, the repair mode that loads before Windows itself, where a trusted piece of that startup process gets tricked into reopening a saved action and letting someone onto the unlocked drive. I walked through the full YellowKey attack last month.

On paper YellowKey scores a 6.8, which counts as medium. That number is misleading. The only reason it is not rated higher is that the attacker has to be physically at the machine. Once they are, the damage to your data is rated high across the board. So for a laptop that gets stolen or left unattended, medium is not the word that should be on your mind.

The fifth is GreenPlasma, another privilege-escalation flaw buried in Windows internals, with no patch at the time of writing.

The sixth is MiniPlasma. It takes a normal user account and pushes it all the way up to SYSTEM on a fully patched Windows 11 machine. It abuses the Cloud Files driver, and the bug it uses is roughly six years old, first found by Google Project Zero, and somewhere along the way it was either never properly fixed or fixed and then undone. I covered MiniPlasma on its own last month.

The anger is written straight into the working code. To pull off its trick, RedSun has to register itself as a fake cloud sync provider, the same kind Windows uses for OneDrive, and it needs a name for that. The name sitting in the source code, where anyone can read it, is SERIOUSLYMSFT, with a comment next to it daring Microsoft to keep playing this game. BlueHammer used the name IHATEMICROSOFT, and it carries a hardcoded password string aimed squarely at Microsoft. This is not a quiet technical disagreement. It is a public fight with Microsoft, spelled out inside attack code that is already in the hands of real attackers.

Huntress, a security firm, investigated an intrusion where an attacker tried to use this toolkit, and three of the four tools they dropped failed. Defender quarantined BlueHammer. RedSun produced no result. The UnDefend tools were run wrong by the attacker, who clearly did not fully understand them. The only piece that worked was a tunnelling tool, used to keep a connection open for later. The code is out there and the danger is genuine, but a properly patched and properly configured Windows machine held up far better than the panic would suggest.

There is another detail from that intrusion that matters for defenders. The attacker got in through a compromised FortiGate SSL VPN account. They came through weak remote access first, and only reached for these tools once they were already inside. The zero-day gets the headlines, but the initial access through a weak account is where the intrusion actually started.

If you run Windows machines, a few things help right away.

• → Get your machines onto the April 2026 cumulative update and make sure the Defender engine is current. The engine updates on its own channel, separate from the big monthly Windows updates, so check both. You can see where you stand by opening PowerShell as administrator and running:

1

Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, AntivirusSignatureLastUpdated

• → For YellowKey, the default BitLocker setup, called TPM-only, stays exposed. Switch encrypted devices to TPM+PIN, which forces a startup PIN before the drive unlocks and closes off the physical attack. You can do this through PowerShell, Group Policy, or Intune.
• → Lean on behaviour-based detection, not just signatures. These tools abuse legitimate Windows components doing legitimate things, so a defence that only looks for known-bad files will miss them. Watch for the pattern of the chain, not the fingerprint of a single tool.

The full set of mitigations, including the registry change Microsoft published for YellowKey, is in my breakdown.

That was the technical half. The other half is why this happened at all.

The researcher’s version is on his blog, and he tells it plainly. He says he asked Microsoft to communicate with him and was refused, that he was humiliated and insulted in front of people. He says Microsoft deleted the account he had used to report bugs to them, that work he did report got credited to other researchers instead of him, and that he was paid nothing for properly reporting flaws. He says he has proof for every word of it but cannot release that proof yet. And then he set a date, July 14, which is Microsoft’s next monthly patch day, and warned that something is coming that day that he says will shatter their bones. That is his account, in his own words.

Microsoft’s version is just as clear and points the other way. In an official post from its Security Response Center on May 27, the company said none of these six flaws were reported to it privately before they went public, that the disclosures put customers at unnecessary risk, and that releasing attack code for unpatched flaws is never justifiable and has real-world consequences. Microsoft also said its Digital Crimes Unit will keep bringing cases against people who do this and against those who help them, coordinating with law enforcement. From Microsoft’s side, there was no broken agreement because there was no coordination at all, and customers are the ones paying for that.

And that part is not just talk. The whole reason coordinated disclosure exists is to close the window between a flaw becoming known and a fix being ready, because in that window anyone can grab the code. That is exactly what happened here. Within days of the exploits going public, attackers were dropping them onto a victim’s network, a company that had nothing to do with the fight between this researcher and Microsoft. The people who pay for a public dump are rarely the company it was aimed at. They are the ordinary organisations whose machines get hit while the dust is still settling.

So one side says the deal was broken and the other says there was never a deal. Both of them are saying it on the record, and both cannot be true at once. From the outside, there is no way to know which one is lying.

What pushed this from a private feud into a bigger fight is that Microsoft’s own past works against it. The company has hired people who did the exact thing it now calls criminal, including a well-known researcher who dumped Windows zero-days in public out of frustration and then got a job there. So if publishing this kind of code is suddenly a crime, that is a hard thing to say with a straight face when your own staff list is full of people who did it.

Katie Moussouris built Microsoft’s bug bounty programme. She caught something small but telling in how Microsoft talks about this. They used to say coordinated disclosure, a neutral phrase, and she was the one who pushed them off the older term, responsible disclosure, because that word quietly makes the company’s wishes the right thing to do and the researcher the difficult one.

Microsoft has now gone back to that older framing, and added the mention of its crime unit, which she described as vaguely threatening. Her worry is the chilling effect, the next honest researcher who finds a serious bug and now wonders whether reporting it will get them threatened instead of paid, and decides to just stay quiet. Her plainest point was that the bugs belong to Microsoft. They wrote the code, so they own the risk to their customers, no matter how the disclosure happened.

To be fair to Microsoft, this is not a company that never pays. It handed out more than 17 million dollars in bug bounties last year and works with hundreds of researchers the normal way. That is what makes this case stick out. It looks like one relationship that went badly wrong, not how the programme usually runs. Why it went wrong is the part nobody on the outside can settle.

There is one more development worth watching. After all the noise, other researchers started reaching out to Nightmare-Eclipse and handing him vulnerabilities for free. One of them is a respected name in Windows security, the person behind the HiveNightmare flaw from a few years back. By his own account, that person did most of the work on a new way to break BitLocker, and the two of them are now sitting on it together. This started with one researcher and is turning into a group, and Microsoft’s response is part of what pulled the others in.

There is also the timing. Back in February, Microsoft said its researcher leaderboard would change in July 2026, switching from a points system to one based on the money actually paid out, so the rankings match real rewards. July. The same month as the threat. And so you have to wonder whether that fix, meant to make researchers feel they get a fairer deal, came too late for the ones who already feel burned.

Two things are true here at once, and the bounty reform does not change either one. He found six serious holes in Windows and, by his own account, reported them the right way. What he got back, and this is on the public record, was a deleted reporting account, his credit handed to other people, no money, and then a company that owns GitHub using GitHub to wipe him while waving its crime unit at him. A company worth hundreds of billions, with hundreds of thousands of staff, against one researcher who walked away with nothing. That is the one side. The other side is just as real. Dumping working attack code for unpatched flaws hurt people who had nothing to do with this fight, and the code did get grabbed and used because it was sitting there for the taking. Both of those things happened.

My question in this whole story is, who are the real criminals here? I have asked myself what I would have done in Dead Eclipse’s shoes, and honestly, I think I would have done the same.

I also think there should be far more conversation about the work of bug hunters, the people who find the holes wherever they happen to be. They are not there to break anything. They are there to make the internet, and the world, a little safer. And they get treated as an afterthought, and badly underpaid. They carry the risk, they do the hard part, they hand it over, and the reward is a thank you if they are lucky, a lawsuit if they are not.

It has happened so often, yes, even to me, that a company was saved from ruin by one of these reports. Company after company, they take the report, they quietly fix it, and it often ends the same way. The hacker is left with zero, and sometimes even branded a criminal, while the company and its expensive lawyers walk free.

Microsoft is not unique here, not by a long way. This happens everywhere, and that is my whole point. That is exactly why we need to start talking about it out loud.

This is what penetration testing looks like, getting in, escalating your access, moving through a network, and understanding a system better than the people who run it. It is also where bug hunters start, learning to find the holes before anyone else does. That is exactly what I teach in my ethical hacking course, from your first day with zero experience to thinking and working like a real hacker:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: Dead Eclipse | Microsoft MSRC | NVD CVE-2026-41091