Opening position

RedSun describes a defect in Windows Defender's remediation pipeline where the act of cleaning a detected file became a primitive for arbitrary writes into protected system locations. The component that exists to remove malicious content was the component that delivered it. The defender became the delivery mechanism.

This is not a detection failure. Detection worked. The malicious content was identified, classified, and routed for action. The failure occurred after detection, inside the trusted remediation path that runs at a higher privilege level than the process being defended against. The control that fired produced the outcome the control was meant to prevent.

Treat this as a boundary failure inside a privileged service. The exposure is not theoretical malware evasion. The exposure is that an enforcement component held write capability into locations the original threat could not reach on its own. Whatever the threat could influence, the remediation path could escalate.

What actually failed

The observable behaviour: a remediation action performed by Windows Defender resulted in a file write into a system-protected path. The write was performed by the security service, not by the originating process. From the operating system's perspective, the write was legitimate because it originated from a trusted, signed, high-privilege component executing its declared function.

The distinction matters. The file system did not break. Access control did not break. The privilege model behaved exactly as designed. A SYSTEM-level service issued a write, and the operating system honoured it. The boundary that failed was inside the remediation logic, where attacker-influenced input was allowed to determine where a privileged action would land.

What is not confirmed: the specific input vector RedSun relied on, the precise file path written, the persistence outcome, and whether exploitation required prior code execution on the host. Treat the mechanism as the finding. Treat scope, reliability, and chain prerequisites as not confirmed unless explicitly stated in source material.

Why it failed

The remediation path treated its own action as inherently safe because the process performing it was trusted. Trust was assigned to the executing identity, not to the operation being performed. Once the service held SYSTEM context and a write capability, the destination of that write was governed by remediation logic rather than by an independent authorisation check against the target path.

This is the core defect: privilege was bound to the process, not to the operation. A trusted process performing an attacker-influenced operation is not a trusted operation. The remediation routine did not re-validate the target of its write against the threat model of "what should a cleanup action ever be permitted to touch." There is no evidence of an enforcement boundary between "Defender is allowed to act" and "Defender is allowed to act here, on this path, in this way."

The behaviour is consistent with a confused deputy condition inside a SYSTEM service. The deputy held authority the caller did not. The caller supplied, directly or indirectly, the parameter that steered the deputy's authority to a destination the caller could not reach unaided. Whether the input vector was a crafted file, a controlled path, a symbolic link, or another redirection primitive is not confirmed. The class of failure is. Controls that delegate destination selection to attacker-reachable input, while executing under SYSTEM, are ineffective by construction.

Mechanism of failure

The failure is structural, not incidental. A SYSTEM-level service held a write capability that was steered by input the service did not own. The remediation routine treated its destination as a parameter rather than as a privilege decision. Once the destination became a parameter, the privilege of the writer no longer described the privilege of the write. The operation inherited SYSTEM authority while its target was selected through logic exposed to lower-trust influence. The boundary that should have held was the one between the act of cleaning and the location of the cleaning. That boundary did not exist as an enforced control. It existed only as an assumption inside the remediation path.

The drift here is the gap between declared function and effective capability. Defender's declared function is to remove malicious content from the system. Its effective capability, given the defect, was to write content into system-protected paths under SYSTEM context, with the destination shaped by attacker-reachable conditions. Declared function and effective capability diverged. The operating system enforced the privilege of the caller. Nothing enforced the constraint that a remediation write should only ever land inside the set of paths a remediation action is permitted to touch. There is no evidence in the described mechanism that such a permitted-set existed as an enforced policy. If it had existed and been enforced, the write would have been refused at the boundary.

The defect is the class known as confused deputy operating inside a privileged service. A deputy with authority acts on behalf of a caller without authority, and the caller steers the deputy's authority to a target the caller could not reach directly. The mechanism does not require the caller to escalate. It requires the caller to supply, directly or indirectly, the parameter that determines where the deputy's authority lands. The specific input vector is not confirmed. The class is. Any control that binds privilege to a process identity, then accepts attacker-reachable input as a destination selector for a privileged operation, produces the same outcome regardless of the surface it sits on.

Expansion into parallel pattern

The pattern is not specific to anti-malware. It applies to any privileged component whose declared function involves acting on files, paths, registry locations, or other addressable resources where the address is influenced by content the component is processing. Backup agents that restore files based on metadata embedded in the backup. Update services that resolve target paths from manifests delivered over the network. Installer frameworks that honour relative or symbolic path elements supplied by package contents. Endpoint agents that quarantine, restore, or rewrite files based on rule output. Each of these holds SYSTEM or equivalent context. Each of them, if it accepts the destination of its privileged action as data rather than as a constrained policy, expresses the same defect.

The shared mechanism is that the privileged component validates that it is allowed to act, and does not validate that it is allowed to act on this specific target through this specific operation. Authorisation is performed once, at the identity layer, and is treated as transitive across every operation the component performs for the duration of its execution. That is not a trust model. That is an absence of one. Trust must be evaluated per operation, against the operation's actual destination, not inherited from the fact that a signed binary is running. Identity is necessary. It is not sufficient.

The pattern also exposes a structural weakness in defender-class software specifically. Defender-class components are deliberately positioned with elevated authority because they must reach into locations user-mode threats cannot. That same positioning means any input-influenced operation they perform is, by design, capable of reaching those locations. The privilege gap that makes the component effective as a defender is identical to the privilege gap that makes the component dangerous when its operations can be steered. The control surface and the attack surface share boundaries. A defect inside that surface does not produce a small failure. It produces a write primitive at the highest privilege the host supports.

Hard closing truth

A control that holds SYSTEM authority and accepts attacker-influenced input as a destination selector is not a control. It is a privileged primitive waiting to be addressed. The presence of detection, signing, and trust attestation does not change this. Those properties describe the component. They do not describe the operations the component performs. Until each privileged operation is independently authorised against its actual target, identity-based trust is the only enforcement, and identity-based trust is exactly what the confused deputy class defeats.

The operator position is that privileged remediation paths must enforce destination policy as a separate layer from process identity. The set of paths a remediation action is permitted to write to is a finite, declarable set. It is not the same as the set of paths the SYSTEM account is permitted to write to. Treating those two sets as equivalent is the design error. A defender that can write anywhere SYSTEM can write is not bounded by its declared function. It is bounded only by its caller's input. That is the wrong boundary.

RedSun is not a story about Defender failing to detect. Detection worked. RedSun is a demonstration that the highest-privilege component on the host carried a write capability whose destination was not enforced as policy. Anything with that shape, on any platform, under any vendor, produces the same outcome when its input is shaped against it. The defender is not exempt from the threat model. The defender is part of it. Treat every privileged enforcement component as a candidate primitive until its operations are bounded independently of its identity. If the operation is not bounded, the identity does not matter.