RedSun Windows 0day: Defender Abused via Race to Write & Execute in System32

Windows Defender has become the center of a serious local privilege escalation story, and the uncomfortable twist is that the trusted security product is the one doing the dangerous write. According to CloudSEK’s RedSun research, a standard user can race Defender’s remediation workflow and trick it into writing an attacker-controlled binary into C:\Windows\System32, ultimately turning a cleanup path into a SYSTEM execution path . The result is a Windows 0day that does not require a kernel exploit, does not need UAC bypass, and does not rely on administrator rights. Instead, it abuses a trust failure in how Defender restores a file after detection, which makes the issue especially unsettling for defenders.

Background​

The core idea behind RedSun is simple to describe and alarming in practice: Defender is writing back a malicious file to a path that can be redirected underneath it. CloudSEK’s write-up says the flaw lives in the remediation path inside MpSvc.dll, the Malware Protection Engine used by MsMpEng.exe, where Defender restores a detected file without validating whether the original location has been swapped for a reparse point or junction . That detail matters because Defender runs with high privilege precisely so it can quarantine, remove, or restore files across the system. Once that trust boundary breaks, the antivirus becomes an attacker’s delivery mechanism.
This is not the kind of bug that comes from malformed input alone. It emerges from the interaction of several legitimate Windows features: Cloud Files placeholders, opportunistic locks, Volume Shadow Copy Service, and junction points . Each component is documented and expected. The exploit succeeds because the attacker arranges them into a sequence that creates a deterministic race window, then pivots Defender’s own write into a privileged directory.
The bigger historical lesson is familiar to anyone who has watched Windows privilege escalations evolve over the years: the most dangerous bugs often sit at the boundary between “security software” and “filesystem plumbing.” Defender is not just another app. It operates with system-level authority, scans early, and remediates under trust assumptions that ordinary software would never receive. That is why a logic flaw in the remediation path can be so potent. The product is doing exactly what it is designed to do, only in the wrong place and at the wrong time.
CloudSEK reports that the proof of concept was demonstrated on Windows 11 25H2 Build 26200.8246 with real-time protection enabled, and that the exploit remains highly reliable against fully patched systems at the time of writing . If accurate, that pushes RedSun into the class of issues that are more than theoretical. It is the kind of privilege escalation that security teams dread because it can be chained after initial access, lateral movement, or a low-value foothold.
The report also places RedSun in context with an earlier exploit from the same researcher, BlueHammer, which CloudSEK says Microsoft addressed as CVE-2026-33825 in April 2026, while RedSun remains unpatched . That comparison is useful because it shows a pattern: a researcher is studying a privileged subsystem, identifying trust failures, and publishing working proof-of-concepts before Microsoft has closed the loop.

---

What RedSun Actually Exploits​

At the heart of RedSun is a missing reparse-point validation. Defender detects a cloud-tagged malicious file, then attempts to restore it to its original path. According to the report, it does so without checking whether that path still resolves to the same directory tree it saw at scan time . In security terms, that is a classic time-of-check, time-of-use mistake, but with a modern Windows twist.
The attacker uses a batch OPLOCK to freeze Defender at a precise moment, then swaps the target directory with a mount point reparse that points into C:\Windows\System32 . When Defender resumes, the kernel resolves the redirected path transparently. Defender believes it is restoring a file to a benign working directory, but the write lands in a protected system location instead.

Why the write matters more than the detection​

This is not merely a delete-or-quarantine issue. The exploit depends on Defender’s own remediation logic placing an arbitrary binary on disk in a location that Windows treats as privileged. Once that binary lands in System32, the attacker no longer needs to fight the same protections that blocked the initial placement. The payload is now sitting where many service launchers and COM servers will trust it.
CloudSEK’s walkthrough says the placed binary is then triggered through the Storage Tiers Management COM server using CLSID {50d185b9-fff3-4656-92c7-e4018da4361d} . In other words, the exploit is not just about file placement; it is about translating placement into execution. That is why the chain is so dangerous.
A few points stand out:

• No admin rights are required to start the chain .
• No driver loading is needed.
• No kernel bug is required.
• The attacker leverages Defender’s own SYSTEM context.
• The final step converts a file-write primitive into interactive SYSTEM code execution.

That is a very compact privilege escalation chain by modern Windows standards.

---

How the Windows Primitives Fit Together​

RedSun is interesting because none of its ingredients are exotic by themselves. The exploit is a composition attack, and composition attacks are often what slip through review. CloudSEK explicitly calls out four building blocks: OPLOCKs, the Cloud Files API, VSS, and junction points .

Opportunistic locks as timing control​

OPLOCKs are the exploit’s timing tool. A batch OPLOCK lets the attacker hold a file open and get notified when another process tries to access it. In this case, that means Defender is forced to wait at exactly the point where the attacker wants the race to occur . That is a very different proposition from a flaky race exploit that depends on luck. Here, the race becomes engineered.

Cloud Files placeholders as bait​

Cloud Files placeholders are the bait. The attacker creates a placeholder file so Defender sees something that looks like a synchronizable cloud item rather than a normal local executable . The report says the placeholder is marked in sync, which suppresses hydration callbacks and helps the attacker control what Defender sees at scan time. That reduces noise and helps keep the chain deterministic.

VSS as a workflow signal​

The use of Volume Shadow Copy Service is subtle but clever. CloudSEK says the exploit monitors for new HarddiskVolumeShadowCopy objects to appear, using that as an indicator that Defender has entered remediation mode . Rather than guessing when the engine is ready, the attacker watches the system’s own object namespace. That makes the exploit more robust and shows a good understanding of how Defender stages its response.

Junctions as the final redirect​

The junction point is the actual redirect. Unlike symbolic links, junctions can be created by standard users in many scenarios, and they are resolved by the kernel during filesystem operations . When the target directory is swapped for a junction to C:\Windows\System32, Defender’s write follows the redirect automatically. The crucial failure is that the remediation path does not revalidate the target before writing.

---

Why Defender Becomes the Attacker​

The phrase “Defender becomes the attacker” is not hyperbole here; it is a fair description of the trust inversion. Defender is trusted to write or restore files because it is running as SYSTEM and is supposed to be correcting malicious changes. The exploit converts that authority into an unsafe file-placement primitive.
The report says the vulnerable path lives inside MpSvc.dll and that the original detection path is stored at scan time, then later reused verbatim for the restoration write without path revalidation . That is the critical design flaw. Security software is especially vulnerable to this class of problem because it must constantly make decisions based on stale filesystem state. If the object identity is not rechecked, the assumptions made during detection may no longer apply during remediation.

The missing validation step​

CloudSEK’s analysis suggests that a simple check such as FSCTL_GET_REPARSE_POINT or GetFinalPathNameByHandle before the write could have prevented the issue . That is the sort of detail that makes these bugs frustrating: the mitigation is conceptually straightforward, but the implementation path was apparently absent. In other words, this is not a lack-of-ability problem so much as a lack-of-verification problem.
This also explains why the bug is so compelling from a red-team perspective. It is not based on overflowing a buffer or corrupting memory. It is based on persuading a privileged service to trust a path that no longer means what it used to mean. That is a much quieter failure mode, and quiet failure modes are often harder to notice in testing.
The broader lesson is worth stating plainly:

• Trust must be revalidated at use time, not just at discovery time.
• Path identity cannot be assumed across asynchronous remediation.
• Privilege does not protect a process from logic errors.
• Security services need the same anti-race discipline as filesystems.

---

The Exploit Chain Step by Step​

CloudSEK’s walkthrough is important because it shows how the pieces are sequenced rather than merely named . The attack is not a single trigger. It is a choreographed sequence that uses Defender’s own behavior against it.

Step 1: Shadow copy monitoring​

The exploit begins by watching the object manager namespace for new HarddiskVolumeShadowCopy devices. That gives the attacker a signal that Defender has moved into the remediation phase. This is a smart choice because it ties the exploit to an observable system event instead of a guess.

Step 2: Dropping the trigger file​

The attacker writes the EICAR test string in reverse inside the binary, then reconstructs it at runtime and stores it in a file named TieringEngineService.exe under %TEMP% . Opening the file with FILE_EXECUTE causes Defender to inspect it and start the detection workflow. The choice of filename matters because it lines up with the later execution target.

Step 3: OPLOCK synchronization and directory swap​

Once Defender is engaged, the attacker acquires a batch OPLOCK on the target file. When Defender attempts access, the lock breaks and signals the exploit to move. The original file is deleted with POSIX semantics, a Cloud Files placeholder is created, and the directory is renamed away and rebuilt as a junction to System32 .

Step 4: Defender completes the privileged write​

Defender resumes its write operation, still believing it is restoring the original path. The kernel resolves the junction and the file is written directly into C:\Windows\System32\TieringEngineService.exe as SYSTEM . This is the pivot point: the attacker no longer needs filesystem tricks. The payload is now in a launchable privileged location.

Step 5: Execution via Storage Tiers Management​

The exploit then activates the Storage Tiers Management Engine COM server via CLSID {50d185b9-fff3-4656-92c7-e4018da4361d} so that TieringEngineService.exe is executed . Because the binary has been replaced, the attacker’s payload runs as SYSTEM. The payload checks whether it is running as LocalSystem, retrieves the victim session ID, and launches an interactive shell in the user’s session.
That final move is the reason the exploit is more than an LPE demonstration. It is a complete end-to-end path from low privilege to interactive SYSTEM.

---

The Role of MpSvc.dll and the Trust Boundary​

CloudSEK’s report ties the root cause to MpSvc.dll, which it describes as the core Malware Protection Engine loaded by MsMpEng.exe . That places the issue squarely inside the part of Defender that makes scan, detection, and remediation decisions. If the engine trusts stale path data, every downstream action inherits that mistake.

Why this class of bug is so dangerous​

Security products often sit at the top of the trust hierarchy. They are designed to inspect, modify, quarantine, restore, and delete files that other processes cannot safely touch. That means a logic flaw in one of those systems is worse than the same flaw in a regular application. A regular app that writes to the wrong place can misbehave; a security app that does it can authorize the misbehavior.
The report’s function trace is telling. It claims no function in the remediation chain performs a reparse check before the write, and that the path is passed verbatim from detection to restoration . If accurate, that means the vulnerability is not hidden in a bizarre edge case. It is a straightforward failure to reassert ownership of a critical decision point.

What should have happened​

A robust remediation engine would likely:

• Open the target by handle rather than trusting a stale string path.
• Revalidate the target’s final resolved location.
• Refuse to write across a changed reparse boundary.
• Confirm that the destination still matches the original object identity.

Instead, the reported behavior treats the path as if it were immutable. That is the kind of assumption that works right up until it catastrophically does not.

---

Enterprise Impact​

For enterprises, the practical issue is not only whether RedSun is patched. It is whether a low-privilege foothold can be turned into a high-value compromise on systems that rely heavily on Defender for baseline protection. That makes the bug especially relevant for managed endpoints, admin workstations, and environments where local user access is common.
CloudSEK says the attack works on supported Windows versions with Defender enabled and that no elevated privileges are required . In enterprise terms, that means any user shell, RDP session, or sandbox escape that yields a standard account may be enough to escalate further. Once SYSTEM is obtained, the attacker can tamper with security controls, dump credentials, persist more quietly, or pivot laterally.

Why managed fleets should care​

The exploit’s reliability also matters. If an LPE is flaky, attackers often reserve it for targeted use. If it is repeatable, it becomes a candidate for broad post-exploitation tooling. That is why even a local bug can have wide operational consequences. Enterprises do not need the vulnerability to be wormable to suffer serious damage from it.
The monitoring guidance in the report is worth attention as well. CloudSEK recommends watching for VSS enumeration by non-system processes, unusual CfRegisterSyncRoot activity, junction creation inside %TEMP%, and unexpected writes to System32 originating from MsMpEng.exe . Those are not generic Windows behaviors. They are a very specific behavioral profile that blue teams can use to hunt for exploit staging.
A practical enterprise response would likely include:

• Inventorying endpoints where Defender is the primary AV control.
• Reviewing telemetry for suspicious Cloud Files registrations.
• Alerting on junction creation in writable temp locations.
• Watching for Defender-originated writes to protected system paths.
• Prioritizing containment on hosts where untrusted local users exist.

---

Consumer Impact​

For consumers, the story is a little different. A home user is less likely to be targeted with this exact chain unless an attacker already has local access or can trick the user into launching a prepared file. Still, the implications are serious because standard user accounts are common, and consumer systems often run with broad trust in security software.
This is the sort of issue that can be abused after phishing, after a malicious installer has landed, or after a low-privilege foothold from another bug. Once initial access exists, RedSun gives an attacker a clean method to jump to SYSTEM. That changes the economics of post-exploitation substantially.

Why consumer systems still matter​

Consumers also tend to rely more heavily on built-in protection and less on layered enterprise controls. That makes Defender’s own trust boundaries more important, not less. If the built-in antivirus can be coerced into writing to System32, then the protective layer itself becomes part of the attacker’s playbook.
There is also a trust effect that should not be underestimated. Users expect the security product to be the last line of defense. When that line becomes the mechanism for compromise, confidence erodes quickly. Perception matters in security because trust determines how users respond to warnings, prompts, and remediation advice.

---

Comparisons With Other Windows Vulnerabilities​

RedSun fits into a broader family of Windows issues where object identity, filesystem semantics, and privileged services intersect. It is not the same as a kernel memory corruption bug, and it is not a browser sandbox escape. It is a logic flaw in a privileged system service that trusts stale state.
That distinction matters because Windows defenders often triage based on component class. Kernel bugs feel high-risk, and they are. But a privileged service bug can be just as severe when it hands the attacker SYSTEM through a supported workflow. This is especially true when the vulnerable component is installed everywhere and runs continuously.

What makes RedSun unusual​

A few characteristics make RedSun stand out:

• It turns defensive remediation into an offensive primitive.
• It depends on filesystem state changes, not malformed code.
• It uses documented Windows features rather than obscure exploit-only APIs.
• It appears to work against fully patched systems.
• It does not need a kernel exploit to reach SYSTEM.

That combination makes it unusually elegant from an attacker’s point of view and unusually awkward from a defender’s point of view. There is no single obvious setting that disables the problem without weakening Defender’s protection model more broadly.

---

Strengths and Opportunities​

The upside for defenders is that this issue is unusually well mapped at the conceptual level. CloudSEK’s analysis identifies the trust failure, the race window, the privileged write, and the final execution step. That makes it easier to build detections, prioritize endpoints, and pressure vendors for a fix.

• The exploit chain is behaviorally distinctive, which helps with detection.
• Defender-originated writes to C:\Windows\System32 are a strong anomaly signal.
• The use of Cloud Files sync roots narrows the suspicious process set.
• OPLOCK plus junction timing gives defenders a clear hunting pattern.
• The issue reinforces the case for handle-based revalidation in remediation logic.
• Enterprises can use the report to review broader trust-boundary assumptions.
• The proof-of-concept is concrete enough to support control validation and tabletop exercises.

---

Risks and Concerns​

The most immediate concern is that the flaw sits in a security product that many organizations implicitly trust as a compensating control. If Defender itself can be turned into a file-dropper for System32, then standard hardening assumptions need to be revisited.

• A local foothold can be converted into SYSTEM execution.
• The exploit appears highly reliable, which raises abuse potential.
• No patch is reported at the time of writing .
• Monitoring and EDR tools may miss the logic flaw if they focus only on memory corruption.
• Temporary mitigation ideas may reduce Defender effectiveness if applied broadly.
• Attackers with local access may use the bug as a post-exploitation escalator.
• Security teams may underestimate the issue because it is “just local,” even though local SYSTEM is often enough to own a machine.

---

What to Watch Next​

The most important near-term question is whether Microsoft acknowledges the issue publicly and ships a remediation that changes how Defender validates restore destinations. If that happens, the fix will likely reveal a lot about how the remediation pipeline is designed and where the trust boundary is enforced.
A second question is whether researchers or attackers can adapt the same pattern to other privileged Windows services that restore, repair, or normalize files. That is the broader danger: once the method is understood, the individual vulnerability becomes a template. RedSun may be one bug, but the design lesson could apply to several other code paths.
A third issue is operational. Enterprises will need to decide whether they can safely use enhanced monitoring to detect exploitation attempts without overreacting to benign Cloud Files or junction behavior. That balance is always difficult, and it will be especially delicate here because many legitimate Windows components legitimately touch the same APIs.
What to watch next:

• Microsoft’s response, advisory language, or eventual CVE assignment.
• Any revision to Defender’s remediation logic or path validation behavior.
• Hunting guidance from EDR vendors based on the reported indicators.
• Signs of copycat exploitation using similar OPLOCK and reparse techniques.
• Evidence that other privileged restore workflows share the same design weakness.

The larger story is not just that one Defender path is flawed. It is that modern Windows security still depends on continuous revalidation of object identity under concurrency, and that is hard to get right. When a security product writes based on stale assumptions, the attacker does not need to break the product’s defenses. They only need to make the product faithfully execute the wrong decision. That is why RedSun is more than a clever exploit; it is a reminder that trust boundaries inside operating systems are only as strong as the checks that protect them at the moment of use.

---

Source: CloudSEK RedSun: Windows 0day when Defender becomes the attacker | CloudSEK