The RedSun exploit is a local privilege escalation vulnerability in Windows Defender that allows an attacker with local code execution to write arbitrary files with SYSTEM privileges by abusing the Cloud Files API and mount point reparse points. It leverages the same attack surface as the previously patched BlueHammer (CVE-2026-33825, CVSS 7.8), but uses a different primitive, and no patch is currently available as of the article's publication.
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. BlueHammer RedSun Entry point Windows Update Agent COM ( wuapi.h ) Cloud Files API ( CfRegisterSyncRoot ) Trigger Pending Defender signature update detected Defender scan of cloud placeholder Steer mechanism Oplock on VSS snapshot mount stalls Defender SYSTEM thread Reparse point redirects Defender write path Privileged primitive exploited Defender reads SAM/SYSTEM/SECURITY hives from mounted snapshot D...