Nightmare-Eclipse: Six Windows Zero-Days and a Very Public Grudge

A security researcher with a personal grudge against Microsoft has released six Windows zero-day exploits in six weeks — and confirmed that at least one is being actively exploited in the wild. Here's what's confirmed, what to patch immediately, and a behavioural hunting query to help you detect exploitation before a signature exists.

What Happened

Beginning in April 2026, a researcher operating under the aliases Nightmare-Eclipse (also seen as Chaotic Eclipse and Dead Eclipse) began publicly releasing working proof-of-concept exploits for Windows and Microsoft Defender vulnerabilities. The researcher has publicly stated the disclosures are driven by frustration with Microsoft's vulnerability reporting process — including claims of mishandled reports and disputed bounty payments. Regardless of motive, six vulnerabilities were released over six weeks, several with working exploit code, and at least one has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog.

The Six Vulnerabilities

Why This Matters: The Attack Chain

Individually, several of these look like isolated bugs. Chained together, they form a genuinely dangerous attack path: BlueHammer, RedSun, or MiniPlasma provide privilege escalation to SYSTEM, and UnDefend then quietly degrades Microsoft Defender's ability to detect what happens next. An attacker doesn't need all six — escalating privileges and blinding endpoint detection in the same intrusion is enough to operate with significantly reduced risk of being caught. Independent security vendors have already reported observing this tooling used in real-world intrusions, not just in lab proof-of-concept demonstrations. If this kind of activity did make it into your environment, a structured incident response process is what stops it from becoming a full breach.

Platform and Vendor Response

The disclosures triggered fallout beyond the technical details. GitHub removed the researcher's account around 23 May, and GitLab followed around 26–27 May, both citing policies against hosting weaponised exploit code being used in active intrusions. Reports also indicate Microsoft threatened legal action against the researcher, which drew significant criticism from the security community over the handling of the disclosure dispute. The researcher has reportedly threatened to release remote code execution (RCE) class vulnerabilities if the pressure continues.

Public Advisories & Tracking

We're deliberately not linking to any proof-of-concept exploit code in this post — the accounts hosting it were removed from GitHub and GitLab specifically because the tooling was being used in live intrusions. For accurate, official tracking, use these public advisory sources instead:

• CISA Known Exploited Vulnerabilities Catalog — cisa.gov/known-exploited-vulnerabilities-catalog — check for CVE-2026-33825 and any newly added entries as YellowKey, GreenPlasma, and MiniPlasma are formally assigned.
• NVD / CVE.org — nvd.nist.gov/vuln/search — search CVE-2026-33825, CVE-2026-41091, and CVE-2026-45498 for full technical detail and CVSS scoring.
• Microsoft Security Response Center — msrc.microsoft.com/update-guide — the authoritative source for patch availability and guidance as it's issued.
• GitHub Security Advisories — github.com/advisories — official GHSA entries are a reliable way to track confirmed, vetted advisories rather than unverified researcher claims.

What You Should Do Now

• Confirm the April and May patches are installed. If your Windows estate hasn't applied the 14 April Patch Tuesday update or the 21 May out-of-band update, treat this as urgent — CVE-2026-33825 is in CISA's KEV catalog, meaning it's confirmed under active exploitation.
• Watch for patches on the remaining three. YellowKey, GreenPlasma, and MiniPlasma don't have official CVEs or patches as of this writing. Subscribe to MSRC's update guide and apply fixes the moment they're released.
• Apply compensating controls where no patch exists. For MiniPlasma specifically, restrict which accounts and processes can interact with the Cloud Filter driver where operationally possible, and increase monitoring around unexpected privilege escalation on endpoints — the kind of baseline our security hardening engagements are built to establish.
• Don't rely on patching alone. With active zero-days in play, behavioural detection is your best defence for the gap between disclosure and patch.

Behavioural Threat Hunting: Detecting the Attack Chain

Because several of these vulnerabilities are still unpatched, signature-based detection won't catch every variant. What's detectable is the behaviour — a low-privilege process suddenly spawning a SYSTEM-level process, followed shortly after by an attempt to tamper with Microsoft Defender. That sequence is exactly the BlueHammer/RedSun-then-UnDefend pattern, and it's a strong indicator regardless of which specific exploit was used.

// Hunts for a low-integrity process escalating to SYSTEM,
// followed within 30 minutes by a Defender tamper attempt.
// This behavioural pattern matches the Nightmare-Eclipse chain
// (BlueHammer/RedSun/MiniPlasma -> UnDefend) regardless of variant.
DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessIntegrityLevel in ("Medium", "Low")
| where ProcessIntegrityLevel == "System"
| project EscalationTime = Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, FileName, ProcessCommandLine
| join kind=inner (
    DeviceEvents
    | where Timestamp > ago(1d)
    | where ActionType in ("AntivirusDisabled", "TamperingAttempt",
                          "AntivirusScanCancelled")
        or ProcessCommandLine has_any ("Set-MpPreference",
              "-DisableRealtimeMonitoring", "-DisableIOAVProtection")
    | project TamperTime = Timestamp, DeviceName, ActionType, ProcessCommandLine
) on DeviceName
| where TamperTime between (EscalationTime .. (EscalationTime + 30m))
| project DeviceName, AccountName, EscalationTime, InitiatingProcessFileName,
          FileName, TamperTime, ActionType, ProcessCommandLine
| order by EscalationTime desc

This is a starting template, not a drop-in production rule — tune the time window and field names to your EDR schema, and validate against your own baseline before enabling as an alert.

How Red Team Intelligence Can Help

Campaigns like this are exactly why patch management and behavioural detection have to work together. We help organisations close the gap: vulnerability management to make sure emergency patches like the 21 May out-of-band release actually get applied on time, and threat hunting rule development to build detections like the one above, tuned to your specific SIEM or EDR platform. Get in touch if you need help assessing your exposure.