Back to threat alerts

Zero-Day: ShieldBreak Microsoft Defender Privilege Escalation

On August 12, 2026, Nightmare Eclipse shared an exploit that allows a local standard user to elevate execution integrity to NT AUTHORITY\SYSTEM. Although initially characterised by the researcher as a direct patch bypass for the RoguePlanet vulnerability (CVE-2026-50656), technical analysis demonstrates that ShieldBreak utilises a distinct vulnerability mechanism.

Threat alert
August 13, 2026
RoguePlanet vs. ShieldBreak

Distinguishing between RoguePlanet (CVE-2026-50656) and ShieldBreak is essential for accurate threat hunting and vulnerability tracking. Although both exploits weaponise Microsoft Defender's privileged file processing routines to achieve local privilege escalation, their core primitives, API interactions, and operational dependencies differ fundamentally.
‍

RoguePlanet leveraged a Time-of-Check to Time-of-Use race condition within Defender's quarantine engine. An attacker mounted a virtual disk (.vhd or .iso image) containing an EICAR test string, initiated a scan, and manipulated opportunistic locks (OpLocks), directory junctions, and Volume Shadow Copy snapshots to redirect file operations. This forced Defender's core service (MsMpEng.exe), operating under the SYSTEM context, to overwrite arbitrary system binaries with attacker-controlled code.
‍

ShieldBreak bypasses filesystem race conditions and virtual disk mounting entirely. Instead, it targets asynchronous file hydration during real-time antimalware scanning of cloud-synced storage locations. By registering a local directory as a Cloud Sync provider via the Cloud Filter API (cfapi), the exploit hooks user-mode hydration callback routines. When Defender inspects a newly written EICAR file within this directory, the callback intercepts the read request, leverages Common Log File System (CLFS) transactions to alter hydration metadata, and writes an arbitrary binary named phoneinfo.dll into C:\Windows\System32\.

Attack Chain
  1. Cloud Sync Provider Registration: The exploit initialises by interacting with native functions in cldapi.dll to register an attacker-controlled temporary folder as an active Windows Cloud Sync Provider. This configuration grants the user-mode process authority over placeholding, file hydration, and read callback operations within that folder hierarchy.
  2. Defender Scan Induction: An EICAR standard anti-malware test string is dropped into the newly registered sync directory. Microsoft Defender's real-time filter driver (WdFilter.sys) flags the file creation event and commands the antimalware service (MsMpEng.exe) to perform a file inspection and cloud-hydration scan.
  3. Cloud Filter Callback Interception: As Defender opens the file placeholder to evaluate its contents, the Windows Cloud Filter driver issues an asynchronous data fetch callback to the registered provider. The exploit process intercepts this user-mode callback, pauses the data response, and uses Windows Object Manager symbolic links to alter the target path destination.
  4. CLFS State Swap and File Creation: Utilising the Common Log File System (CLFS) transaction model, the exploit swaps the identity file and hydration stream data. When Defender completes the file write operation under its elevated context, the output is redirected to create C:\Windows\System32\phoneinfo.dll populated with attacker-supplied code. The file phoneinfo.dll does not exist in standard Windows installations, making it an ideal target for phantom DLL hijacking.
  5. Coerced Execution via Windows Error Reporting: With phoneinfo.dll planted in System32, the exploit triggers the native Windows Error Reporting scheduled task QueueReporting, which executes wermgr.exe -upload under the NT AUTHORITY\SYSTEM context. As wermgr.exe loads its supporting library wer.dll, explicit code within wer.dll checks for and imports phoneinfo.dll from System32. The malicious code executes within the elevated SYSTEM process, spawning conhost.exe or an interactive command shell with full system privileges.
Operating System Vulnerability

ShieldBreak impacts current client and server releases of Microsoft Windows. Testing across multiple distribution channels confirms that standard security baselines do not prevent execution unless explicit binary allowlisting controls are configured.
‍

Operating System Platform: Build / Release Channel

Windows 11 25H2: Production / General Availability

Windows 11 Canary: Insider Preview Channels

Windows Server 2025: Core & Desktop Experience

Windows 10 Enterprise: 22H2 / ESU / LTSC 2021

Windows 10 Non-ESU: Consumer / Out-of-Support

Recommendations and Mitigation
  • Application Allowlisting: Enforce Windows Defender Application Control (WDAC) using strict Publisher/Signer rules rather than standard Path rules for system directories. This ensures unauthorised or unsigned binaries dropped into System32 cannot execute, even if placed there by elevated system components.
  • Attack Surface Reduction (ASR): Enable ASR rules to restrict child process creation from system utilities and prevent executable content creation within temporary directories, blocking post-exploitation staging.
  • Directory Auditing (SACLs): Enable System Access Control Lists (SACLs) on C:\Windows\System32\ to generate audit logs for file creation and write operations. Note: Telemetry must explicitly capture actions taken by elevated system accounts (NT AUTHORITY\SYSTEM and MsMpEng.exe) rather than filtering out administrative activity.
  • Phantom DLL Threat Detection: Configure high-fidelity EDR and SIEM file-creation alerts specifically targeting C:\Windows\System32\phoneinfo.dll and other known Windows Error Reporting (WER) phantom DLL targets, regardless of the initiating process.
  • Tamper Protection: Mandate cloud-managed Microsoft Defender Tamper Protection across all enterprise endpoints as critical baseline security hygiene.

‍