RedSun: Windows 0day when Defender becomes the attacker

Executive Summary

A logic flaw in Windows Defender's file remediation path allows a standard user to redirect Defender's own restore write into C:\Windows\System32, resulting in elevated code execution. No administrative privileges, UAC bypass, or kernel exploit are required.

When Defender detects a cloud-tagged malicious file, it writes the file back to its original detection path without validating whether that path has been replaced with a junction point. An attacker races this window using a batch OPLOCK, swaps the target directory with a mount point reparse to C:\Windows\System32, and Defender completes the write. The placed binary is then executed via the Storage Tiers Management COM server. 

Introduction

Windows Defender is installed and enabled by default on every modern Windows system. It operates at a privileged position within the OS receiving early notification of file system events, scanning files before execution, and performing remediation operations as SYSTEM. This level of trust is necessary for an antivirus to function. It is also, as this research demonstrates, exploitable.

A security researcher operating under the alias Chaotic Eclipse released a fully functional Windows local privilege escalation exploit publicly. The exploit, which now is being called as RedSun, targets a logic flaw in Windows Defender's file remediation path that allows a standard unprivileged user to achieve SYSTEM level code execution on a fully patched Windows system.

The root cause is a missing reparse point validation in MpSvc.dll  the core Malware Protection Engine loaded by MsMpEng.exe. When Defender detects a malicious file carrying Cloud Files attributes, it attempts to restore the file back to its original detection path. This write operation is performed without verifying whether the target path has been redirected via a junction point. By timing this restore operation against a batch OPLOCK and substituting the target directory with a mount point reparse to C:\Windows\System32, an attacker can cause Defender to write an arbitrary binary directly into System32 on their behalf.

The vulnerability was confirmed on Windows 11 25H2 Build 26200.8246 with real time protection fully enabled and may affect other versions of Windows as well.

Technical Background

RedSun chains four legitimate, documented Windows features together to create the exploit primitive. None of these components are individually vulnerable, the flaw emerges from how they interact under specific timing conditions.

Opportunistic Locks (OPLOCKs)

An opportunistic lock is a mechanism that allows a process to request notification when another process attempts to access a file it holds open. A batch OPLOCK specifically coalesces multiple file open and close operations, and breaks notifying the lock holder the moment another process attempts to access the locked file. In this exploit, the attacker uses a batch OPLOCK as a precise timing instrument: it holds Defender in a blocked state at an exact, reproducible point in its execution, creating a deterministic race window rather than a timing dependent one.

Cloud Files API

The Windows Cloud Files API (CfApi.dll) provides the infrastructure for cloud sync providers such as OneDrive. It allows a process to register a directory as a sync root and create placeholder files lightweight stubs that represent remote content not yet downloaded to disk. A placeholder marked with CF_PLACEHOLDER_CREATE_FLAG_MARK_IN_SYNC signals to the system that the file is up to date, suppressing hydration callbacks. In this exploit, a Cloud Files placeholder is created in the attacker's working directory to present a controlled file to Defender's scanner.

Volume Shadow Copy Service (VSS)

VSS is a Windows service that creates point in time snapshots of volumes. When Defender detects a malicious file, it creates a VSS snapshot to preserve a copy of the file for remediation purposes. This snapshot is mounted as a device object under \Device\HarddiskVolumeShadowCopy* and is accessible via the NT object namespace. The exploit monitors the object manager directory for the appearance of a new shadow copy device indicating Defender has reached the remediation stage before proceeding.

Junction Points (Mount Point Reparse)

A junction point is a type of reparse point that redirects filesystem operations from one directory to another. Unlike symbolic links, junction points can be created by standard users without elevated privileges. In this exploit, the attacker's working directory is replaced with a junction pointing to \??\C:\Windows\System32 after the OPLOCK fires. Any subsequent file write operation targeting the working directory is transparently redirected into System32 by the kernel without the writing process having any awareness of the redirection.

Exploit Walkthrough

The following walkthrough documents how the exploit chain operates. The analysis is based on the original unmodified PoC compiled and executed against a clean Windows virtual machine with real time protection fully enabled.

Step-1  Shadow Copy Monitoring

Before the exploit begins, a background thread opens the NT object manager directory \Device and takes a snapshot of all currently existing HarddiskVolumeShadowCopy* device objects. It then polls continuously, comparing against the initial snapshot, waiting for a new shadow copy to appear indicating Defender has entered its remediation workflow.

Step-2  EICAR Drop and AV Trigger

The EICAR test string is stored reversed in the binary to avoid static detection by the host AV. At runtime it is reversed in memory and written to a temp file named TieringEngineService.exe inside a working directory under %TEMP%. Opening the file with FILE_EXECUTE access causes Defender to scan it, triggering the detection and remediation workflow.

Step 3 OPLOCK Synchronisation and Junction Swap

A batch OPLOCK is acquired on the target file. When Defender attempts to access the file during remediation, the OPLOCK breaks signaling the main thread. At this precise moment, the original file is deleted via FileDispositionInformationEx with POSIX semantics, and a Cloud Files placeholder is created in its place via CfCreatePlaceholders. The working directory is then renamed away and recreated as a junction point targeting \??\C:\Windows\System32.

Step 4 Defender Writes Payload to System32

With the junction in place, Defender resumes its remediation write targeting what it believes is the original detection path. The kernel transparently resolves the junction, and Defender writes the attacker controlled binary directly into C:\Windows\System32\TieringEngineService.exe as SYSTEM. No reparse point check is performed anywhere in the write back chain, as confirmed by reverse engineering of MpSvc.dll.

Step 5 SYSTEM Shell via Storage Tiers COM Server

The exploit activates CLSID {50d185b9-fff3-4656-92c7-e4018da4361d} via DCOM the Storage Tiers Management Engine COM server which executes TieringEngineService.exe. Since the binary has been replaced, the attacker's payload runs as SYSTEM. The payload detects the SYSTEM context via IsRunningAsLocalSystem(), reads the target session ID from a named pipe (\\pipe\REDSUN), and spawns conhost.exe in the user's active session delivering an interactive SYSTEM shell.

Why does the vulnerability exist ?

MpSvc.dll is the core Malware Protection Engine the binary that MsMpEng.exe loads and delegates all scan, detection, and remediation logic to. This is where the vulnerable write back path lives. The goal is to trace the exact code path responsible for the file restoration write, confirm that no reparse point validation exists anywhere in that path

To understand precisely where the vulnerability lives, we try to find the Defender's remediation configuration handler, the function that reads the rollback policy and dispatches the file write back operation.

Remediation Config Handler

EnableLocalFileRollback configuration value is read and compared against the cached state. On a state change, the rollback is dispatched immediately  passing the original detection path downstream without any reparse point validation. The path is trusted unconditionally.

This function is a generic wrapper around the internal MpConfigGetValue API (exported by MpClient.dll). It reads a named DWORD configuration value and has no side effects. It is not vulnerable in isolation  the vulnerability is the absence of any validation after this function returns:

The following table traces every function in the complete call chain from detection to write back. No function in the chain calls any API that could detect a junction or reparse point redirect:

The detection file path is stored at scan time and used verbatim as the write destination at write back time. No function in the chain between these two points validates whether the path still resolves to the same filesystem object. 

A single call to DeviceIoControl(FSCTL_GET_REPARSE_POINT) or GetFinalPathNameByHandle before the write would have prevented this vulnerability.

Impact & Mitigations

RedSun affects any Windows system with Windows Defender enabled and the cldapi.dll component present  which covers Windows 10, Windows 11, and Windows Server 2019 and later. The exploit functions with approximately 100% reliability even against systems with the latest April 2026 updates applied. The attack requires only local, unprivileged access; no kernel exploit, no driver, no administrator interaction.

As of the time of writing, no patch exists for RedSun. Microsoft has not assigned a CVE or issued a fix. BlueHammer, the earlier exploit by the same researcher, was addressed as CVE-2026-33825 in April 2026 Patch . RedSun is an independent attack vector and remains fully unpatched on all supported Windows versions.

Until a patch is available, defenders should focus on behavioral detection:

• Monitor for VSS enumeration from non system processes. Calls to NtQueryDirectoryObject targeting HarddiskVolumeShadowCopy* from user space processes have no legitimate use case outside of system and backup tooling.
• Alert on CfRegisterSyncRoot from untrusted processes. Cloud Files sync root registration outside of known cloud sync software such as OneDrive or Dropbox is a strong indicator of this attack pattern.
• Monitor junction creation in %TEMP%. A standard user creating a mount point reparse in a temporary directory immediately following OPLOCK acquisition is a high confidence signal.
• Alert on unexpected writes to C:\Windows\System32 originating from MsMpEng.exe. The write in this exploit originates from Defender's own process  conventional file integrity monitoring should flag this as anomalous.
• Disable cloud delivered protection as a temporary measure on high risk isolated systems only this is not recommended as a general control as it degrades Defender's detection capability significantly.

References

• https://github.com/Nightmare-Eclipse/RedSun