ShieldBreak: The Windows Zero-Day That Breaks Microsoft's Own RoguePlanet Fix

Key Findings

• Tenth tool in an escalating grudge match between the researcher and Microsoft that began in April 2026. This is the first time in the campaign that the researcher has circled back to defeat a patch built specifically to stop them.
• Full patch bypass for CVE-2026-50656 (RoguePlanet), patched by Microsoft on July 9, 2026, in Defender engine version 1.1.26060.3008. The PoC reports 100% success on Windows 11 25H2 and Windows Server 2025, up from RoguePlanet's inconsistent reliability. The researcher states Windows 10 and its server editions are also vulnerable, but the PoC does not currently target them.
• Local privilege escalation from standard user to NT AUTHORITY\SYSTEM. No kernel bug, no memory corruption, no admin rights required. Confirmed by Howler Cell on a fully patched Windows 11 Pro host.
• PoC published August 11, 2026 under the MSNightmare handle on GitHub with mirrors on git.projectnightcrawler[.]dev and git.churchofmalware[.]org. No coordinated disclosure, no CVE, no patch.
• ShieldBreak registers a fake cloud sync provider ("Flubber"), creates a placeholder file named "BERLIN" containing EICAR test content, and baits Defender into scanning via a path routed through the Object Manager shadow directory. During remediation, the exploit rearranges the namespace and uses restart hydration to switch the delivered content from the EICAR bait to the payload DLL. The final redirect lands the payload at C:\Windows\System32\phoneinfo.dll via a UNC loopback path (127.0.0.1\C$). The payload itself, Warden.dll, is new: RoguePlanet delivered a copy of its own binary, but ShieldBreak delivers a separate DLL.
• Defender signatures Exploit:Win32/NghtMrShldBrk.BB and Trojan:Win32/Bearfoos.B!ml flag the compiled sample only. Minor source changes defeat it. The behavioral chain remains undetected by static means.

Summary

By multiple independent accounts, the person behind ShieldBreak once worked inside Microsoft's own security organization. Today they are running one of the most public grudge matches in recent memory against their former employer, and Windows Defender is the battlefield.

The researcher, who goes by Nightmare-Eclipse, says Microsoft buried their bug reports, denied them credit, and cut off their access. Since April 2026, they have answered by publishing one unpatched Windows zero-day after another, mostly aimed at Defender, releasing each one without warning Microsoft first. Microsoft has spent months patching what it can.

In July, it landed what looked like a real win: an emergency, out-of-cycle patch that shut down RoguePlanet, one of the researcher's SYSTEM-level exploits. On August 11, the researcher answered back. ShieldBreak does not exploit a new bug. It walks straight through the patch Microsoft built specifically to close RoguePlanet, at a 100% success rate. This is the tenth tool in the campaign, and the first time the researcher has circled back to beat a patch built specifically to stop them.

The researcher published ShieldBreak under the MSNightmare handle on GitHub on August 11, 2026, with mirrors on git.projectnightcrawler[.]dev and git.churchofmalware[.]org. This is Howler Cell's sixth report on this cluster. Cyderes Howler Cell has tracked it since its first release, with prior coverage of BlueHammer, RedSun, RoguePlanet, GreatXML, and most recently LegacyHive in July 2026.

ShieldBreak is a full patch bypass for CVE-2026-50656 (RoguePlanet), patched by Microsoft in the July 2026 Defender engine update. The PoC reports 100% success on Windows 11 25H2 and Windows Server 2025, up from RoguePlanet's inconsistent reliability.

Like RoguePlanet, ShieldBreak drives the exploit through Defender's own scan and remediation pipeline via MpClient.dll RPC calls. Where it diverges is in how the redirect and payload delivery work. ShieldBreak uses the Cloud Filter API to deliver content and switch it mid-operation: a restart hydration call swaps the bait (EICAR) for the payload DLL (Warden.dll) while Defender is mid-remediation. The redirect is constructed through the NT Object Manager namespace using symbolic links and shadowed directories, bypassing the NTFS junction layer that Microsoft's July patch targeted. A path routed through the CLFS device namespace creates a predictable artifact that anchors the redirect. The final payload lands at C:\Windows\System32\phoneinfo.dll via a UNC loopback path, and a fabricated WER crash report triggers the QueueReporting scheduled task to load it as SYSTEM.

No CVE has been assigned. No patch has been released. The behavioral chain survives recompilation and remains undetected by static means. Cyderes has built detection coverage for the chain described in this report.

Who Is Behind It

ShieldBreak comes from the same researcher behind every prior tool in this series. Public identity unknown. Three aliases seen across releases and press coverage: Nightmare-Eclipse, Chaotic Eclipse, and Dead Eclipse. GitHub releases ship under the handle MSNightmare.

The real identity behind the persona has not been independently confirmed by Cyderes.

Security journalist Brian Krebs and The Register have both reported that a LinkedIn profile tied to the persona shows employment in a Microsoft security role from September 2022 to June 2025, which would make this a former-insider dispute rather than an outside researcher's grievance. The researcher has not confirmed this publicly, and other outlets have treated the claim as an unverified rumor circulating in the security community.

The releases are framed. The researcher has publicly accused MSRC of revoking portal access, dismissing submitted reports, and refusing to pay bounties on confirmed findings. Every tool in the cluster has been dropped without coordinated disclosure, most in the days immediately following a Microsoft Patch Tuesday.

ShieldBreak is the tenth tool released since the first drop on April 3, 2026, all nineteen weeks targeting Windows Defender, BitLocker, or the User Profile Service. Six of the ten aim directly at Defender. The timeline below tracks what has shipped and where each stands on patching.

Figure 1: NightmareEclipse cluster timeline, BlueHammer through ShieldBreak

What Is the Vulnerability?

ShieldBreak is a design-level race condition in how Defender's remediation pipeline interacts with cloud-filter-backed file hydration and the NT Object Manager namespace. No memory safety bug. No elevated privileges required.

Six legitimate Windows features combine to produce the exploit:

• Cloud Filter API (CfApi): Lets a user-mode process register as a sync provider, create placeholder files, and control what content is delivered to disk when those placeholders are hydrated. The exploit's callback serves EICAR test content on the initial hydration request. A restart hydration call (CF_OPERATION_TYPE_RESTART_HYDRATION) then resets the placeholder with new file size metadata and triggers a second hydration, during which the callback serves the payload DLL instead. This mid-operation content switch is what delivers the attacker's binary through Defender's own remediation write.
• NT Object Manager shadow directories: The shadow directory mechanism (NtCreateDirectoryObjectEx) allows an atomic, filesystem-invisible path redirect that operates below the NTFS layer. It rearranges how paths resolve without touching the file system itself.
• NT Object Manager symbolic links: NtCreateSymbolicLinkObject creates targeted redirects within the shadow directory structure, steering Defender's output path to an attacker-chosen location via a UNC loopback path (127.0.0.1\C$\Windows\System32\phoneinfo.dll).
• CLFS device namespace routing: A symbolic link targeting the \CLFS\??\ Object Manager prefix forces the CLFS driver to create a predictable .BLF log file inside the working directory. The exploit locks this file exclusively (LockFileEx), anchoring the redirect chain so it remains stable through Defender's remediation sequence.
• Fabricated WER crash report: A fake Report.wer file is planted in C:\ProgramData\Microsoft\Windows\WER\ReportQueue\ under a crafted directory name. The report is structurally valid and passes the WER infrastructure's format checks, giving the QueueReporting task a pending report to process. When the task runs, wermgr.exe executes as SYSTEM and loads phoneinfo.dll from System32 as a known dependency, independent of the report contents.
• WER QueueReporting scheduled task: Runs as SYSTEM. Can be triggered by any unprivileged user via the Task Scheduler COM interface. Processes the fabricated crash report and loads the planted DLL with SYSTEM privileges.

Howler Cell Verification Run

Figure 2: Howler Cell verification run, standard user to NT AUTHORITY\SYSTEM.

The Core Flaw

The vulnerability is the gap between when Defender creates a remediation artifact and when it validates where that artifact actually landed. Microsoft's July patch for CVE-2026-50656 addressed this gap at the NTFS junction layer, where RoguePlanet operated. ShieldBreak moves the entire redirect to the NT Object Manager namespace, a layer the patch does not cover. The gap still exists. ShieldBreak fills it with a namespace redirect, a controlled payload delivery via restart hydration, and a fabricated crash report that triggers SYSTEM-level execution, turning Defender's own remediation into the delivery mechanism.

Technical Analysis

Stage 1: Initialization

The exploit checks that phoneinfo.dll does not exist in System32 (precondition for the DLL plant). The process sets itself to HIGH_PRIORITY_CLASS with THREAD_PRIORITY_TIME_CRITICAL to win scheduling races.

A named pipe \\??\\pipe\\SHIELDBREAK is created and held open for the process lifetime. The elevated payload will connect back through this pipe to signal success.

The named pipe SHIELDBREAK is a stable, observable artifact for the entire exploit duration. High-confidence detection indicator against the published PoC.

A working directory C:\ShieldBreak_<GUID> is created with the hidden attribute and an explicit ACL granting full control to the Everyone SID (required so Defender's SYSTEM-level service can write into it during remediation).

Stage 2: Cloud Provider Registration and Placeholder

A fake cloud sync provider named Flubber (GUID {B196E670-59C7-4D41-9637-C62D80541321}) is registered on the working directory using the Cloud Filter API, the same infrastructure backing OneDrive Files On-Demand.

A placeholder file named BERLIN is created inside the working directory with its advertised size set to the embedded zip resource size.

The critical component is the fetch-data callback. When a dehydrated placeholder is opened for reading, the cloud filter triggers hydration, which fires the callback. A counter (initialized to 1 and passed as the callback context) controls what gets served:

• Counter = 1: serves the embedded zip (malicious content for Defender detection), then advances to 2
• Counter = 2: serves the embedded DLL (the payload)

Figure 3: Callback Architecture

The first hydration delivers the EICAR zip content to disk. Once hydrated, the file sits on disk as a normal file and subsequent reads by Defender during scanning do not trigger the callback again. The second hydration is forced later in the chain via CF_OPERATION_TYPE_RESTART_HYDRATION, which dehydrates the placeholder, resets its metadata to match the DLL size, and triggers a fresh hydration request. This time the counter is already at 2, so the callback serves Warden.dll instead.

Stage 3: Object Manager Namespace Construction

Two object directories are created in \BaseNamedObjects\Restricted\:

• Target directory: WD_TARGET_<GUID>
• Shadow directory: WD_SHADOW_<GUID>, created with the target's handle as its ShadowDirectoryHandle. Lookups in the shadow check its own entries first, then fall through to the target's entries.

Two symbolic links named WD_SCAN are placed in different directories:

• In the shadow: WD_SCAN points to \??\C:\ShieldBreak_<GUID> (direct working directory)
• In the target: WD_SCAN points to \CLFS\??\C:\ShieldBreak_<GUID> (same path routed through the CLFS namespace prefix)

Because the shadow overlays the target, the shadow's WD_SCAN wins. The target's version is hidden.

When the shadow's WD_SCAN is deleted later, the target's version becomes visible. Same path, different resolution. Defender never sees the path string change.

The scan target passed to Defender is:

• \\.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERLIN

Stage 4: ADS Preparation

The exploit opens the BERLIN placeholder via its direct working directory path with read access. Under the registered CF_HYDRATION_POLICY_FULL policy, accessing the dehydrated placeholder triggers the first cloud callback, which serves the embedded EICAR zip. The placeholder is now hydrated on disk with malicious content. This happens before the Defender scan thread is started.

ntdll.dll is copied to an NTFS Alternate Data Stream on the placeholder (BERLIN:stream). This ADS serves as a pinning mechanism later in the chain: after the payload DLL lands at C:\Windows\System32\phoneinfo.dll through the redirect, the exploit maps phoneinfo.dll:stream as an executable image section (PAGE_EXECUTE_READ | SEC_IMAGE) with an active view. This prevents the file from being deleted or replaced while the mapping is held.

The restart hydration operation is staged at this point but not executed. The CF_OPERATION_TYPE_RESTART_HYDRATION parameters are populated with new file size metadata matching Warden.dll, and the transfer key is obtained from the placeholder handle. Execution is deferred until after the namespace manipulation and CLFS lock are in place.

Stage 5: Defender Scan and CLFS Log Capture

A worker thread loads Defender's internal client library, opens its RPC interface, and triggers a resource scan against the globalroot path. The placeholder was already hydrated with the malicious zip in Stage 4, so Defender reads it directly from disk without triggering a callback. Defender detects the threat, the worker thread confirms it, and enters the remediation pipeline.

Figure 4: Shadow link deletion on first directory change event, triggering the atomic path resolution flip

The main thread monitors the working directory for new files using ReadDirectoryChangesW:

• First FILE_ACTION_ADDED: Defender has created a remediation artifact. The exploit deletes the shadow directory's WD_SCAN link. Resolution now falls through to the target's link, routing through the \CLFS\ namespace prefix.
• Second FILE_ACTION_ADDED: CLFS has created a log file in the working directory. The exploit captures its filename.

Stage 6: CLFS Lock and Final Redirect

The CLFS log file is opened and exclusively byte-range locked over the maximum range, pausing Defender mid-remediation.

With Defender paused, the final redirect is constructed:

• A new WD_SCAN object directory is created in the shadow directory (occupying the name freed in Stage 5).
• Inside it, a symbolic link is created whose name matches the CLFS log filename (minus its extension) and whose target is the UNC loopback path \\??\UNC\127.0.0.1\C$\Windows\System32\phoneinfo.dll.

Figure 5: CLFS log filename stripped to symlink name, redirecting to phoneinfo.dll via UNC loopback

When Defender resumes and resolves the CLFS log through the object namespace, the path hits the new directory, matches the filename symlink, and resolves through SMB loopback to phoneinfo.dll in System32.

Stage 7: Payload Delivery and File Pinning

The staged restart hydration fires, changing the placeholder's advertised size to the DLL resource size. A full re-hydration is forced. The cloud callback now serves the embedded DLL, and through the redirect chain, the content lands at C:\Windows\System32\phoneinfo.dll under Defender's SYSTEM token.

The exploit pins the payload by opening phoneinfo.dll:stream (the ADS carrying the ntdll.dll copy from Stage 4) with execute access and mapping it as SEC_IMAGE. Windows will not delete a file backing an active image section.

The remediation pipeline is then released cleanly.

Stage 8: WER Task Execution and Shell Delivery

A WER report directory is created at:

• C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_c0000000_A_B_C-C-D-E-<GUID>

A crafted Report.wer is written into it. The report contains a valid-looking crash record for a fabricated application, structured to pass the WER infrastructure's format validation.

The QueueReporting scheduled task is triggered via the Task Scheduler COM interface. This task runs under SYSTEM and can be triggered by any unprivileged user. Its processing loads the planted phoneinfo.dll from System32.

The payload DLL, now executing as SYSTEM, connects back through the SHIELDBREAK pipe. The orchestrator's blocking ConnectNamedPipe unblocks and the exploit prints "Exploit succeeded."

What Should Defenders Do?

• No patch exists. The PoC is public. Signature detections target the compiled binary only and do not survive recompilation.

PoC-Specific Indicators (high-confidence, low-effort to change)

• Named pipe \\.\pipe\SHIELDBREAK created by a non-system process. Any actor adapting this technique would rename the pipe.
• Cloud sync root registration with provider name Flubber or GUID {B196E670-59C7-4D41-9637-C62D80541321}. Both are trivially changed in modified builds.
• Working directory matching the pattern C:\ShieldBreak_<GUID> at the root of C: created with the hidden attribute and an Everyone SID full-control ACL. The root-of-C location is unusual for any legitimate application.
• A placeholder file named BERLIN inside a Cloud Files sync root.

Behavioral Indicators (technique-level, survive recompilation)

• phoneinfo.dll appearing in System32. This DLL does not ship with any supported Windows version. Its presence is a confirmed indicator of compromise. Alert on file creation events for this path.
• CfRegisterSyncRoot called by processes outside of known cloud sync software (OneDrive, Dropbox, Box, iCloud). ShieldBreak registers a sync root on a directory at the root of C:. Cloud sync registrations from unsigned binaries or from paths outside of standard user profile directories are suspicious. This is the same signal from BlueHammer and RedSun and should already be in your detection stack.
• Object Manager symbolic links and directories created beneath \BaseNamedObjects\Restricted by user-mode processes. The WD_TARGET_ and WD_SHADOW_ naming pattern is PoC-specific, but any symbolic link creation in this namespace by non-system processes is uncommon. Tune against known legitimate uses (some cloud sync and virtualization software uses this namespace).
• WER report directories created under C:\ProgramData\Microsoft\Windows\WER\ReportQueue\ by non-WER processes. Standard users can write to this path. The Kernel_ prefix with a GUID suffix is the PoC pattern, but any report directory created by a process that is not WerFault.exe or WerSvc should be investigated.
• Report.wer files written by processes other than WerFault.exe or Windows Error Reporting service components. Legitimate Report.wer files are created by WER infrastructure. A user-mode process writing one directly is a strong signal.
• WER QueueReporting scheduled task triggered via Task Scheduler COM interface from a non-administrative, non-WER process.
• MpClient.dll loaded by processes outside of the Defender service tree. ShieldBreak (like RoguePlanet, RedSun, and BlueHammer) loads MpClient.dll at runtime and calls its exports directly. Any process loading this library that is not MsMpEng.exe, MpCmdRun.exe, or another Defender component should be flagged. This detection applies across the entire NightmareEclipse cluster.

Composite detection (highest confidence):

• The strongest detection signal is the combination of multiple indicators in close temporal proximity from the same process. Cloud Filter sync root registration + Object Manager namespace activity + MpClient.dll load + WER ReportQueue write + QueueReporting task trigger.
• No legitimate software performs this sequence. Any two or more of these from the same process tree within a short window should generate a high-severity alert.

Cyderes Detection Engineering have built behavioural coverage for ShieldBreak targeting these TTPs. Cyderes clients are protected against the behavioural chain described above

Conclusion

ShieldBreak is the first tool in this cluster to fully bypass a patch Microsoft shipped for a prior NightmareEclipse exploit. Microsoft's July fix for CVE-2026-50656 closed the NTFS junction-based redirect that RoguePlanet used. ShieldBreak moves the entire redirect to the Object Manager namespace, where that patch has no visibility, and replaces the probabilistic race with priority-class scheduling that achieves 100% reliability.

No kernel exploit. No memory corruption. The attack succeeds because the Cloud Filter API, Defender's remediation pipeline, the Object Manager namespace, CLFS path routing, and the WER task infrastructure can be combined in a sequence that produces a result none of them were designed to permit.

This is the tenth tool from NightmareEclipse in nineteen weeks. The pattern of dropping exploits after Patch Tuesday and bypassing patches within weeks of release should be treated as ongoing. Until a root-cause patch addressing the Object Manager redirect path and the CfApi restart hydration primitive is available, behavioral detection against the TTPs described in this report is the primary defensive control.

Howler Cell is tracking MSNightmare's ongoing activity. Findings will be updated as the situation develops.

Appendix

Zero-Day PoC

• hxxps[://]github[.]com/MSNightmare/ShieldBreak
• Named pipe: \\.\pipe\SHIELDBREAK
• Working directory pattern: C:\ShieldBreak_<GUID>, hidden attribute, Everyone SID full control
• Cloud sync provider: "Flubber", GUID {B196E670-59C7-4D41-9637-C62D80541321}
• Placeholder file: BERLIN, created inside a Cloud Files sync root
• Dropped payload path: C:\Windows\System32\phoneinfo.dll, delivered via UNC loopback (127.0.0.1\C$)
• Embedded payload resource: Warden.dll (not present in RoguePlanet)
• Defender signatures: Exploit:Win32/NghtMrShldBrk.BB, Trojan:Win32/Bearfoos.B!ml (compiled sample only, does not survive recompilation)

Related NightmareEclipse mirrors and channels

• git.churchofmalware[.]org/Nightmare_Eclipse
• git.projectnightcrawler[.]dev/NightmareEclipse
• deadeclipse666[.]blogspot[.]com

Related Cyderes Howler Cell coverage

• https://www.cyderes.com/howler-cell/greatxml-windows-zero-day
• https://www.cyderes.com/howler-cell/rogueplanet-windows-zero-day
• https://www.cyderes.com/howler-cell/redsun-zero-day
• https://www.cyderes.com/howler-cell/windows-zero-day-bluehammer
• https://www.cyderes.com/howler-cell/legacyhive-windows-user-profile-loading-vulnerability

Indicators of Compromise

File hashes for the compiled samples are below. Both are already flagged by the Defender signatures listed above, so these specific hashes have little standalone detection value going forward. A minor recompile changes every value in this table without touching the underlying technique. Treat these as a record of what was seen in this release, not as a durable detection control, and expect new hashes and likely new evasion methods as this cluster continues.