The Nightmare-Eclipse suite is a series of zero-day exploits released in early April 2026. It was dropped not by a nation-state or a criminal syndicate, but by a frustrated security researcher operating under the alias Chaotic Eclipse (also known as Nightmare-Eclipse on GitHub).
The Nightmare-Eclipse suite is a three-headed hydra designed to systematically dismantle every layer of Windows security. Each component plays a specific role in the “eclipse” of your system:
- BlueHammer: The entry point. This tool targets the Volume Shadow Copies (VSS) to silently extract the SAM database. It’s the “key thief,” pulling admin passwords and hashes out of thin air before the user even knows the door is unlocked.
- UnDefend: The “blinder.” This is a Denial of Service (DoS) tool specifically for Microsoft Defender. It doesn’t kill the process (which would trigger alarms), instead, it “blinds” it by severing its connection to cloud intelligence and signature updates, leaving the guard standing at his post but unable to see the intruder.
- RedSun: The final stage and the “totality.” Once the system is blind and the keys are stolen, RedSun weaponizes the Defender Remediation Service. It tricks the antivirus into hand-delivering malicious binaries into protected system folders like System32, completing the takeover.
Together, they form a perfect cycle: BlueHammer steals the keys, UnDefend pulls the wool over the guard’s eyes, and RedSun convinces that guard to burn the building down from the inside.
In this technical breakdown, we dissect the PoC for REDSUN (available on github) — a critical vulnerability in the Windows Kernel and Cloud Files API that allows a standard user to hijack the identity of the most powerful account on the machine.
REDSUN is a sophisticated Local Privilege Escalation (LPE) exploit that leverages a “Time-of-Check to Time-of-Use” (TOCTOU) race condition. It is fundamentally a vulnerability in Microsoft Windows, specifically within how the Windows Cloud Files API (cldflt.sys) and NTFS file system handle file restoration and path redirection.
By combining Opportunistic Locks (Oplocks), NTFS Junctions, and the Cloud Files API, an attacker can trick high-privileged system services into overwriting protected binaries (like TieringEngineService.exe) with malicious code. The result is a full takeover of the operating system, providing the attacker with NT AUTHORITY\SYSTEM access.
1. The Vulnerability Primitive
The exploit utilizes a Redirected Restoration vulnerability. It tricks a high-privileged system component into “restoring” or “syncing” a file into a protected directory (System32) by swapping the destination folder with a Junction while the system is mid-operation.
2. Phase-by-Phase Execution
Phase A: Setup & Baiting
The exploit creates a workspace and a bait file containing the EICAR string to trigger a response from Windows Defender or the Cloud Filter driver. (It can be malicious code or shell code)
// Create workspace in a user-writable directory
ExpandEnvironmentStrings(L"%TEMP%\\RS-GUID", workdir, MAX_PATH);
CreateDirectory(workdir, NULL);
// Create the bait file with EICAR string to trigger AV/Filter activity
char eicar[] = "X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*";
WriteFile(hfile, eicar, sizeof(eicar) - 1, &nwf, NULL);
- Path: C:\Users\User\AppData\Local\Temp\RS-ABC-123\
- Contents: TieringEngineService.exe (a dummy file).
Phase B: The Oplock “Freeze”
To win the race condition, the exploit places a Batch Oplock on the bait file. When a system service attempts to scan or open this file, the Oplock pauses that service’s execution.
// Request a batch oplock to "pause" the system service
OVERLAPPED ovd = { 0 };
ovd.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
DeviceIoControl(hlk, FSCTL_REQUEST_BATCH_OPLOCK, NULL, NULL, NULL, NULL, NULL, &ovd);
// Wait for the Oplock to be triggered by the victim service
GetOverlappedResult(hlk, &ovd, &nbytes, TRUE);
The exploit tells the system: “I’m using this folder/file right now. If anyone else tries to touch it, make them wait for me.” This is the Oplock.
Phase C: The Junction Swap
While the system service is paused, the exploit deletes the original folder and replaces it with a Junction pointing to System32.
// Delete the old directory and create a Junction 'Portal'
RemoveDirectory(workdir);
CreateDirectory(workdir, NULL);
// Point the Temp folder to System32
REPARSE_DATA_BUFFER* rdb = /* ... Initialize with IO_REPARSE_TAG_MOUNT_POINT ... */;
DeviceIoControl(hrp, FSCTL_SET_REPARSE_POINT, rdb, totalsz, NULL, NULL, NULL, NULL);
In the context of the Windows file system (NTFS), a Junction (also known as a Soft Link) is a shortcut that connects one folder to another. It acts like a “portal”: when you enter Folder A, the computer instantly and transparently teleports you to Folder B.
In this case C:\Users\User\AppData\Local\Temp\RS-ABC-123\ points to C:\Windows\System32.
Phase D: Redirection & Overwrite
The exploit uses the Cloud Files API to force the system to “hydrate” or restore the file. Because of the Junction, the system writes the malicious binary to C:\Windows\System32\TieringEngineService.exe.
3. The Payload (SYSTEM Escalation)
Once the service binary is overwritten, the exploit triggers it. The “Fake” service then steals the session ID from a local Named Pipe to launch a visible shell.
// Connect to the pipe created by the 'User' instance to find the session ID
HANDLE hpipe = CreateFile(L"\\??\\pipe\\REDSUN", GENERIC_READ, ...);
GetNamedPipeServerSessionId(hpipe, &sessionid);
// Duplicate the SYSTEM token and jump into the user's active session
DuplicateTokenEx(htoken, TOKEN_ALL_ACCESS, NULL, SecurityDelegation, TokenPrimary, &hnewtoken);
SetTokenInformation(hnewtoken, TokenSessionId, &sessionid, sizeof(DWORD));
// Launch the God-Mode Command Prompt
CreateProcessAsUser(hnewtoken, L"C:\\Windows\\System32\\conhost.exe", ...);
Tricking the Cloud Filter Driver into a Blind Write
You might be wondering: how does Windows manage to copy a file that the exploit just deleted?
That is the most clever part of the exploit! It doesn’t “copy” the file in the traditional sense; it tricks the Windows Cloud Files API (cfapi.lib) into "restoring" it for you.
Even though the original folder is deleted, the data for the “malicious” file is still held in the system’s memory and “Sync Root” configuration.
1. Registering the “Ghost” Data
Before the folder is deleted, the code calls DoCloudStuff. This function uses the Cloud Files API to tell Windows:
“This folder is a Cloud Sync folder. I have a file here called TieringEngineService.exe, and here is its 'Identity' (a unique GUID)."
By doing this, the exploit registers the malicious file’s metadata with the Cloud Filter Driver (cldflt.sys). The system now "knows" about this file, even if it hasn't fully written it to the disk yet.
2. The Placeholder Trick
The exploit creates a Placeholder. In Windows, a placeholder looks like a file but doesn’t take up space until it’s “hydrated” (downloaded or restored).
The exploit then calls CfCreatePlaceholders with the flag CF_PLACEHOLDER_CREATE_FLAG_MARK_IN_SYNC. This tells Windows: "This file is currently perfect and matches the cloud version."
3. The Forced “Hydration” (The Recovery)
When the exploit swaps the folder for a Junction to System32, it creates a situation where the Cloud Filter Driver thinks: "Wait, the local file at this path is missing or changed! I need to fix it to match the 'Cloud' version I registered earlier."
- The Trigger: The exploit or a system service tries to access that specific path.
- The Driver’s Logic: The Cloud Filter Driver sees the path is a “Cloud Sync Root” and realizes the file needs to be “restored” from the identity it was given.
- The Blind Write: The Driver (running as SYSTEM) starts writing the malicious data back to the path: ...\Temp\RS-GUID\TieringEngineService.exe.
- The Redirection: Because the folder is now a Junction, the Driver’s write operation is diverted to System32 .
Why this works after deletion:
The Cloud Filter Driver keeps a record of what should be in that folder. When you delete the folder and replace it with a Junction, you haven’t deleted the Driver’s “memory” of the file. You’ve just changed where the Driver’s “hands” go when it tries to put the file back.
In summary: The exploit doesn’t copy the file. It tells a high-privileged system driver, “I lost my file, please put it back here,” and then quickly moves the “here” to a protected system folder.
Hunting Opportunities
Here are hunting opportunities with specific Sysmon logic and forensic context.
1. Unusual cldapi.dll Loading
This is your “Proactive” hunt. It catches the attacker during the Setup/Baiting phase before they have even attempted the escalation.
- Primary Rule: ImageLoaded contains *cldapi.dll* AND Image NOT IN (OneDrive.exe, iCloud.exe, Dropbox.exe, ApplicationFrameHost.exe)
- The “RedSun” Special: Monitor TieringEngineService.exe specifically. While it is a system service, it does not typically utilize the Cloud Files API for user-space sync root registration.
- Forensic Pivot: Check the Signed status and SignatureStatus in Sysmon EID 7. An unsigned binary loading cldapi.dll is an immediate 90/100 severity alert.
2. Shell via TieringEngineService.exe
This is your “Reactive” alert. If this triggers, the system has likely already been compromised, and you are now looking at an active “God-Mode” session.
- Log Source: Sysmon EID 1 (Process Creation)
- ParentImage: *TieringEngineService.exe
- Image: contains any of (cmd.exe, powershell.exe, pwsh.exe, cscript.exe, wscript.exe, conhost.exe)
- Why it’s high fidelity: TieringEngineService (the Windows Storage Tiering service) is a background maintenance task. It manages data movement between SSDs and HDDs. There is zero legitimate reason for it to spawn a command interpreter or a script host.
3. The “Junction Portal” Creation
Since RedSun relies on a Time-of-Check to Time-of-Use (TOCTOU) race condition involving a folder swap, you can hunt for the “Portal” creation itself.
- Log Source: Sysmon EID 11 (FileCreate)
- TargetFilename: contains \AppData\Local\Temp\RS-{GUID}
- The Chain: Look for a directory being created and then converted into a Reparse Point (Junction) pointing to C:\Windows\System32.
- The “Time” Factor: Look for this Junction creation happening within seconds of the cldapi.dll load.
4. Named Pipe Creation `\pipe\REDSUN`
This is the “Pivoting” alert. It identifies the moment the exploit attempts to bridge the gap between the background SYSTEM service and the user’s interactive desktop.
- Log Source: Sysmon Event ID 17 (Pipe Created) & Event ID 18 (Pipe Connected)
- PipeName: \REDSUN
- Detection Logic: * EID 17: Created by a process in a user-writable path (e.g., *\AppData\Local\Temp\*).
- EID 18: Connected to by C:\Windows\System32\TieringEngineService.exe running as NT AUTHORITY\SYSTEM.
- Why it’s high fidelity: Named Pipes are frequently used for Inter-Process Communication (IPC), but a background system service connecting to a pipe created by an unsigned binary in a user’s temporary directory is a textbook indicator of Token Stealing or Session Hijacking.
Conclusion
REDSUN isn’t just a vulnerability; it is a masterclass in exploiting the Windows kernel’s own trust against itself. By turning the Cloud Files API into a high-privileged weapon, attackers can bypass the most fortified system defenses in a heartbeat. It serves as a chilling reminder that in the world of modern exploits, the most dangerous portals are the ones the operating system opens for you.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: https://medium.com/@Mr.AnyThink/redsun-the-portal-trick-to-god-mode-2af1ae219b7f?source=rss-b61b59bd2c7c------2