ShieldBreak – description of the exploitation mechanism for a SOC analyst

ShieldBreak is a local privilege escalation chain to NT AUTHORITY\SYSTEM, claimed by the author to be a bypass of the fix for CVE-2026-50656 (RoguePlanet) in Microsoft Defender. For exploitation, the attacker must already be able to execute code on the host, but administrative privileges are not required.

How the attack works.

Preparation of a controlled file.

The exploit creates a working directory and registers it as a Cloud Files sync root. A placeholder file named BERLIN is created inside it. Its contents are returned on request through a callback, so the attacker can change the data between read operations.

Creation of dual path resolution.

The WD_SHADOW_* and WD_TARGET_* directories and the WD_SCAN symbolic links are created through Windows Object Manager. While the first link exists, the path passed to Defender leads to the regular BERLIN file. After it is deleted, the same string is resolved through CLFS.

Obtaining a Defender verdict.

The exploit initiates a resource scan itself through MpClient.dll. On the first read, the Cloud Files callback returns a ZIP archive containing EICAR. Defender detects the test threat and opens a cleanup procedure as SYSTEM. The state of real-time protection is not essential to this sequence because the scan is invoked directly.

Destination substitution during cleanup.

After the threat is detected, the PoC deletes the first WD_SCAN link, waits for the CLFS service file to be created, and locks it through LockFileEx. A new chain of links is then created, leading through the local administrative SMB share to:

\\127.0.0.1\C$\Windows\System32\phoneinfo.dll

Content replacement.

Placeholder hydration is restarted. On subsequent reads, the callback returns Warden.dll instead of the archive containing EICAR. As a result, the Defender operation running with SYSTEM privileges writes the attacker’s DLL to C:\Windows\System32.

Retaining the file.

The PoC waits for phoneinfo.dll:stream to appear and maps the valid PE file contained there as an executable image. This keeps the file object open and prevents the cleanup procedure from deleting the created file.

Executing the DLL as SYSTEM.

The exploit places the prepared Report.wer into the Windows Error Reporting queue and starts the existing task:

\Microsoft\Windows\Windows Error Reporting\QueueReporting .

Task Scheduler starts wermgr.exe with system privileges. It loads phoneinfo.dll, after which the Warden.dll code executes as SYSTEM.

Obtaining a system process.

The payload connects to the SHIELDBREAK named pipe, obtains the process’s system token, transfers it to the interactive session, and starts a process with SYSTEM privileges. The connection to the pipe also serves as the PoC’s confirmation of successful exploitation.

Where the vulnerability is located.

The key problem is the inconsistency between the object that Defender inspected and the object on which cleanup is subsequently performed.

Defender first detects the threat through an attacker-controlled path, but during processing it continues to work with a repeatedly resolved name. Between validation and use, the attacker changes the meaning of the path. This is a type of TOCTOU/link-following: one object is inspected, while the privileged operation is performed on another.

The Cloud Files callback, CLFS, Object Manager, and file locking are not four independent vulnerabilities. They are used together to:

• control the file’s contents;
• synchronize with Defender’s processing stages;
• change the path destination after detection;
• retain the created DLL until it is loaded.

What the analyst should see.

In the published PoC, the sequence looks approximately as follows:

User process:

• creates C:\ShieldBreak_{GUID};
• registers a Cloud Files sync root;
• creates the BERLIN placeholder;
• initiates a Defender scan;
Defender detects EICAR;
CLFS files are created;
access occurs to \\127.0.0.1\C$\Windows\System32\phoneinfo.dll;
C:\Windows\System32\phoneinfo.dll appears;