Microsoft patched three more Nightmare Eclipse zero-days on Tuesday, six in six weeks now. The story isn't the bugs, it's how fast a public PoC turns into a real attack.

THE BUGS AREN'T THE STORY. THE WINDOW IS.

It is tempting to read a wave like this as a list of vulnerabilities to patch and move on. That misses what actually changed. The defining feature of the Nightmare Eclipse campaign is not any single flaw. It is the speed at which a flaw goes from a post on a public code repository to a technique in a live intrusion. Researchers tracking the campaign saw attackers begin using the BlueHammer exploit within days of its release, then pick up the proof-of-concept code for RedSun and UnDefend almost immediately after those dropped, following the public exploits closely enough that there was little doubt where the playbook came from. The observed timing was stark: exploitation of BlueHammer was reported within days of disclosure, and attackers moved onto the RedSun and UnDefend proof-of-concepts within roughly a week of those going public. That is not a sophisticated adversary doing original research. That is a commodity crew reading the same page you could read, and acting on it faster than your change-control process can convene.

Hold that against how patching actually works. Most organizations patch on a monthly rhythm anchored to Patch Tuesday, and many add days or weeks of testing on top of that. When the interval between a public exploit and its use in attacks is measured in days, a monthly cycle is structurally too slow. The defender is not racing the researcher. The defender is racing every opportunistic crew that reads the same GitHub page. That race is already lost on timing alone, which means the strategy cannot be only "patch faster." It has to include "assume this will be used before you have patched, and make sure that is survivable."

THE WAVE, IN ORDER

Six named exploits over roughly six weeks, with a seventh now in the wild. The naming is theatrical on purpose, but the pattern underneath is consistent: each one sits on or near the endpoint trust boundary.

BlueHammer and RedSun escalate a standard user to SYSTEM through Microsoft Defender by different code paths. UnDefend does not escalate at all; it blocks Defender's definition updates and degrades its ability to detect anything new, which is its own kind of weapon. YellowKey bypasses BitLocker on TPM-only configurations through the recovery environment, a physical-access attack on stolen or seized devices. GreenPlasma escalates through the CTFMON text-input subsystem; the researcher noted it began as a remote code execution path before a May Defender update appears to have closed the remote angle, leaving local escalation. MiniPlasma is the most pointed: it reopens a Cloud Files driver flaw that Google Project Zero reported to Microsoft in 2020, arguing the original fix never truly held, and it elevates to SYSTEM on fully updated Windows 11. RoguePlanet, the seventh, spawns a SYSTEM command prompt and arrived without a patch.

WHY THIS SHOULD WORRY YOU MORE THAN AN RCE

Read the list again and notice what is missing. There is almost no remote code execution here, almost nothing that gets an attacker onto a machine from the outside. These are local privilege escalation and security-tool tampering flaws. On paper that sounds reassuring, since an attacker needs a foothold first. In practice it is the opposite of reassuring, because footholds are the cheap part of a modern intrusion. Stolen credentials, a phishing click, an exposed remote service, a commodity loader off a malicious npm package: initial access is a commodity. What separates a contained incident from a company-ending one is what happens in the minutes after that foothold.

That is exactly the ground this wave occupies. A bug that takes a standard user to SYSTEM, or quietly stops your endpoint sensor from updating, is not a footnote to an intrusion. It is the hinge the intrusion turns on. Escalate to SYSTEM and the attacker owns the host. Blind Defender with something like UnDefend and the activity that follows, credential theft, lateral movement, ransomware staging, happens without the alerts that were supposed to fire. Reporting on the campaign noted attackers chaining these Defender exploits toward ransomware, which is precisely the sequence you would expect: get in cheap, escalate with a public PoC, disable the watcher, then encrypt.

The defensive obsession with initial access, the perimeter, the RCE, the firewall, is understandable, but it leaves the most decisive phase of an intrusion under-defended. Nightmare Eclipse is a six-week reminder that the post-foothold path is where breaches are actually won and lost.

WHERE PATCH VELOCITY STOPS HELPING

None of this argues against patching. Apply Tuesday's fixes and verify the out-of-band Defender updates from May; the specifics are in the action list below. But be honest about what patching can and cannot do against a campaign shaped like this one. Patching is a trailing control. It closes a door after the exploit is public, often after it is already in use, and on a cadence slower than the exploitation it is meant to prevent. Against a researcher who will keep dropping new zero-days, RoguePlanet being the proof, on no schedule you control, "patch faster" is necessary and insufficient.

The question that actually moves your risk is not "are we patched against the six we know about." It is "if an attacker lands a foothold and reaches for SYSTEM with a brand-new public exploit we have not patched yet, do we see it, and can we contain it before they blind the sensor." That is a detection and architecture question. It is answered by tamper protection that resists the UnDefend playbook, by treating a sudden stop in EDR definition updates or a disabled sensor as a high-fidelity alert rather than noise, by tiered administration that limits what a single SYSTEM-on-one-box win actually unlocks, and by shrinking the time between a detected foothold and its containment. Those controls work against the seventh exploit and the eighth, the ones with no patch yet, in a way that patch velocity never can.

SUPPRESSION DIDN'T WORK EITHER

Microsoft's first instinct was to make the problem disappear. The proof-of-concept code was pulled from public repositories, and the company's early posture toward the researcher included the threat of legal action. After a wave of public backlash from the security community, Microsoft walked that back, saying it would involve law enforcement only when a researcher crosses a clear line rather than for disclosure itself. Whatever your view of the researcher's ethics, and dropping live exploits that get people compromised is a defensible thing to be angry about, the takedown approach did nothing to help defenders.

Here is why. Once an exploit is public even briefly, the people who needed it already have it. Opportunistic crews archive a useful PoC within hours of it appearing; that is the entire reason exploitation followed these releases by days. Removing the repository afterward mostly removes the reference material for defenders, blue teams, and detection engineers who were trying to understand and catch the technique. The attacker kept their copy. Suppression, like patching, is a trailing control, and it is slower than the copy-and-paste it is trying to outrun. You cannot unpublish something that has already been forked a thousand times.

The climate around this matters too. Microsoft itself has noted that vulnerability reporting volume has climbed over recent years, and that both its own engineers and the wider research community are increasingly using AI to find bugs. Read that trend forward. The supply of weaponizable flaws is rising and the time to turn one into a working exploit is falling, with or without any single grudge-holding researcher. Waves shaped like Nightmare Eclipse are going to get more frequent, not less. That is the structural argument for spending less energy on the fantasy of patching or suppressing your way ahead of every new zero-day, and more on the defenses that hold no matter which specific bug is trending this week. Those defenses live after the foothold, which is where this entire wave is aimed.

DETECTION: WATCH THE WATCHER

The tampering bugs leave a signal, if you are looking for it. The single highest-value detection against this wave is simple to state and often un-monitored: a security sensor that goes quiet, stops updating, or gets disabled is an incident until proven otherwise, not a maintenance blip.

 title: Defender disabled, stalled, or tamper-protection change 
 # UnDefend-style blinding and post-escalation tamper. Defensive signal only. 
logsource:
  product: windows
  service: windows-defender
detection:
  disabled_or_degraded:
    EventID:
      - 5001     # real-time protection disabled 
      - 5007     # configuration changed (tamper) 
      - 1151     # health/agent status degraded 
  stale_definitions:
    EventID: 2001    # signature update failed 
  condition: disabled_or_degraded or stale_definitions
level: high

WHAT TO DO