Nightmare-Eclipse is a single researcher operating under a rotating set of handles. Public reporting attributes Chaotic Eclipse, INFINITE NIGHTMARE, MSNightmare, and Nightmare-Eclipse to the same person, and prior Howler Cell coverage recorded Dead Eclipse as well. The GitHub account is MSNightmare, with parallel mirrors on the self-hosted Git servers at git.projectnightcrawler[.]dev and git.churchofmalware[.]org.
The pattern holds across every release. This researcher does not hunt memory-safety bugs. Each release is a design-level abuse of trusted functionality, chained out of legitimate operating system features, and published without coordination or advance notice to the vendor. The motivation reads as grievance over Microsoft’s handling of bug bounties and vulnerability disclosure rather than financial gain. Microsoft has publicly warned of legal action against people engaged in malicious activity causing real harm, which has been widely read as pressure directed at this researcher.
ShieldCrash is the fifteenth tool from this cluster since April 2026, a span of roughly twenty-three weeks. Named releases to date include UnDefend, RedSun, BlueHammer, YellowKey, GreenPlasma, MiniPlasma, RoguePlanet, LegacyHive, GreatXML, ShieldBreak, the four-vendor batch covering CrowdStrike, NVIDIA, Avast, and Kaspersky, and now ShieldCrash. The targeting concentrates on components that vendors position as security guarantees. Microsoft Defender is the most frequent target in the set.
This is the eighth report in Howler Cell’s ongoing coverage of the Nightmare-Eclipse cluster. Prior installments: BlueHammer, RedSun, RoguePlanet, GreatXML, LegacyHive, ShieldBreak, the four-vendor batch.
For defenders, the significance is not any single proof of concept. It is a public actor producing design-level abuse chains against the security control itself, faster than the vendor closes them. Endpoint protection is the control most security programs treat as a floor. When that floor becomes the attack surface, detection has to come from somewhere other than the product under attack. That is the case for threat hunting against host telemetry the endpoint agent does not generate, and for defense in depth that does not assume the agent is trustworthy during an incident.
Within a day of publishing ShieldBreak, the researcher posted an update under the INFINITE NIGHTMARE handle on the account @MSNightmare2000. The post makes three moves. It reclassifies ShieldCrash as a full privilege escalation rather than an arbitrary file read. It states that the SAM database can be obtained easily. It invites the community to build a full exploit before the researcher does, and points at BlueHammer source code as the hint.
Figure 1: The researcher’s follow-up post reclassifying ShieldCrash and inviting the community to complete it.
The reclassification does not describe a new capability. An arbitrary file read running as SYSTEM is already a privilege escalation path once it can reach the SAM and SECURITY registry hives, because those hives hold local account password hashes. Extract the hashes, and local administrator access follows. The researcher is arguing about the consequence of the primitive already claimed rather than announcing a second exploit.
The BlueHammer pointer is specific, and it decodes. BlueHammer, CVE-2026-33825, was this researcher’s April 2026 Defender privilege escalation, and independent analysis at the time described it as a time-of-check to time-of-use race combined with path confusion. Its route to SYSTEM ran through access to the SAM database and the local password hashes inside it. Howler Cell’s own analysis of BlueHammer identified Volume Shadow Copy abuse against the Defender update process. Shadow copies are also the established route to a registry hive the operating system holds open, which matters because SAM cannot be opened directly while the system is running. Howler Cell has not confirmed which part of the BlueHammer code the researcher intends. The hint reads as an instruction to attach ShieldCrash’s read primitive to the post-read escalation path BlueHammer already published.
That construction is credible. It is also entirely dependent on the read primitive working, and the read primitive is the part Howler Cell could not reproduce. The claim now being made is specifically about SAM. The released code was pointed at that exact file, on an engine build carrying the CVE-2026-69414 fix, and it returned the exploit’s own copy of ntdll.dll. The same held for SECURITY and ELAM.
The invitation to the community is not new behavior for this actor, and the precedent is the reason it matters. BlueHammer shipped in April 2026 as an acknowledged buggy proof of concept, with the researcher declining to explain how it worked and telling readers to work it out themselves. Other researchers repaired it. Public reporting recorded a working version against fully patched Windows 10 and Windows 11, with conflicting accounts of whether it reached SYSTEM on Windows Server. CISA added CVE-2026-33825 to the Known Exploited Vulnerabilities catalog on April 23, 2026, and confirmed on June 30, 2026 that ransomware operators were exploiting it. BlueHammer, RedSun, and UnDefend have all been confirmed exploited in the wild.
Several questions about intent remain open and Howler Cell does not have answers to them.
Howler Cell is not going to guess at motive. The practical consequence does not depend on it. Whether the researcher holds the chain or the community assembles it, the BlueHammer sequence ran from a buggy public release to ransomware operations inside three months. Treating the invitation as theater is the wrong planning assumption.
Three Patches, Three Bypasses
RoguePlanet was disclosed in June 2026 and assigned CVE-2026-50656, an elevation of privilege flaw in the Microsoft Malware Protection Engine (mpengine.dll). Public analysis described the exploit as a race condition involving a virtual disk and improper link resolution. Microsoft patched it on July 8, 2026 through Malware Protection Engine version 1.1.26060.3008.
ShieldBreak followed on August 12, 2026, one day after that month’s Patch Tuesday. Microsoft assigned CVE-2026-69414 two days later and confirmed an elevation of privilege flaw in the same engine. ShieldBreak was assessed as a full bypass of the RoguePlanet fix, reaching the same outcome through a different mechanism. It hooked the Cloud Filter API during cloud-file hydration rather than racing a virtual disk. Both CVEs carry a CVSS score of 7.8. The researcher claimed a 100 percent success rate against Windows 11 25H2, including Canary channel builds, and Windows Server 2025.
ShieldCrash was published on September 8, 2026, hours after the September Patch Tuesday updates shipped, and claims to bypass the ShieldBreak fix. It stays inside the ShieldBreak technique family. Cloud Filter placeholders, hydration callbacks, and Object Manager namespace manipulation are all present. ShieldCrash is an iteration of a technique already proven to work rather than a new bug class. That is the main reason Howler Cell treats the underlying behavior as a live exploitation candidate even though the released code fails.
| Release | CVE | Published | Vendor status | Mechanism |
|---|---|---|---|---|
| RoguePlanet | CVE-2026-50656 | June 2026 | Patched July 8, 2026, in engine version 1.1.26060.3008 | Race condition against a virtual disk |
| ShieldBreak | CVE-2026-69414 | August 12, 2026 | Patched in September 2026 in engine version 1.1.26080.3 | Cloud Filter API hooking during hydration |
| ShieldCrash | Not assigned as of publication | September 8, 2026 | No advisory or mitigation published |
What ShieldCrash Claims
ShieldCrash targets a trust boundary violation in how Defender’s remediation pipeline resolves file paths when those paths traverse the NT Object Manager namespace and the Cloud Filter API’s hydration callbacks. The researcher states that Microsoft’s fix for CVE-2026-69414 closed several exploitation paths but left one condition reachable, and that the same underlying problem can still be triggered, in this case as a file read.
The primitive claimed in the README is read access rather than write access, and several outlets collapsed that distinction into general SYSTEM compromise. The researcher then widened the claim himself a day later, as covered above. The released code remains narrower than either version of the claim.
The proof of concept takes a target file path as a command-line argument, baits Defender into scanning a cloud-filter placeholder containing EICAR test content, manipulates the Object Manager namespace during remediation, and constructs a two-layer redirect. An NTFS junction points into the Object Manager namespace, and a symbolic link inside that namespace points at the target file. The intent is to make Defender’s SYSTEM-context remediation read the target file on the attacker’s behalf.
Intended Execution Chain
Figure 2 shows the chain as designed, with the point at which it stops in Howler Cell’s environment. Stages 1 through 3 and Stage 5 were observed. Stage 4, the privileged read, was not.
Figure 2: ShieldCrash intended execution chain and observed break point.
Technical Analysis
The target file path from the command line is converted to NT-native form. The process raises itself to the highest available priority class and thread priority.
A hidden working directory C:\ShieldCrash_<GUID> is created with an Everyone SID full-control ACL. A cloud sync provider named Flubber, GUID {B196E670-59C7-4D41-9637-C62D80541321}, is registered on it. A dehydrated placeholder named BERN is created and explicitly hydrated, which triggers the fetch-data callback and serves embedded EICAR content.
ntdll.dll is then copied from System32 into an NTFS alternate data stream at BERN:stream. This single detail decides how the final output has to be read. The stream the proof of concept eventually extracts already contains ntdll.dll before any exploitation attempt begins.
Figure 3: ntdll.dll copied into the BERN alternate data stream during setup.
Before the scan, two object directories and two symbolic links are constructed in the Object Manager namespace.
The shadow overlays the target, so any lookup of WD_SCAN in the shadow directory hits the shadow’s link first. The target’s link stays hidden until the shadow’s link is deleted.
A worker thread loads Defender’s internal client library, MpClient.dll, opens the RPC interface, and triggers a resource scan against the placeholder through the shadow directory.
Scan path: \\.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERN
Defender resolves the path through the shadow’s link, reads the EICAR content from the working directory, detects the threat, and enters the remediation pipeline.
Figure 4: Object Manager directory and symbolic link creation.
The main thread monitors C:\Windows recursively for new files, watching for Defender to create a remediation temp file in C:\Windows\TEMP. When the temp file appears, the exploit deletes the shadow’s WD_SCAN link. Resolution falls through to the target’s link, routing through \CLFS\. The CLFS driver creates a .BLF log file in the working directory and the exploit captures its filename.
The exploit then creates a new shadow link pointing to a second working directory, C:\ShieldCrash_<GUID>_2, creates that directory on disk, and attempts to delete the CLFS log.
This is where the chain stops. The delete fails with a sharing violation because Defender still holds the log file open. The working directory is therefore not empty, and the subsequent attempt to set a reparse point on it fails with Windows error 145, ERROR_DIR_NOT_EMPTY. A reparse point cannot be applied to a directory that still contains files. The published implementation does not wait for Defender to release the handle and does not retry once it does.
A file subsequently appears in the _2 directory. Whether that artifact was placed there by Defender following the redirected namespace or by normal remediation behavior is not distinguishable from the proof of concept output alone.
The BERN placeholder is renamed to %TEMP%\ShieldCrash_<GUID>.BERN2. Its alternate data stream travels with the rename and still holds the ntdll.dll copy from Stage 1. The sync root is disconnected.
The original working directory is reopened and two redirect structures are constructed. An Object Manager symbolic link at \BaseNamedObjects\Restricted\BERN:stream points to the NT-native path of the target file, for example \??\C:\Windows\System32\config\SAM. An NTFS mount point on the working directory targets \BaseNamedObjects\Restricted.
The intended resolution chain is that any access to C:\ShieldCrash_<GUID>\BERN:stream follows the junction into \BaseNamedObjects\Restricted, hits the symbolic link, and resolves to the target file. If Defender’s SYSTEM-context remediation traversed that chain, it would read the target file under its SYSTEM token.
Howler Cell’s reproduction does not confirm this resolution chain producing the claimed result. Because the reparse point could not be set at Stage 3, the junction that anchors the chain never becomes active.
Stage 5. Output
The exploit opens %TEMP%\ShieldCrash_<GUID>.BERN2:stream, memory-maps it, and copies the contents into an output file named <target_filename>.<GUID> alongside the exploit binary.
The stream being read at this step is the one populated in Stage 1. When the redirect at Stage 4 does not take effect, the extraction returns the ntdll.dll copy the proof of concept placed there itself. An output file is produced either way. That is what gives a failed run the appearance of a successful one.
Howler Cell Reproduction
Howler Cell compiled and executed the proof of concept in a controlled environment on the following configuration.
That engine build is the load-bearing detail. Microsoft shipped the fix for CVE-2026-69414 in Malware Protection Engine version 1.1.26080.3 and stated the fix requires no customer action and has no effect on systems where Defender is disabled. The test host ran exactly that build. The reproduction therefore exercises the patched configuration the researcher makes the claim against, which is what makes the result meaningful in either direction.
The exploit was run against three protected registry hives, SAM, SECURITY, and ELAM. Every run produced the same result.
All intermediate stages execute. The cloud provider registers, the placeholder hydrates, the Object Manager namespace constructs, Defender detects the EICAR content and enters remediation, the shadow link deletion fires, the CLFS log appears, and the second-directory bounce operates. An output file is produced on every run. The chain does not complete. The reparse point operation fails at Stage 3, so the privileged read at Stage 4 never occurs.
None of the output files contain the requested target. Every run produced an output file of exactly 2,505,480 bytes. That is the same length as ntdll.dll on the test host, which appears in the same directory listing in Figure 5 at the same size. The SAM hive is approximately 64 KB and begins with a regf registry hive header. SECURITY and ELAM are also small hives, and none of the three approaches 2.5 MB. Three targets of three different sizes produced three identically sized outputs, which is not possible if the output came from the targets.
The identification does not rest on file size. The SAM output file carries its own PE version resource and that resource names it. FileDescription reads NT Layer DLL. InternalName and OriginalFilename both read ntdll.dll. FileVersion reads 10.0.26100.1591 and CompanyName reads Microsoft Corporation. The file hashes to MD5 6E39C98CB92BE9764588E666D25DE801 and SHA-1 7E36D6A6D26BE8C6382E068FAD212CD851913BB9.
Source review explains why that is the expected result. The proof of concept copies ntdll.dll into BERN:stream before Defender is engaged, carries that stream through the rename at Stage 4, and reads the same stream in its extraction step at Stage 5. An output file containing ntdll.dll is what a failed run produces. It is not evidence of a successful one.
Figure 5: Howler Cell reproduction. Three differently sized targets produced identically sized output, and the version resource identifies it as ntdll.dll.
The researcher’s published screenshot shows the proof of concept targeting C:\Windows\System32\config\ELAM. The ELAM hive is a small Early Launch Antimalware registry hive, typically 28 to 56 KB. The output file in the screenshot is 2,522,080 bytes, approximately 2.46 MB. The figure differs from the 2,505,480 bytes Howler Cell observed because ntdll.dll differs in size between Windows builds. Both figures are ntdll-sized and neither is hive-sized. The researcher’s own evidence shows the same pattern Howler Cell reproduced.
Figure 6: Researcher’s published screenshot, showing the same file size discrepancy.
Instrumentation of the run records the failure directly. The debug output in Figure 7 captures the reparse point operation returning error 145 and the sharing violation on the CLFS log that causes it.
Figure 7: Debug output. The chain terminates before the privileged read.
The published proof of concept does not deliver the claimed arbitrary file read in our environment. That is a statement about the code as released. It is not a statement about the vulnerability, and two things follow from it that point in opposite directions.
The failure is a housekeeping problem, not a security control. Nothing in Defender stopped the redirect. A log file left open by Defender’s own remediation blocked a reparse point operation, and the exploit did not wait for the handle to close. The defect is in the implementation rather than the concept, and the researcher has already stated the release is a skeleton pending rework.
The technique family is already proven. ShieldBreak established that Cloud Filter hydration callbacks can be used to steer Defender’s remediation across a security boundary, and Microsoft assigned it a CVE and shipped a fix. ShieldCrash reaches the same pipeline through the same class of manipulation.
What Howler Cell has not established matters just as much. The reproduction does not show that the underlying Defender behavior is safe, and it does not show that the September 2026 fix fully closed the issue. The absence of a working proof of concept is not evidence of a closed vulnerability.
The reclassification does not change the assessment, because it rests on the same primitive. A full privilege escalation built on an arbitrary SYSTEM file read requires the read to work. Howler Cell tested the released code against SAM, the file the claim now names, and against SECURITY and ELAM, on an engine build carrying the CVE-2026-69414 fix. The read did not occur in any run.
Howler Cell assesses with high confidence that the public ShieldCrash code does not perform an arbitrary file read as released, and with moderate confidence that the underlying pipeline remains a viable exploitation target pending a corrected implementation. Research is ongoing and this assessment will be revised if that changes.
Coverage for this cluster starts before any host telemetry. Nightmare-Eclipse publishes without coordination and mirrors releases across self-hosted Git servers and a blog. Monitoring those channels has consistently given days of lead time over vendor advisories in this lineage, which is time that goes into hunt hypotheses rather than patch waiting.
On the host, the detection opportunities below are keyed to the lettered break points in Figure 2. None of them depend on Defender detecting the exploit, which is the point. The product under attack is the product most environments rely on for endpoint detection.
| Ref | Chain stage | Observable | Detection or hunt opportunity |
|---|---|---|---|
| A | Stage 1. Setup |
|
|
| B | Stage 2. Product Engaged |
|
|
| C | Stage 3. Path Redirect |
|
|
| D | Stage 4. Privileged Read |
|
|
| E | Stage 5. Output |
|
|
Two of these carry the most signal today. MpClient.dll loading outside the Defender process tree and CfRegisterSyncRoot from unrecognized software are both rare enough in a typical estate to alert on rather than hunt, and both fire early in the chain, well before the privileged read is attempted. Cloud Filter registration monitoring also applies to ShieldBreak, so environments that built coverage for the August release already have part of this.
Confirm the Malware Protection Engine version across the estate rather than assuming a Windows update covered it. Defender engine updates ship on their own channel. The RoguePlanet fix was delivered as engine version 1.1.26060.3008 and the ShieldBreak fix as engine version 1.1.26080.3, so 1.1.26080.3 is the current floor for this lineage. Vulnerability management should be reporting engine version, not only operating system patch level. Get-MpComputerStatus returns AMEngineVersion and AMProductVersion directly.
Restrict untrusted local code execution. Every release in this lineage is a local privilege escalation or a local file read, which requires an attacker to already hold a foothold on the host. Application control and script control reduce the population of attackers who can reach the vulnerable path at all.
Keep the behavioral detection coverage established for prior Defender-targeting tools in this cluster. Rows A through C of Table 2 apply across the Cloud Filter releases in this lineage. Rows D and E are specific to the ShieldCrash redirect and output steps. None of them depend on the vulnerability status of any single release.
Do not read the absence of a Microsoft advisory as resolution. As of publication, Microsoft has not issued an advisory or mitigation specific to ShieldCrash and has not commented publicly. The vendor pattern in this lineage has been to acknowledge and assign a CVE within days of public release.
Assume a follow-up, and plan for the community to supply it. Fifteen tools in twenty-three weeks, with two consecutive patch bypasses in the same component, is a cadence that does not support treating a broken proof of concept as the end of the matter. BlueHammer is the precedent to plan against. It was published buggy, repaired by others, and reached the CISA Known Exploited Vulnerabilities catalog within three weeks and ransomware operations within three months.
ShieldCrash claims that Microsoft’s September 2026 fix for CVE-2026-69414, shipped as Malware Protection Engine version 1.1.26080.3, left residual attack surface in the Defender remediation pipeline. It chains two redirection layers, an NTFS mount point into the Object Manager namespace followed by an object symbolic link, where earlier releases in this lineage used single-layer junction abuse.
The claimed arbitrary file read as SYSTEM is not functional in the published code. The output in both Howler Cell’s reproduction and the researcher’s own published screenshot is ntdll.dll, placed there by the exploit’s own setup rather than read from the target. Because the alternate data stream is populated before remediation begins, a failed run produces an output file that looks like a successful one.
Howler Cell has not confirmed the claimed primitive and has not established that the technique is non-exploitable. What the reproduction identifies is a strong exploitation candidate whose public implementation fails on an open file handle rather than on a security boundary.
The researcher describes the release as a skeleton and states intent to rework it. The behavioral detections against Cloud Filter registration and MpClient.dll loading remain the primary defensive controls whether or not the underlying vulnerability is open.
Cyderes Howler Cell is tracking MSNightmare’s activity across this cluster. Findings will be updated as the situation develops.
These are artifacts of the proof of concept running in a controlled environment, not adversary indicators.
These are researcher publication and distribution points, not adversary infrastructure.