ShieldBreak: When Microsoft Patches a Zero-Day and the Researcher Patches the Patch
Category: Vulnerability Research | Windows Security | Zero-Day Analysis • Published: August 12, 2026
- What Just Happened
- Who Is Nightmare-Eclipse?
- What Makes ShieldBreak Different From RoguePlanet
- The Six Windows Features That Combine to Produce the Exploit
- Eight-Stage Attack Chain, Explained
- Why Microsoft's July Patch Didn't Work
- Current Detection Posture
- What Defenders Should Actually Do
- MITRE ATT&CK Mapping
- IOC Reference
- The Bigger Picture
- References
1. What Just Happened
On July 9, 2026, Microsoft shipped an out-of-cycle Defender engine update (version 1.1.26060.3008) specifically targeting CVE-2026-50656 — the vulnerability underlying RoguePlanet, a local privilege escalation exploit that had been running unpatched since June. That patch took about five weeks to land. The researcher who published RoguePlanet took about a month to beat it.
On August 11, 2026, a new repository appeared on GitHub under the MSNightmare handle. The repository is called ShieldBreak. It does not exploit a new bug. It walks directly through the patch Microsoft built to close RoguePlanet, on fully patched Windows 11 25H2 and Windows Server 2025, at a reported success rate of 100%.
This is the tenth tool from the NightmareEclipse cluster in nineteen weeks. It is the first time in the campaign that the researcher has cycled back to defeat a patch built specifically to stop them. The PoC is publicly available. No CVE has been assigned. No patch exists.
2. Who Is Nightmare-Eclipse?
The real identity behind the persona has not been independently confirmed. The researcher operates under three aliases — Nightmare-Eclipse, Chaotic Eclipse, and Dead Eclipse — with GitHub releases shipping under MSNightmare. Security journalists at Krebs on Security and The Register have reported that a LinkedIn profile tied to the persona shows Microsoft security employment from September 2022 to June 2025, suggesting a former-insider dispute rather than an outside researcher's grievance. The researcher has not confirmed this. Other outlets treat it as an unverified circulating rumor.
What is verifiable is the public record: ten working exploits targeting Windows Defender, BitLocker, or the User Profile Service, released over nineteen weeks beginning April 3, 2026, none of them coordinated with Microsoft before publication. The stated motivation is specific — revoked portal access, dismissed bug reports, bounties refused on confirmed findings. The researcher frames the releases as a response to what they describe as defamation by MSRC.
The track record matters for evaluating the threat level of new releases. Three earlier tools in this cluster — BlueHammer, RedSun, and UnDefend — have been confirmed in real-world attack chains by Huntress researchers. When the tenth tool in a series drops publicly, the baseline assumption should not be "this might get picked up." It already has an audience.
| Tool | CVE | Patch Status | Notes |
|---|---|---|---|
| BlueHammer | CVE-2026-33825 | Patched April 14, 2026 | Added to CISA KEV. Confirmed real-world exploitation. |
| RedSun | CVE-2026-41091 | Patched May 21, 2026 (out-of-band) | Added to CISA KEV. Confirmed exploitation. |
| UnDefend | CVE-2026-45498 | Patched May 21, 2026 (out-of-band) | Added to CISA KEV. |
| YellowKey | CVE-2026-45585 | Patched June 9, 2026 | |
| GreenPlasma | CVE-2026-45586 | Patched June 9, 2026 | |
| MiniPlasma | CVE-2020-17103 (researcher-attributed) | Patched June 9, 2026 | Re-exploitation of incomplete 2020 fix. |
| RoguePlanet | CVE-2026-50656 | Patched July 9, 2026 | PoC public June 10, 2026. |
| GreatXML | — | Unpatched | |
| LegacyHive | — | Unpatched | User Profile Service, July 2026. |
| ShieldBreak | No CVE assigned | No patch available | Full bypass of the RoguePlanet patch. PoC public August 11, 2026. |
3. What Makes ShieldBreak Different From RoguePlanet
RoguePlanet was the seventh release in this cluster. ShieldBreak is the tenth. On the surface, both are local privilege escalation exploits that elevate a standard user to NT AUTHORITY\SYSTEM through Defender's own remediation pipeline. Beyond that, the mechanics diverge significantly.
RoguePlanet used NTFS junction swaps and opportunistic locks to redirect Defender's quarantine artifact into attacker-controlled space, then triggered WER's QueueReporting scheduled task to execute the injected payload. The exploit was reliable in lab conditions but described by the researcher as "hit or miss" in production due to timing variability in the underlying race condition. Microsoft's July patch targeted the NTFS junction layer where the redirect operated.
ShieldBreak does not touch NTFS junctions. The entire redirect has moved to the NT Object Manager namespace — a layer the July patch does not reach. Instead of junctions, the exploit uses a shadow directory mechanism to atomically flip how a path resolves without touching the filesystem at all. The race condition that plagued RoguePlanet is replaced with priority-class scheduling and a CLFS log file lock that pauses Defender mid-remediation at a deterministic point. Result: 100% reported success on patched Windows 11 25H2 and Windows Server 2025.
The payload delivery is also new. RoguePlanet delivered a copy of its own binary through Defender's quarantine write. ShieldBreak uses the Cloud Filter API to switch delivered content mid-operation — serving EICAR test content on the first hydration request, then swapping to Warden.dll on a forced restart hydration. The final payload lands at C:\Windows\System32\phoneinfo.dll, a path that does not exist in any supported Windows version and whose presence is therefore an unambiguous indicator of compromise.
4. The Six Windows Features That Combine to Produce the Exploit
ShieldBreak is not a memory safety bug. Nothing overflows. Nothing corrupts. Six legitimate, documented Windows features are assembled in a specific sequence that produces a result none of them were designed to allow.
Cloud Filter API (CfApi). The infrastructure backing OneDrive Files On-Demand. ShieldBreak registers a fake sync provider named "Flubber" and creates a placeholder file called BERLIN. When the placeholder is read, the registered callback controls what content is served. First read: EICAR zip. Forced second read via CF_OPERATION_TYPE_RESTART_HYDRATION: Warden.dll. Defender's own remediation write is what delivers the DLL to System32 — the callback is just deciding what that write contains.
NT Object Manager shadow directories. The NtCreateDirectoryObjectEx API creates a shadow directory that overlays a target directory. Lookups check the shadow's own namespace first and fall through to the target's entries if nothing matches. This produces an atomic, filesystem-invisible path redirect that operates below the NTFS layer entirely.
NT Object Manager symbolic links. NtCreateSymbolicLinkObject places targeted redirects within the shadow directory structure. When the shadow's link is deleted, the target's link becomes visible — same path string, different resolution. Defender never sees a path change because there is no path change at the string level.
CLFS device namespace routing. A symbolic link targeting the \CLFS\??\ Object Manager prefix forces the CLFS driver to create a predictable .BLF log file in the working directory. The exploit locks this file exclusively using LockFileEx, pausing Defender's remediation at a controlled point and holding the redirect chain stable while the final namespace construction completes.
Fabricated WER crash report. A structurally valid Report.wer file planted in C:\ProgramData\Microsoft\Windows\WER\ReportQueue\. Format validation passes. When the QueueReporting scheduled task processes it, wermgr.exe executes as SYSTEM and loads phoneinfo.dll from System32 as a known dependency — independent of anything in the report itself.
WER QueueReporting scheduled task. Present on every standard Windows installation. Runs as SYSTEM. Can be triggered by any unprivileged user through the Task Scheduler COM interface. ShieldBreak uses it the same way RoguePlanet did. It is the SYSTEM-level execution primitive at the end of the chain.
5. Eight-Stage Attack Chain, Explained
Stage 1: Initialization
The exploit checks that phoneinfo.dll does not already exist in System32. The process sets itself to HIGH_PRIORITY_CLASS with THREAD_PRIORITY_TIME_CRITICAL — this is how ShieldBreak eliminates RoguePlanet's timing variability. A named pipe \\.\pipe\SHIELDBREAK is created and held open for the process lifetime. The elevated payload connects back through it to signal success.
A working directory C:\ShieldBreak_<GUID> is created with the hidden attribute and an Everyone SID full-control ACL. The Everyone ACL is required so that Defender's SYSTEM-level service can write into the directory during remediation.
SHIELDBREAK is a stable, observable artifact for the entire exploit duration. High-confidence indicator against the published PoC.
Stage 2: Cloud Provider Registration and Placeholder
The fake cloud sync provider "Flubber" (GUID {B196E670-59C7-4D41-9637-C62D80541321}) is registered on the working directory using the same Cloud Filter API that backs OneDrive. A placeholder file named BERLIN is created inside with its advertised size set to the embedded zip resource.
The fetch-data callback controls hydration output via a counter initialized to 1:
- Counter = 1: Serves the embedded EICAR zip (bait that triggers Defender detection), then advances counter to 2
- Counter = 2: Serves Warden.dll (the payload)
The first hydration — delivering EICAR to disk — happens before Defender is invoked. Subsequent reads by Defender during scanning do not fire the callback again because the file is already fully hydrated. The second hydration is forced later via CF_OPERATION_TYPE_RESTART_HYDRATION, which dehydrates the placeholder, resets its size metadata to match Warden.dll, and triggers a fresh callback. Counter is at 2. The callback serves the DLL.
Stage 3: Object Manager Namespace Construction
Two object directories are created in \BaseNamedObjects\Restricted\:
- Target:
WD_TARGET_<GUID> - Shadow:
WD_SHADOW_<GUID>, created with the target's handle as itsShadowDirectoryHandle
Two symbolic links named WD_SCAN are placed in these directories:
- In the shadow: points to
\??\C:\ShieldBreak_<GUID>(working directory directly) - In the target: points to
\CLFS\??\C:\ShieldBreak_<GUID>(same path, via CLFS namespace prefix)
Because the shadow overlays the target, the shadow's WD_SCAN link wins. The target's is hidden. When the shadow's link is deleted later, the target's becomes visible — same path name, different resolution, no filesystem change, no path string change visible to any external process.
The scan target passed to Defender:\\.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERLIN
Stage 4: ADS Preparation
BERLIN is opened via the direct working directory path. Under the registered hydration policy, accessing the dehydrated placeholder triggers the first callback — EICAR zip content is served and written to disk. The file is now hydrated.
ntdll.dll is then copied to an NTFS Alternate Data Stream on the placeholder (BERLIN:stream). This ADS is a pinning mechanism: after Warden.dll lands at phoneinfo.dll, the exploit maps phoneinfo.dll:stream as an executable image section (PAGE_EXECUTE_READ | SEC_IMAGE), which prevents Windows from deleting a file backing an active image mapping.
The restart hydration parameters are staged here but not fired — deferred until the namespace manipulation and CLFS lock are in place.
Stage 5: Defender Scan and CLFS Log Capture
A worker thread loads MpClient.dll directly, opens its RPC interface, and triggers a resource scan of the BERLIN placeholder through the globalroot path. Because the placeholder is already hydrated with EICAR, Defender reads it from disk without firing the callback. Detection happens. Defender enters remediation.
The main thread monitors the working directory with ReadDirectoryChangesW:
- First FILE_ACTION_ADDED: Defender has created a remediation artifact. The exploit immediately deletes the shadow directory's WD_SCAN link. Path 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 exclusively byte-range locked over the maximum range. Defender pauses mid-remediation.
With Defender paused, the final redirect is constructed:
- A new
WD_SCANobject directory is created inside the shadow directory (occupying the name freed when the prior link was deleted 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
When Defender resumes and resolves the CLFS log through the Object Manager namespace, it 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. The placeholder's advertised size changes to match Warden.dll. Full re-hydration is forced. The callback serves Warden.dll. Through the redirect chain, that content lands at C:\Windows\System32\phoneinfo.dll under Defender's SYSTEM token.
The exploit pins the payload: phoneinfo.dll:stream is mapped as a SEC_IMAGE section. Windows will not delete a file backing an active image mapping. Defender's remediation pipeline is 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 structurally valid Report.wer is written into it, crafted to pass WER format validation. The QueueReporting scheduled task is triggered via Task Scheduler COM from the unprivileged process. The task runs as SYSTEM, processes the fabricated report, and loads phoneinfo.dll from System32 as a known dependency.
Warden.dll is now executing as SYSTEM. It connects back through the SHIELDBREAK pipe. The orchestrator's blocking ConnectNamedPipe unblocks. The exploit prints "Exploit succeeded."
6. Why Microsoft's July Patch Didn't Work
Microsoft's fix for CVE-2026-50656 addressed the NTFS junction layer — the junction-based redirect that RoguePlanet used to steer Defender's quarantine artifact into attacker-controlled space. That was the right fix for the tool it was patching.
ShieldBreak does not use NTFS junctions. The entire redirect operates through the NT Object Manager namespace, using shadow directories and symbolic links to flip path resolution atomically and invisibly at a layer the July patch does not instrument. The core vulnerability — the gap between when Defender creates a remediation artifact and when it validates where that artifact actually landed — was not closed at the root. The July patch closed one instance of that gap at one layer. ShieldBreak found the same gap expressed through different plumbing at a different layer.
A root-cause fix requires a change to how Defender validates path integrity across its quarantine workflow at the file handle level, not at the path string level. That is an architectural change.
7. Current Detection Posture
The Defender signatures Exploit:Win32/NghtMrShldBrk.BB and Trojan:Win32/Bearfoos.B!ml flag the compiled sample. Minor source modifications defeat them. The behavioral chain is undetected by static means and survives recompilation without additional changes.
There is no patch. The PoC is public. Hash-based and signature-based detection of the compiled binary has the same limitation it always does in this cluster: it is accurate until someone recompiles, which is trivial.
8. What Defenders Should Actually Do
No patch exists. Detection has to be behavioral. The following signals are organized from most reliable to most environment-dependent.
High-Confidence PoC-Specific Signals
These accurately detect the published PoC and are trivially defeated by anyone adapting the technique. Worth running now; do not treat them as durable detections.
- Named pipe
\\.\pipe\SHIELDBREAKcreated by a non-SYSTEM process - Cloud sync root registration with provider name "Flubber" or GUID
{B196E670-59C7-4D41-9637-C62D80541321} - Working directory at the root of C: matching
C:\ShieldBreak_<GUID>with hidden attribute and an Everyone SID full-control ACL. Root-of-C directories with Everyone full-control ACLs have essentially no legitimate equivalent. - Placeholder file named BERLIN inside a Cloud Files sync root
Technique-Level Behavioral Signals (survive recompilation)
phoneinfo.dllappearing inC:\Windows\System32\. This file does not ship with any supported Windows version. Its presence is confirmed compromise. Alert on file creation events at this path and do not wait for execution.CfRegisterSyncRootcalled by processes outside of known cloud sync software (OneDrive, Dropbox, Box, iCloud). This signal appeared in BlueHammer and RedSun coverage and should already be in your stack. A sync root registered on a directory at the root of C: from an unsigned binary is high-signal.- Object Manager symbolic links or directories created under
\BaseNamedObjects\Restrictedby user-mode processes. TheWD_TARGET_andWD_SHADOW_naming pattern is PoC-specific; any symlink creation in this namespace from non-system processes is uncommon. Baseline against your environment before alerting. MpClient.dllloaded by processes outside the Defender service tree. ShieldBreak, RoguePlanet, RedSun, and BlueHammer all load this library at runtime and call its exports directly. Any process loading it that is notMsMpEng.exe,MpCmdRun.exe, or another Defender component should be flagged. Applies across the entire NightmareEclipse cluster.- WER report directories or
Report.werfiles written underC:\ProgramData\Microsoft\Windows\WER\ReportQueue\by non-WER processes. Standard users can write to this path. A user-mode process writing aReport.werdirectly is a strong signal. - QueueReporting scheduled task triggered via Task Scheduler COM from a non-SYSTEM, non-WER process.
Composite Signal (Highest Confidence)
No legitimate software performs this combination: Cloud Filter sync root registration + Object Manager namespace activity + MpClient.dll load + WER ReportQueue write + QueueReporting task trigger. Any two or more of these from the same process tree within a short window should generate a high-severity alert. The composite signal survives recompilation and actor adaptation in a way individual indicators do not.
9. MITRE ATT&CK Mapping
| Technique ID | Technique Name | How ShieldBreak Uses It |
|---|---|---|
| T1068 | Exploitation for Privilege Escalation | Core exploit: standard user to NT AUTHORITY\SYSTEM through Defender's remediation pipeline, no kernel bug required |
| T1574.010 | Hijack Execution Flow: Services File Permissions Weakness | Warden.dll delivered to System32 via Defender's SYSTEM-token write, then loaded by WER task |
| T1053.005 | Scheduled Task/Job: Scheduled Task | WER QueueReporting (SYSTEM) triggered via Task Scheduler COM by unprivileged user |
| T1055 | Process Injection | Warden.dll executes as SYSTEM, connects back to orchestrator via named pipe |
| T1036.005 | Masquerading: Match Legitimate Name or Location | Payload delivered to C:\Windows\System32\phoneinfo.dll via UNC loopback redirect |
| T1480 | Execution Guardrails | Pre-check for phoneinfo.dll existence gates execution; priority-class scheduling enforces reliable timing |
| T1187 | Forced Authentication | UNC loopback path (127.0.0.1\C$) routes payload delivery through SMB loopback |
| T1562.001 | Impair Defenses: Disable or Modify Tools | Defender's own remediation pipeline is the delivery mechanism; no external injection needed |
10. IOC Reference
| Indicator | Type | Notes |
|---|---|---|
\\.\pipe\SHIELDBREAK | Named Pipe | PoC-specific; rename defeats this indicator |
C:\ShieldBreak_<GUID> at root of C:, hidden, Everyone SID full control | File Path Pattern | Unusual ACL at root of C: is the durable signal component |
Cloud sync provider "Flubber", GUID {B196E670-59C7-4D41-9637-C62D80541321} | Registry/CfApi | PoC-specific; trivially changed |
Placeholder file BERLIN inside Cloud Files sync root | File | PoC-specific |
C:\Windows\System32\phoneinfo.dll | File | Does not exist in any legitimate Windows install. Confirmed IOC. Alert on creation. |
Exploit:Win32/NghtMrShldBrk.BB | Defender Signature | Compiled sample only; does not survive recompilation |
Trojan:Win32/Bearfoos.B!ml | Defender Signature | Compiled sample only |
hxxps[://]github[.]com/MSNightmare/ShieldBreak | PoC URL | Defanged |
git.projectnightcrawler[.]dev/NightmareEclipse | Mirror | Defanged |
git.churchofmalware[.]org/Nightmare_Eclipse | Mirror | Defanged |
deadeclipse666[.]blogspot[.]com | Researcher Blog | PGP-signed posts; tracks new releases |
File hashes (Warden.dll):
| Algorithm | Hash |
|---|---|
| MD5 | ff5b18a59cc71ea4274239463bf1d9d2 |
| SHA-1 | c60b42ce019d8e727e08e75690128f28583d8900 |
| SHA-256 | 691857f3f28049a7e33f5767d4e4eb3d739e1aa76c2a43c8cccadf871cfa7c1a |
| SHA3-256 | 96167fa28329360740d5cd0c72ef57090045a4e7079b404223e80c2d08b192f9 |
These hashes identify the specific compiled release. A recompile changes all of them. Treat as a record of what was observed, not a durable detection control.
11. The Bigger Picture
Ten tools in nineteen weeks. The pace alone is notable. But the more significant development with ShieldBreak is the feedback loop it establishes: Microsoft patches an exploit from this cluster, and within roughly a month, the researcher delivers a full bypass of that specific patch at higher reliability than the original. That is not coincidental timing. It is a deliberate, calibrated response.
The architectural consistency is intentional. All ten tools target the intersection of Microsoft Defender, Windows namespace and filesystem behavior, scheduled task infrastructure, and Windows security internals. This is not breadth — it is depth. The researcher has mapped a family of related design assumptions in a specific attack surface and is working through them methodically.
Each patch informs the next exploit. The April 2026 fix for BlueHammer did not end the campaign — it told the researcher what Microsoft had visibility into. The mid-May Defender engine update that broke RoguePlanet's original remote code execution path resulted in three weeks of rebuilding on a different primitive. ShieldBreak is the same dynamic applied to a shipped patch rather than an engine update.
Public release is not an accident. Every tool in this cluster dropped without coordinated disclosure. Three of them appeared in real-world attack chains within weeks of release. When a working LPE PoC goes public, the question is not whether it will be used by attackers — it is how quickly.
The patch gap is the actual problem. Closing individual expressions of the vulnerability while leaving the underlying architectural gap accessible gives the researcher raw material for the next release. ShieldBreak is the second demonstration of that dynamic; it will likely not be the last.
Behavioral detection against the TTPs described above is the primary and only reliable defensive control until a root-cause patch addressing the Object Manager redirect path and the CfApi restart hydration primitive is available.
12. References
- Primary Technical Analysis: Reegun Jayapaul and Rahul Ramesh, Cyderes Howler Cell — "ShieldBreak: The Windows Zero-Day That Breaks Microsoft's Own RoguePlanet Fix," August 12, 2026.
- Cyderes Howler Cell — RoguePlanet (CVE-2026-50656)
- Cyderes Howler Cell — LegacyHive
- Cyderes Howler Cell — GreatXML
- Cyderes Howler Cell — RedSun (CVE-2026-41091)
- Cyderes Howler Cell — BlueHammer (CVE-2026-33825)
- PoC repository (defanged):
hxxps[://]github[.]com/MSNightmare/ShieldBreak
Tags: Windows Zero-Day, Privilege Escalation, Microsoft Defender, LPE, Cloud Filter API, NT Object Manager, CLFS, WER Scheduled Task, Nightmare-Eclipse, MSNightmare, ShieldBreak, CVE-2026-50656, Patch Bypass, Windows 11, Vulnerability Research, Zero-Day Exploit, Defender Remediation, Threat Intelligence
