Nightmare Eclipse is associated with Abdelhamid Naceri, a vulnerability researcher whose Windows security work predates the 2026 releases by several years. His earlier research focused heavily on privilege boundaries and trusted Windows components, a technical theme that continues across several of his newer proof-of-concept exploits.
Naceri publishes his proof-of-concept exploits through the MSNightmare GitHub account. His releases examine weaknesses in Microsoft Defender, Windows recovery mechanisms, and third-party endpoint security products.
Figure 1. The MSNightmare GitHub profile and pinned repositories associated with the Nightmare Eclipse research stream.
Figure 2. Kaspersky’s acknowledgement linking Abdelhamid Naceri with the halove23 handle.
Figure 3. The halove23 HackerOne profile showing older resolved reports and the displayed researcher identity.
Earlier disclosure records connect Naceri with the halove23 handle and show that his vulnerability research predates the Nightmare Eclipse releases. Vendor acknowledgements and older resolved reports involving Malwarebytes, Elastic, and Kaspersky place his work within established disclosure programs before 2026.
September 2024: The Initial Meeting and Proposed Separation
In a thread published on September 13, 2026, Naceri said he had been working in Microsoft Security Response Center Vulnerabilities and Mitigations (MSRC V&M) when an unexpected meeting with Tom Gallagher and an HR representative took place in September 2024. According to his account, he was told that he had harmed Microsoft’s customers but was not given the incident details he requested.
A September 20, 2024 email attributed to Gallagher refers to a potential security breach, concerns about vulnerability information being shared with external parties, and a resulting loss of trust. It also proposes a mutual separation. The email documents the allegation communicated to Naceri without identifying the information involved or establishing that a disclosure occurred.
Naceri said he sought an explanation from MSRC leadership and rejected several separation proposals, including an eventual offer combining financial compensation and outplacement support. He described his priorities as understanding the dismissal decision, remaining in Germany, and challenging his treatment by the company.
March 2025: The Written Termination Notice
The German-language letter dated March 3, 2025 gives notice of termination under the heading Ordentliche Kündigung and specifies June 30, 2025 as the calculated end of employment. It also releases Naceri from work immediately with continued pay, accounting for outstanding leave and time-off entitlements.
The September 2024 meeting, March 2025 written notice, and June 2025 contractual end date are distinct events. That distinction matters when interpreting his later claim of continued internal access. The letter requests the return of company property and business material but does not describe the alleged security incident.
Figure 4. The redacted letter dated March 3, 2025, specifying June 30, 2025 as the calculated termination date and immediate release from work with continued pay.
The Court Dispute and Naceri’s Stated Motivation
Naceri said he challenged the dismissal at the Cologne Labour Court. His account describes Microsoft raising questions about his authorization to work in Germany and later alleging that he had made threats, which he denied. He maintained that supplementary residence documentation authorized his employment and said the court accepted it.
By September 2026, he described the proceedings as having ended with the dismissal remaining in effect and little financial recovery. A complete judgment was not available in the reviewed material, leaving the court’s reasoning unverified.
He also alleged that he had been threatened with blacklisting and an adverse employment reference. Naceri presents the dispute and its personal and professional consequences as the motivation behind his later public disclosures and criticism of Microsoft. His research record and subsequent releases require separate technical assessment.
September 2026: The Claim That Internal Access Continued
In a September 14 follow-up, Naceri said his Microsoft work account and access to the MSRC database, including source code, remained available for two months after he was told he was being dismissed. He did not place that period after the June 30, 2025 contractual end date. He also said he did nothing beyond logging in and did not retrieve or modify internal data.
Figure 5. Naceri’s September 14, 2026 posts alleging continued internal access and stating that he did nothing beyond logging in.
The allegation raises an access-control question during the separation process. Establishing the scope and use of that access would require authentication records, repository logs, and the relevant employment timeline. The posts alone provide no evidence of internal source-code retrieval or a connection to a particular 2026 exploit.
CVE-2021-26426, credited to Naceri as halov, concerned Windows User Profile Service handling of directory junctions. A local attacker could influence a privileged deletion operation and use the resulting condition to reach SYSTEM-level impact. The advisory records a May 2021 report to the vendor and an August 2021 public disclosure.
Figure 6. ZDI-21-965, crediting Naceri for CVE-2021-26426 in Windows User Profile Service directory-junction handling.
CVE-2022-21838 provides a second example. It involved link following in the SilentCleanup scheduled task, again allowing a local, lower-privileged user to influence a privileged filesystem operation. Its advisory records a September 2021 report and January 2022 public disclosure.
Figure 7. ZDI-22-049, documenting the SilentCleanup link-following vulnerability CVE-2022-21838.
Related research shows how arbitrary file deletion can be combined with Windows Installer rollback behavior to achieve privilege escalation. The same distinction matters in the later releases: a protected read, delete, or write may be one stage in a broader elevation chain.
A recurring theme across Naceri’s research is the abuse of trusted components that operate with higher privileges on files or state influenced by a lower-privileged user. The 2026 releases apply the same general idea to security scanning, remediation, recovery, profile loading, and update workflows.
The early public cluster included BlueHammer, RedSun, and UnDefend. By May 27, Microsoft had publicly identified six named releases those three, YellowKey, GreenPlasma, and MiniPlasma as vulnerabilities that had not been shared with it before publication. Its statement emphasized coordinated vulnerability disclosure and the risk created when exploit information is available before customers can deploy fixes.
Period | Releases / milestone | Security relevance |
|---|---|---|
April–May 2026 | BlueHammer, RedSun, UnDefend; Microsoft later names YellowKey, GreenPlasma, MiniPlasma | Early disclosure cluster; distinct elevation and protection-disruption paths. |
June 2026 | RoguePlanet; GreatXML | Defender race condition and a separate recovery-state technique. |
July 2026 | LegacyHive | User Profile Service hive loading with account prerequisites. |
August 2026 | ShieldBreak | Published bypass of the RoguePlanet remediation. |
Late August–September 2026 | HardBreacher, FalconFlank, PrettyPrague, GreenSection | Expansion to Kaspersky, CrowdStrike, Avast, and NVIDIA components. |
September 2026 | ShieldCrash; BigDiskBuster | Protected-file read after further remediation; Defender update disruption. |
Table 1. Timeline of Nightmare Eclipse disclosures and their primary security relevance.
The release history shows repeated work on Defender after remediation and expansion into other privileged endpoint components. Tracking the affected workflow, CVE, and component version is therefore more useful than a product-level “patched” status.
ThreatMon’s Cyber Threat Intelligence helps teams follow emerging exploit and vulnerability developments. Attack Surface Intelligence adds context on external assets and known exposures; internal endpoint inventories establish whether the affected components and configurations are deployed.
BlueHammer and RedSun Target Different Privileged Operations
BlueHammer uses Defender activity to access sensitive registry data and support local privilege escalation. Microsoft tracks it as CVE-2026-33825 and addressed it through a Defender platform update.
RedSun instead targets a restoration workflow to place attacker-controlled content in a protected location before privileged execution. It is tracked as CVE-2026-41091. These different operations call for monitoring both protected-data access and protected-file changes.
RoguePlanet: A Race Condition With a Demonstrated SYSTEM Outcome
RoguePlanet is a Defender race-condition exploit that can produce a SYSTEM shell when successful. The author reported intermittent reliability and testing on Windows 10 and Windows 11 with June 2026 updates. The public implementation’s disk-image mounting method limits its direct use on Windows Server, while the author claims the underlying issue also affects server systems.
Figure 9. The RoguePlanet README and the author’s terminal demonstration of SYSTEM execution.
RoguePlanet is associated with CVE-2026-50656. Assess the affected component version and test conditions: a failed attempt does not resolve exposure to a timing-dependent vulnerability.
ShieldBreak: A Bypass of the RoguePlanet Remediation
ShieldBreak bypasses the remediation introduced for RoguePlanet and targets the same broader Defender workflow through a revised technique. Its README names CVE-2026-50656 as the earlier issue and describes testing on newer Windows releases, including Windows Server 2025. The published proof of concept reports a SYSTEM-level outcome under the author’s test conditions.
Figure 10. ShieldBreak’s README identifying the RoguePlanet remediation as its target, alongside the author’s SYSTEM-shell demonstration.
The later issue is tracked as CVE-2026-69414. Organizations that remediated RoguePlanet therefore still need to assess ShieldBreak separately against the relevant Defender engine version.
ShieldCrash: Protected-File Access After a Further Fix
ShieldCrash refers to the ShieldBreak fix and CVE-2026-69414, then describes a remaining path on systems with September updates. ShieldCrash provides arbitrary protected-file read access with SYSTEM privileges under the author’s tested conditions. CVE-2026-69414 identifies the preceding ShieldBreak issue; it should not automatically be reassigned to ShieldCrash as a newly confirmed CVE.
Figure 11. ShieldCrash’s README and demonstration of arbitrary file reading as SYSTEM after the ShieldBreak remediation.
Protected-file access can expose credentials or other sensitive data. Record ShieldCrash’s demonstrated read capability separately from arbitrary code execution when assessing its impact.
Which Defender Components Need Separate Remediation Checks?
Microsoft’s advisory data distinguishes platform fixes from engine fixes. The table lists historical first fixed versions; deployment should follow current supported vendor updates and guidance for subsequent bypasses.
Release | Microsoft CVE record | Component | First fixed version |
|---|---|---|---|
BlueHammer | Platform | 4.18.26030.3011 | |
RedSun | Engine | 1.1.26040.8 | |
UnDefend | Platform | 4.18.26040.7 | |
RoguePlanet | Engine | 1.1.26060.3008 | |
ShieldBreak | Engine | 1.1.26080.3 |
Table 2. Microsoft Defender remediation milestones for Nightmare Eclipse-related vulnerabilities.
At the research cut-off, Microsoft marked exploitation as detected for RedSun and UnDefend, and not detected for BlueHammer, RoguePlanet, and ShieldBreak. Record those vendor assessments separately from incident observations, including attempted tool execution.
GreatXML examines access to BitLocker-protected data through Windows Recovery Environment and state associated with Microsoft Defender Offline scanning. The README distinguishes an environment where the relevant recovery state already exists from one where it first needs to be created. Exposure therefore depends on both local access and the system’s recovery configuration.
Figure 12. GreatXML’s README describing recovery-state prerequisites involving WinRE and Defender Offline.
LegacyHive targets User Profile Service hive loading. Its public PoC requires another standard user’s credentials and a third username. Naceri also claims a less restricted private version, but that capability is not demonstrated by the public PoC. Under the published prerequisites, the technique demonstrates access to another user’s registry hive through the profile-loading workflow.
Figure 13. LegacyHive’s README and registry view, including the additional account prerequisites of the public PoC.
These prerequisites affect prioritization. Shared workstations with usable accounts and accessible recovery paths have different exposure from tightly controlled single-user devices. Inventory the required features and security state alongside operating-system and agent versions.
HardBreacher and Kaspersky Endpoint Security
HardBreacher targets Kaspersky Endpoint Security for Windows and was tested by the author against version 14.0.0.504 on Windows 11 25H2. The PoC is described as unreliable and interferes with protected-file handling and product functionality. Kaspersky later addressed the issue through antivirus database updates released on August 30, 2026 or later for Endpoint Security versions 14.0 and 14.1.
FalconFlank and Configuration-Dependent Remediation
FalconFlank targets a CrowdStrike Falcon workflow associated with Office macro removal. Its README specifies configuration assumptions, including that the relevant macro-removal function is enabled, and acknowledges that prevention can block the demonstration. The author reports a SYSTEM-level result under those stated test conditions.
FalconFlank’s applicability depends on deployed policy and prevention settings. Validate exposure with the organization’s existing safeguards enabled.
PrettyPrague and GreenSection Broaden the Target Set
PrettyPrague explores Avast Sandbox behavior and presents access to SAM data together with a SYSTEM-shell outcome in the author’s demonstration. The README speculates about applicability to other Gen Digital products; the Avast demonstration alone does not establish those additional products as affected.
GreenSection targets shared-memory handling in NVIDIA user-mode components and demonstrates an application crash. The author discusses broader cross-user exploitation, but that capability has not been demonstrated.
Across these products, security-sensitive components process files or state influenced by another user or process. Track each workflow, prerequisite, demonstrated outcome, and vendor fix separately.
BigDiskBuster targets the availability of Defender platform and security-intelligence updates. Its public source monitors update-related directories and attempts large temporary allocations during updates. Static inspection supports an assessment of targeted resource exhaustion around that workflow; the PoC was not executed for this article.
The allocation routine uses available volume space and creates temporary files with delete-on-close behavior. Monitoring covers Defender’s Platform and Definition Updates directories. Files may disappear after an update failure, leaving normal free-space readings when an analyst examines the host. Historical update events and storage telemetry are therefore important.
An endpoint agent can remain installed and running while its platform or security intelligence becomes stale. Security teams need visibility into update age, repeated failures, and abrupt storage pressure alongside agent status.
Correlate update failures with large temporary allocations and unfamiliar processes executing from user-writable locations. Storage pressure is meaningful in that context, rather than as a standalone indicator. The experimental implementation has not established reliable disruption across every Windows version.
Naceri’s research repeatedly targets privileged Windows and endpoint security components that process user-controlled files or state. RoguePlanet, ShieldBreak, and ShieldCrash demonstrate how subsequent releases can challenge earlier fixes while introducing different capabilities. Defenders should track the affected workflow, component version, and demonstrated impact across that sequence.
Most reviewed techniques require local execution, device access, or additional credentials. Their priority therefore depends on the organization’s configuration and whether an attacker already has the access needed to use them. The employment dispute provides Naceri’s stated motivation, but the reviewed evidence does not connect his releases to Microsoft source code or link him to the operators using his tools.
ThreatMon’s Cyber Threat Intelligence helps teams track these disclosures, remediation bypasses, and reported exploitation. Attack Surface Intelligence identifies relevant external exposures, while Dark Web Intelligence monitors exposed credentials, access offers, and organization-specific targeting. Correlating those findings with internal asset inventories and endpoint telemetry helps teams identify affected systems and investigate potential access paths.
Defensive Priorities for Windows and Endpoint Security Teams
1. Verify the Specific Component and Protection State
Track Windows builds, Defender platform and engine versions, security-intelligence age, and third-party sensor or database versions separately. Confirm remediation against vendor advisories and successful endpoint updates. Link subsequent bypasses to the affected workflow.
2. Investigate Local Exploit Attempts Even When They Fail
Investigate unexplained execution of these tools through the originating account, remote-access session, parent process, staging directory, and subsequent activity. Failed elevation or a removed payload does not establish that the intrusion was contained.
3. Detect the Privileged Operation Being Abused
Correlate sensitive hive access, protected-file writes, unexpected processes following security remediation, recovery-state changes, and update failures. Filenames and repository labels can support detection, but operators can change them.
4. Preserve Production Controls During Validation
Record required features, credentials, recovery state, and privileges before testing on isolated, authorized systems. Retain both successful and failed results. Evaluate production exposure with application control and endpoint prevention enabled.
5. Monitor Update Health and Retain Independent Visibility
Monitor persistent protection-update failures and increasing intelligence age alongside unusual storage consumption or local execution. Retain identity, VPN, network, and centralized host records independently of the endpoint protection product.
6. Verify Access Revocation During Offboarding
During employee departures, verify account status, active sessions, repository permissions, and access to vulnerability-management systems against the approved offboarding decision. Preserve audit logs to resolve later questions about access and data activity.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
