One Patch Behind: Nightmare-Eclipse's ShieldCrash and the Defender Bypass That Won't Stay Fixed

In our previous blog, we analyzed four proofs of concept (PoCs) from the leak persona Nightmare-Eclipse that targeted Kaspersky, Avast, NVIDIA, and CrowdStrike, respectively.

Nightmare-Eclipse has now returned to the product where that theme started. Immediately following Microsoft's September 2026 Patch Tuesday, the actor released ShieldCrash, a Windows Defender privilege-escalation bypass — and the third entry in a lineage we've been tracking since our coverage of ShieldBreak. ShieldCrash is Nightmare-Eclipse's follow-on to ShieldBreak (https://nvd.nist.gov/vuln/detail/cve-2026-69414), the Defender flaw Microsoft patched this September — which was itself a bypass of an earlier issue, RoguePlanet, patched back in July. Three PoCs, two patches, one underlying mechanism that has now survived both rounds of remediation.

According to the actor, the newly released PoC is a deliberately incomplete "skeleton," scoped to demonstrate an arbitrary file read as SYSTEM rather than a full write primitive. Our testing confirms that framing is accurate — but the artifacts left behind along the way are worth defenders' attention regardless of how limited the current release is.

ShieldCrash: A Skeleton with the Right Bones

We tested the released PoC across several fully patched Windows 11 and Windows Server builds, plus one deliberately out-of-date Windows 11 asset. Across every run, regardless of which target file we specified, the tool produced the same outcome: the file handed back to the calling user was always ntdll.dll. The console output showed the tool copying C:\Windows\System32\ntdll.dll into a Defender-managed shadow path before the "read" completed, and a subsequent hash of the returned file matched ntdll's hash — never the hash of the file we had asked for.

Figure 1. PoC output against a test target file: Defender-related object manager artifacts are created, ntdll.dll is copied into the shadow path, and the hash of the resulting readable file matches ntdll — not the file that was actually requested.

Since ntdll.dll is already world-readable on a standard Windows install, the practical result of our test runs was access to a file that attackers already have permission to read, not a genuine arbitrary-file-read primitive. That lines up with the actor's own description of this release as a skeleton rather than a finished exploit. It does not, however, mean that the PoC is inert: during one run we observed a live Defender detection fire, confirming that the tool engages Defender's real scanning path rather than a simulated or offline one.

Figure 2. A Defender detection fired against content staged inside the tool's scan path during testing, confirming that the PoC interacts with Defender's actual remediation/scan subsystem.

To rule out the possibility that our results were simply a byproduct of the target files we chose, we ran the PoC against three different targets (the SAM hive, ELAM, and a plain test file named Secret.txt) across three separate runs. All three produced output files whose SHA-256 hashes matched ntdll.dll on the endpoint, not the file we specified.

Figure 3. SHA256 hashes of the output files generated as a result of three separate runs against different targets (SAM, ELAM, and a test "Secret.txt" file) compared with the ntdll.dll file on the endpoint, all showing the same values.

Staging Artifacts Left on Disk

Across our test runs, we consistently observed three separate ShieldCrash_<GUID> directories created — two under C:\ and one in %TEMP%. In one run, the tool left behind a C:\ShieldCrash_<GUID> folder with Everyone: Full Control permissions, despite having been executed under a standard user account rather than SYSTEM. This artifact did not appear in every run and may depend on timing or environment state. When this “.blf” file appeared, it was always found as a completely empty file.

Figure 4. Leftover staging folder from one test run, showing an inherited Everyone: Full Control permission entry.

In a separate run, the process halted partway through execution and left behind both ShieldCrash_<GUID> folders under C:\, each populated with files. One folder contained a file named "BERN," the other a file with a randomly generated name — but the file hashes between the two matched. Both turned out to be archives containing bfsvc.exe, eicar.com, and mrkaspy.jpg.

Figure 5. During an incomplete run of ShieldCrash, the process left behind two folders in C:\ that have matching file hashes. The BERN archive is unzipped, showing several files including eicar.com.

Endpoint telemetry from these runs corroborated the filesystem observations. SentinelOne captured file system activity tied to the ShieldCrash_{GUID} directories in both C:\ and %TEMP%.

Figure 6. SentinelOne events showing file system activity related to ShieldCrash_{GUID} directories within C:\ and %TEMP%.

The Object-Manager Mechanism Underneath

Our testing did not reproduce the outcome we initially expected — the files returned by the PoC were ones a standard user could already read, but the underlying mechanism the tool relies on is still worth documenting closely, since it is the same class of technique that survived Microsoft's July and September patches. EDR telemetry showed a suspicious source mount point, C:\ShieldCrash_<GUID>, being created with a target of \BaseNamedObjects\Restricted — a pattern consistent with other recent Defender-targeting exploits we've tracked.

Figure 7. SentinelOne indicator event showing C:\ShieldCrash_<GUID> being mounted at "\BaseNamedObjects\Restricted".

From there, we observed a symlink created from \BaseNamedObjects\Restricted\BERN:stream to whatever target path had been set when launching the PoC — in this instance, C:\Windows\System32\config\ELAM.

Figure 8. SentinelOne events showing the symbolic link creation between BERN:stream to the test target "C:\Windows\System32\config\ELAM".

CrowdStrike telemetry captured the same symlink creation from a different vantage point, additionally recording the initial command line used to launch the test — a useful correlation point for defenders running multiple EDR platforms side by side.

Figure 9. An alternate view of the symbolic link creation from CrowdStrike, which also includes the initial commandline used to start the test.

One particularly interesting artifact surfaced on an out-of-date Windows 11 asset, tested under an administrator account. Process Monitor captured several events in which MsMpEng.exe (Defender's own engine process) performed a read operation directly against the ELAM target file in question. We did not observe this behavior on the fully updated assets in our test set, suggesting it may be tied to the specific patch level of that machine rather than being a universal characteristic of the PoC.

Figure 10. Process Monitor read events for MsMpEng.exe for ELAM, the specified target in this testing run. This test was run using an administrator account called "addy" and was performed on a Windows 11 asset that is purposefully left out of date.

Detection Opportunities

As with the PoCs covered in our previous analysis, the durable detection value in ShieldCrash comes from the behaviors and trust relationships it abuses rather than from any single hardcoded string. Folder names, GUIDs, and even the specific target file can change from release to release; the object-manager mount-and-symlink sequence against a Defender-managed path is harder for the actor to discard without rebuilding the technique from scratch.

Key Takeaways for Defenders

The current public release of ShieldCrash is, by the actor's own admission and by our testing, incomplete — in its released form, it does not deliver a working arbitrary-file-read primitive beyond files a standard user can already access. That should not be read as a reason to deprioritize it. The actor has explicitly flagged intent to rework this skeleton into a full SYSTEM-level primitive, and the pattern across ShieldBreak, RoguePlanet, and now ShieldCrash shows the same underlying object-manager/shadow-path mechanism surviving two consecutive rounds of Microsoft patching.

Organizations should treat the September patch as incomplete rather than closed. Detection engineering effort is better spent on the object-manager mount point and symlink behavior described above than on indicators specific to this particular release — folder names, GUIDs, and target files are trivial for the actor to change, while the underlying mechanism has proven far more durable. As with the PoCs in our previous coverage, the pattern holds: the deployment status of a patch, and the depth of behavioral detection built around the mechanism it addresses, matter as much as the patch's existence.