RedSun: Windows 0day when Defender becomes the attacker

A logic flaw in Windows Defender’s remediation path (MpSvc.dll) allows a local unprivileged user to race a restore operation and redirect Defender to write an attacker-controlled binary into C:WindowsSystem32, enabling SYSTEM code execution. The public PoC exploit “RedSun” chains Cloud Files placeholders, a batch OPLOCK, VSS monitoring, and a junction (mount point) swap to reliably achieve elevation without kernel exploits or admin privileges. #RedSun #WindowsDefender

Keypoints

RedSun exploits a missing reparse point validation in MpSvc.dll so Defender writes files back to stored detection paths without checking for junctions.
The exploit combines Cloud Files placeholders, batch OPLOCKs, Volume Shadow Copy monitoring, and mount point reparse (junction) swaps to create a deterministic race window.
By replacing the attacker’s working directory with a junction to C:WindowsSystem32 at the precise moment Defender resumes its write, an attacker-controlled binary is written into System32 as SYSTEM.
The planted binary (TieringEngineService.exe) is executed via DCOM activation of the Storage Tiers Management COM server (CLSID {50d185b9-fff3-4656-92c7-e4018da4361d}), yielding an interactive SYSTEM shell.
The vulnerability requires only local, unprivileged access and works on fully patched Windows (confirmed on Windows 11 25H2 Build 26200.8246); no kernel exploit or administrator interaction is needed.
No patch or CVE had been issued at time of writing; recommended mitigations focus on behavioral detections (VSS enumeration, unexpected CfRegisterSyncRoot, junctions in %TEMP%, and MsMpEng.exe writes to System32).

MITRE Techniques

[T1068 ] Exploitation for Privilege Escalation – The attacker leverages a logical flaw in Defender’s remediation to escalate to SYSTEM by forcing a write into System32 (‘…allows a standard user to redirect Defender’s own restore write into C:WindowsSystem32, resulting in elevated code execution.’)
[T1574 ] Hijack Execution Flow – Filesystem reparse/junction swap is used to redirect Defender’s trusted write path into C:WindowsSystem32 (‘…the working directory is then renamed away and recreated as a junction point targeting ??C:WindowsSystem32.’)
[T1106 ] Native API – The exploit relies on low-level NT/Windows APIs and object manager monitoring (Device/NT namespace and VSS device objects) to detect shadow copies and manipulate filesystem objects (‘…monitors the object manager directory for the appearance of a new shadow copy device indicating Defender has reached the remediation stage.’)
[T1218 ] Signed Binary Proxy Execution (Abuse of Trusted Component) – The Storage Tiers Management COM server is invoked to execute the replaced binary as SYSTEM, abusing a legitimate Windows component to run attacker code (‘…activates CLSID {50d185b9-fff3-4656-92c7-e4018da4361d} via DCOM the Storage Tiers Management Engine COM server which executes TieringEngineService.exe.’)

Indicators of Compromise

[File Name ] attacker payload / AV trigger – TieringEngineService.exe (temp drop and final payload)
[DLL / Binary ] Defender components involved – MpSvc.dll, MsMpEng.exe (remediation path and writer)
[GUID / CLSID ] COM activation target – {50d185b9-fff3-4656-92c7-e4018da4361d} (Storage Tiers Management COM server)
[Named Pipe ] post-execution IPC – pipeREDSUN (used to read target session ID)
[NT Device / Shadow Copy ] VSS monitoring context – DeviceHarddiskVolumeShadowCopy* (shadow copy device enumeration to detect remediation stage)
[File Path ] target write destination – C:WindowsSystem32 (attacker-controlled binary written here by Defender)
[API / Component ] Cloud Files artifacts – CfCreatePlaceholders / CfApi.dll and cldapi.dll (used to create placeholders and register sync roots)