Like many cybersecurity people, the latest exploit dropped by the cybersecurity researcher “Nightmare Eclipse” made me raise my eyebrows. This vulnerability contains multiple flaws concurrently in order to achieve privilege escalation. It made it more impressive that this was caused by Windows Defender itself.

Once I fully grasped what the flaws were which were being abused in the chain I set out to try the exploit out for myself and analyze what Defender for Endpoint logging shows us and more importantly what is useful to detect the exploitation of this technique.

A short explanation

The PoC released by the researcher shows us a core chain. We will walk through the different steps within the POC.

Setup

The executable creates a named pipe “\\.\pipe\REDSUN” which is later used for inter-privilege communication. After this, it starts a thread called “ShadowCopyFinderThread” which targets a temp file named “TieringEngineService.exe” in a folder under %TEMP%\RS-{RANDOM-GUID}.

(Figure 1: creation of Named Pipe)

AV triggering via EICAR

The EICAR test string is stored reversed in the code itself (flipping it at runtime), likely to avoid triggering AV detections on the source code itself. The string is then written to the aforementioned file in the Temp folder and is opened to force the AV to scan it.

(Figure 2: writing EICAR to disk)

VSS Oplock race

When Defender AV scans a file, it first creates a VSS snapshot of the volume. The aforementioned thread monitors \Device\ in the Windows Object Manager namespace for a newly appearing HarddiskVolumeShadowCopy* device not present at startup. Once found, it opens the corresponding file within the VSS copy and acquires a batch oplock on it. The oplock break (which is triggered when the AV reads the file) serves as a timing signal back to the main() function.

Cloud files placeholder swap

Upon acquiring the oplock in VSS copy, the main thread marks the original TieringService.exe file for deletion and then registers the previously created directory in %TEMP% as a Cloud Files sync root and creates a cloud placeholder for TieringEngineService.exe in its place. This results in the file on disk now being a dehydrated cloud placeholder instead of the EICAR file.

Directory junction to System32

After the shadow copy releases its oplock, the main thread continues to rename the working directory to a .TEMP2 path. It recreates a new empty directory and sets an NTFS junction on it to System32. Which means that the working directory now resolves to System32.

Writing to System32

The executable then loops up to a thousand times trying to open TieringEngineService.exe under System32 for write. During cloud placeholder hydration, the system temporarily has the file open through paths that resolve differently, which creates a race where the junction redirect succeeds. Then the executable copies itself into the TieringEngineService.exe under System32.

System execution via COM abuse

The exploit then activates the CLSID {50d185b9-fff3-4656-92c7-e4018da4361d} via DCOM, which is the Storage Tiers Management Engine COM server, which then executes TieringEngineService.exe under System32. Since the binary is no longer just an EICAR file, this means that the executable is now running as SYSTEM. The payload knows it is running as SYSTEM due to an early check in the code checking its privileges, reads the original session ID from the named pipe created in the first step and spawns a conhost in the user’s session, thus delivering a SYSTEM shell pop.

(Figure 3: Popped a shell)

Creating the detection

In order to create a detection for the exploit, logging of the actual behaviour was needed! I downloaded a copy of the code from Github and set out to compile it myself.

Through some trial and error (and many deep conversations with Claude), I finally managed to get a System-privileged shell to pop up. Victory! Now, it was time for me to put on my blue-teaming hat and check out the logging.

Already being fairly familiar with what the code was supposed to do thanks to the troubleshooting of the PoC, a plan formed in my head. This exploit has three things that it will have to do regardless:

1. Create/open a named pipe to pass the original session ID through
2. Trigger an AV detection by opening a file
3. Spawn a process from the System32 version of itself

Those three core principles led me to a query which will trigger when a process with the same hash does all three of these actions concurrently. This detection can still be optimized by looking at the source process and running its hash through, for example, a FileProfile functionality.

Below, you can find the KQL query that can be configured as a custom detection.

How The Collective helps

The Collective has got you covered! All of our SOC customers have had a thorough threat hunt executed and this custom detection has been deployed. Our customers have had coverage from day 1.