Microsoft patched BlueHammer thirteen days ago. Today Chaotic Eclipse dropped RedSun. Same researcher, same target surface, entirely different primitive, same outcome: SYSTEM. The patch fixed an oplock. The class remained untouched. Here’s what that means.

Background: The Context

BlueHammer was published April 3rd after MSRC declined to process the report — reportedly over a missing video PoC. Let that sink in. A local privilege escalation to SYSTEM via Defender was closed as invalid because the researcher didn’t attach a screen recording. Microsoft eventually patched it as CVE-2026-33825 (7.8 CVSS), crediting Zen Dodd and Yuanpei XU of HUST/Diffract. Not Chaotic Eclipse. The researcher who found it.

RedSun came out today. The source is signed with PGP. The comment in the code reads "SERIOUSLYMSFT" — that’s the Cloud Files provider name registered by the PoC. That name is not an accident.

The researcher’s published statement: “I will personally make sure that it gets funnier every single time Microsoft releases a patch.”

No CVE assigned for RedSun as of this writing. No patch.

The Primitive: Step by Step

The full chain lives in RedSun.cpp at github.com/Nightmare-Eclipse/RedSun. The attack requires local code execution — this is LPE, not RCE. But “requires local execution” increasingly means “requires a single browser tab with a JavaScript engine.”

Step 1: Register a Cloud Files sync root

CfRegisterSyncRoot(syncroot, &cfreg, &syncpolicy,
    CF_REGISTER_FLAG_DISABLE_ON_DEMAND_POPULATION_ON_ROOT)

CfRegisterSyncRoot() is the same API OneDrive and Dropbox use to tell Windows “this directory is backed by a cloud provider.” The provider name in the PoC is "SERIOUSLYMSFT". Hydration policy is CF_HYDRATION_POLICY_PARTIAL, hardlink policy is CF_HARDLINK_POLICY_ALLOWED. Standard sync provider setup — nothing suspicious to the kernel at registration time.

Step 2: Create a cloud placeholder

CfCreatePlaceholders() with flags CF_PLACEHOLDER_CREATE_FLAG_MARK_IN_SYNC | CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE drops a placeholder file into the sync root. This file carries Cloud Files extended attributes that mark it as a remote-backed file pending hydration. This EA tag is what gets Defender’s attention later.

Step 3: Connect as the sync provider

CfConnectSyncRoot() with CF_CONNECT_FLAG_REQUIRE_PROCESS_INFO | CF_CONNECT_FLAG_REQUIRE_FULL_FILE_PATH. The attacker process is now the registered sync provider for this root. The kernel knows who to call for hydration callbacks.

Step 4: Stamp the reparse point

FSCTL_SET_REPARSE_POINT with IO_REPARSE_TAG_MOUNT_POINT is issued against the sync root directory. The mount point target: \??\C:\Windows\System32.

Mount point reparsing is a kernel-level directory substitution. Any I/O path that traverses the sync root directory now resolves to System32 at the object manager layer. This is not a symlink in userspace. The kernel’s I/O manager performs the substitution before the path reaches the filesystem driver — it applies to any process, including SYSTEM-level ones, that opens a path through this directory.

Step 5: Defender scans the placeholder

Windows Defender, running as SYSTEM, encounters the Cloud Files placeholder and sees content it wants to remediate. This is the intended Defender behavior — scan cloud-backed files for threats. What’s not intended is what happens next.

When Defender’s remediation engine encounters a file with a Cloud Files EA tag, it doesn’t simply delete or quarantine. It attempts to restore or resolve the file’s tracked origin path. That tracked path runs through the sync root directory. The sync root directory now has a mount point reparse to \??\C:\Windows\System32. Defender follows the path. The kernel reparse fires. Defender is now writing into System32.

Steps 6–7: SYSTEM binary in, service launched

The source shows CopyFile(mx, mx2, FALSE) where mx is the PoC binary and mx2 is %WINDIR%\System32\TieringEngineService.exe. Defender, operating under its SYSTEM token, overwrites TieringEngineService.exe with the attacker’s payload.

LaunchTierManagementEng() then triggers the service. TieringEngineService runs under SYSTEM via the service infrastructure. Escalation complete.

The PoC also enumerates VSS shadow copies via NtQueryDirectoryObject scanning \Device for HarddiskVolumeShadowCopy entries. This appears to be an alternate escalation path or cleanup mechanism — the source makes it available but RedSun’s primary chain doesn’t depend on it.

Contrast: BlueHammer vs. RedSun

The BlueHammer chain is architecturally different at every layer except the outcome.

BlueHammerRedSun
Entry pointWindows Update Agent COM (wuapi.h)Cloud Files API (CfRegisterSyncRoot)
TriggerPending Defender signature update detectedDefender scan of cloud placeholder
Steer mechanismOplock on VSS snapshot mount stalls Defender SYSTEM threadReparse point redirects Defender write path
Privileged primitive exploitedDefender reads SAM/SYSTEM/SECURITY hives from mounted snapshotDefender writes through attacker-controlled directory
Credential accessoffreg.h offline registry → NTLM hash extractionN/A
Escalation pathSamiChangePasswordUser → LogonUserEx → token dup → CreateServiceOverwrite TieringEngineService.exe → service launch
CleanupSamiChangePasswordUser again to restore original hash—
PatchedYes (CVE-2026-33825, Antimalware Platform 4.18.26050.3011)No

BlueHammer steers when Defender acts. An oplock-induced timing window keeps a VSS snapshot mounted at the exact moment Defender’s SYSTEM thread tries to access it. The hives are readable. The hash comes out.

RedSun steers where Defender writes. The mount point reparse is in place before the scan. When Defender’s remediation logic follows the tracked path back to the file’s origin, it walks straight into System32. There’s no race. There’s no timing. The kernel reparse is deterministic.

BlueHammer patch: fixed the specific oplock+VSS interaction. The fix validates snapshot mount state during the sensitive window. That mitigation is complete, scoped, and irrelevant to RedSun, which doesn’t touch VSS, oplocks, or update workflows at all.

The Class

This is the architectural argument worth understanding.

Both bugs exploit the same root condition: a SYSTEM-privileged component (Defender) takes action based on attacker-influenced input without validating that the action’s consequences are contained to the expected namespace.

Defender has to scan files. It has to remediate them. It runs as SYSTEM because it has to modify protected paths. That’s load-bearing. You can’t fix it by demoting Defender. The question is whether Defender validates, at remediation time, that the paths it writes to are what it thinks they are.

The Cloud Files subsystem is legitimately complex. Placeholder files, hydration callbacks, sync root registration — this is not obscure API abuse. OneDrive uses CfRegisterSyncRoot. Dropbox uses it. Box uses it. The kernel’s Cloud Files filter driver (cldflt.sys) treats any registered sync provider identically because it has to — that’s the contract the API establishes.

The reparse point is also legitimate. Mount points are a documented Windows feature. NTFS supports them. The kernel’s I/O manager resolves them by design.

The vulnerability is the combination: Defender follows a path through infrastructure it doesn’t control, without confirming that path doesn’t resolve somewhere harmful, and then writes. The chain only works because Defender never asks “does this write destination make sense given the file I’m remediating?”

Patching RedSun requires Defender’s remediation engine to validate write targets against a canonicalized expected namespace before acting. That’s a non-trivial change to code paths that are security-critical and performance-sensitive. The BlueHammer patch was surgical — fix the oplock interaction. A class fix requires rethinking how Defender validates its own output paths. Microsoft hasn’t done that yet. Hence the “every single time” promise.

Watch for a third variant. The researcher has demonstrated they understand the class, not just the specific primitives. Fixing one more specific primitive will not close the loop.

What To Do

No patch exists for RedSun as of April 16, 2026. The BlueHammer fix (Antimalware Platform 4.18.26050.3011) does not apply — the primitives are entirely different.

RedSun requires local code execution first. That narrows the realistic threat path:

  1. Initial access via browser RCE, macro execution, or similar userspace compromise
  2. RedSun for SYSTEM escalation
  3. Lateral movement / persistence

Mitigations available now:

  • Attack Surface Reduction rules — Microsoft’s ASR rules can restrict legitimate but dangerous API surface. Rules targeting process creation from Office applications and script interpreters raise the bar for the initial compromise that would precede RedSun.

  • Controlled Folder Access — Won’t block RedSun directly. Defender itself is exempt from CFA restrictions (it has to be). But CFA can prevent the attacker’s initial payload from writing to common staging locations.

  • Audit Cloud Files provider registrations — CfRegisterSyncRoot from processes that aren’t OneDrive, OneDrive Business, Dropbox, Box, or your organization’s known sync clients is anomalous. Log it. Alert on it. The PoC registers a provider named "SERIOUSLYMSFT" — that string will not appear in a legitimate deployment.

  • Monitor FSCTL_SET_REPARSE_POINT on Cloud Files roots — A mount point reparse being stamped on a directory registered as a sync root is a high-fidelity indicator. This combination does not appear in normal operations.

  • Watch TieringEngineService.exe — Unexpected modification of %WINDIR%\System32\TieringEngineService.exe is an endpoint indicator. Hash it. Alert on changes. The RedSun PoC overwrites it directly.

EDR platforms with kernel-level visibility into reparse point operations and Cloud Files API calls should be able to detect this chain before the write lands. The registration and reparse steps leave observable artifacts. The question is whether your detection coverage extends that deep into NTFS/Cloud Files interactions.

If you’re running an enterprise Defender estate and want to assess exposure: the indicator logic above is implementable in Defender for Endpoint’s custom detection rules today, before a patch exists. Do it.

Closing

A SYSTEM write through your own antivirus is a bad week. Two of them in thirteen days, from the same researcher you forgot to credit, is a different category of problem entirely.

"SERIOUSLYMSFT" is not a provider name. It’s a message.

PGP signature: redsun-windows-defender-system-write.md.asc — Key fingerprint: 5FD2 1B4F E7E4 A3CA 7971 CB09 DE66 3978 8E09 1026