New release : CTI Report - Pharmaceutical and drug manufacturing 

                 Download now

REDSUN – Practical Detection Artifacts Under Real-World Constraints

April 24, 2026
CERT

This article documents practical detection opportunities for exploitation associated with REDSUN vulnerability, using public exploit research only as contextual background for the vulnerability.

This write-up deliberately avoids overfitting on the public proof-of-concept launcher name. Detection logic is centered on behaviors and native artifacts that are more likely to survive renaming, repackaging, or partial code reuse by real-world attackers. The goal is not to detect a specific proof-of-concept filename, but to generalize forensic guidance for identifying exploitation of the vulnerability itself.

The scope is therefore evidence-driven: the goal is to show what can still be detected on a Windows host using native artifacts only, even when endpoint telemetry is incomplete. In the investigated case, Sysmon was not deployed. Despite that limitation, the exploitation sequence could still be identified and reconstructed through Microsoft Defender Operational logs, Defender MPLogs, filesystem timeline artifacts, Prefetch, and ShimCache.

Executive Summary

REDSUN exploit is a local privilege escalation vulnerability affecting Microsoft Defender remediation behavior. Public exploit code shows a workflow in which a decoy binary is staged in a temporary directory, populated with an EICAR trigger, and intentionally driven into Defender scanning and remediation logic. The exploit then abuses Cloud Files sync root registration, placeholder creation, rename-and-reparse redirection, and the Storage Tiers Management COM activation path to obtain execution from C:\Windows\System32 as NT AUTHORITY\SYSTEM.

This article does not treat the original public launcher as the primary detection anchor. Instead, it focuses on the forensic artifacts left by the exploitation workflow itself, so that analysts can still investigate cases where the exploit logic has been integrated into another tool, renamed, obfuscated, or otherwise adapted.

Review of the public exploit code aligns well with the observed artifacts from the investigated host. Some of the visible indicators below come directly from hard-coded strings in the public implementation and could be changed by an attacker in a real intrusion. For that reason, they should be treated as useful hunting clues rather than invariant signatures:

  • a GUID-named %TEMP% staging directory prefixed with RS- in the public implementation
  • a staged binary named TieringEngineService.exe in the public implementation
  • Cloud Files-related placeholder metadata associated with the staging directory
  • a rename sequence involving .TMP and .TEMP2 in the public implementation
  • a mount-point reparse redirect to C:\Windows\System32
  • subsequent execution from C:\Windows\System32
  • follow-on execution under SYSTEM

Even without Sysmon, this activity remains detectable through a combination of Defender Event ID 1116, Defender Event ID 1119, Service Control Manager 7000/7009, DistributedCOM 10005, filesystem timeline artifacts, Prefetch, ShimCache, and Defender MPLogs.

Technical Context

Analysis of the public exploit code shows the following high-level sequence:

  1. A working directory is created under %TEMP% using the pattern RS-{GUID} in the public implementation; both the prefix and naming convention are hard-coded and could be changed by an attacker.
  2. A file named TieringEngineService.exe is created in that directory in the public implementation; the exact filename is also attacker-controlled if the exploit logic is embedded or modified.
  3. The file is populated with the reversed EICAR string, then reversed in memory before being written, so the on-disk content becomes the standard EICAR trigger; the trigger mechanism is central to the exploit, even if surrounding filenames are changed.
  4. The staged file is opened in a way that triggers Microsoft Defender real-time scanning.
  5. A helper thread monitors \Device for the appearance of a new HarddiskVolumeShadowCopy* object, then opens the corresponding file in the shadow copy path and requests a batch oplock on it.
  6. The exploit deletes the original staged file, registers the temporary directory as a Cloud Files sync root, and creates a placeholder file for the staged payload name; the Cloud Files behavior is the durable signal, whereas the exact path and filename may vary.
  7. The original working directory is renamed to RS-{GUID}.TMP, recreated under its original name, then the placeholder-backed file path is later renamed to RS-{GUID}.TEMP2 in the public implementation; these suffixes are implementation-specific and could be changed by an attacker.
  8. The recreated working directory is turned into an NTFS mount point targeting C:\Windows\System32.
  9. The exploit repeatedly attempts to create a payload file under C:\Windows\System32, then copies its own image to that path; the final filename used by the public exploit is mutable, but privileged-path placement is the key behavior.
  10. It finally activates the Storage Tiers Management COM object using CLSID {50D185B9-FFF3-4656-92C7-E4018DA4361D}, which results in execution under SYSTEM.

Note

Across artifact sources, the staging directory may appear under multiple closely related forms, including RS-{GUID}, RS-{GUID}.TMP, and later RS-{GUID}.TEMP2 in the public implementation. This is expected and reflects different moments in the staging, rename, placeholder, and cleanup sequence. In a real intrusion, these exact string forms may differ if the exploit is modified.

Detection Artifacts

Defender Operational Log — Event ID 1116

The earliest and most actionable signal came from the Microsoft-Windows-Windows Defender/Operational log.

Representative event:

Several fields are operationally significant:

  1. Threat Name: Virus:DOS/EICAR_Test_File is the first pivot and should be considered suspicious when tied to an executable under a temporary staging directory.
  2. Path exposes the staged file path and the temporary directory naming pattern present in the investigated case.
  3. Execution Name: Suspended is consistent with interception during the Defender handling window.

Note

The exact filename and directory strings visible in Defender logs may be changed by an attacker in a modified implementation. The stronger detection concept is the combination of an EICAR-triggering executable in a suspicious temporary path and closely related remediation anomalies.

Defender Operational Log — Event ID 1119

A second strong indicator comes from remediation failure telemetry.

In the observed case, Defender attempted to remediate the detected EICAR file but failed because the file was locked by another process.

Representative values include:

  • Threat: Virus:DOS/EICAR_Test_File
  • File: C:\Users\<user>\AppData\Local\Temp\RS-{GUID}\TieringEngineService.exe
  • Error description: The process cannot access the file because it is being used by another process
  • Remediation user: NT AUTHORITY\SYSTEM

This matches the public exploit logic closely. The code explicitly waits for the relevant file to appear through the shadow-copy path and requests a batch oplock against it, which makes remediation interference a core behavioral feature rather than an accidental side effect.

Important

The combination of:

  • Defender Event ID 1116 for Virus:DOS/EICAR_Test_File
  • followed by Defender Event ID 1119 with a file-in-use remediation error

is a high-value detection pattern for this vulnerability.

Service and COM-Related Events

System event logs can provide correlation points for the privileged execution phase.

Observed events include:

  • Service Control Manager — Event ID 7009
    Timeout while waiting 30000 milliseconds for TieringEngineService
  • Service Control Manager — Event ID 7000
    Service start failure for TieringEngineService
  • DistributedCOM — Event ID 10005
    COM activation failure involving CLSID {50D185B9-FFF3-4656-92C7-E4018DA4361D}

These events are not specific enough to stand on their own, but they become highly useful when they occur close to Defender detections and filesystem artifacts tied to the staged payload and the privileged execution phase.

Filesystem Forensics

Filesystem Timeline Artifacts

The most useful filesystem artifacts are not just the temporary directory name, but the sequence of file creation, placeholder, rename, and redirection operations around it.

Observed entries show:

This combined view is important for three reasons:

  • The presence of the staged binary inside the working directory shows the initial decoy creation step.
  • Tea .SyncRootIdentity artifact is especially valuable because it directly aligns with the Cloud Files sync-root registration behavior present in the exploit source code.

One subtle but important point is that the exploit code first creates the working directory as RS-{GUID}, later renames the directory itself to RS-{GUID}.TMP, recreates the original directory name, then later renames the placeholder-backed file path to .TEMP2. For that reason, different forensic sources may surface slightly different path variants without contradicting one another. In a modified implementation, the same sequence may exist under different strings.

MFT Timeline

The MFT timeline also showed access and execution-adjacent artifacts:

The first suggests activity consistent with Cloud Files-related processing shortly before execution evidence appears, but should be treated as a correlation artifact rather than a standalone proof point. The second confirms Prefetch creation for the staged payload name used in the investigated case.

Prefetch

Prefetch provides strong native proof of execution.

Observed execution artifacts included:

  • C:\Windows\System32\TieringEngineService.exe
  • C:\Windows\System32\c[m]d.exe
  • C:\Windows\System32\whoami.exe

This sequence is important because it supports the expected post-exploitation flow: privileged payload execution followed by shell launch and privilege verification. In a real intrusion, the child processes may differ depending on operator objectives.

Additional Native Artifacts

Defender MPLogs, MPDetection and Detections.log

Defender MPLogs and MPDetection add important depth to the analysis.

Observed elements include:

  • repeated detections of the staged payload under C:\Users\<user>\AppData\Local\Temp\RS-{GUID}\
  • quarantine attempts
  • explicit remove failures
  • references to \Device\HarddiskVolume*\Windows\System32\TieringEngineService.exe

Representative examples:

Important

If available, C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\ should be preserved early, as it may contains evidences related to TieringEngineService.exe. MPLogs can retain details that are not obvious from Event Viewer alone.

Correlated Forensic Timeline From the Investigated Host

The following timeline consolidates the most relevant host-level events observed on the investigated system.

Timestamp (UTC)SourceEvent
2026-04-18 12:24:20 MFT Creation of C:\Users\<user>\AppData\Local\Temp\RS-{GUID}.TMP:${GUID}.SyncRootIdentity
2026-04-18 12:24:20 MFT Creation of C:\Users\<user>\AppData\Local\Temp\RS-{GUID}.TMP\TIERIN~1.EXE
2026-04-18 12:24:20 MFT Creation of C:\Users\<user>\AppData\Local\Temp\RS-{GUID}.TMP\TieringEngineService.exe
2026-04-18 12:24:20 Defender Event ID 1116 Detection of Virus:DOS/EICAR_Test_File on C:\Users\<user>\AppData\Local\Temp\RS-{GUID}\TieringEngineService.exe
2026-04-18 12:25:11 Prefetch Execution of VSSVC.EXE and related service-host activity
2026-04-18 12:25:13 Defender Event ID 1119 Remediation failure because the file TieringEngineService.exe is in use by another process
2026-04-18 12:25:13 Service Control Manager — 7009 Timeout while waiting for TieringEngineService
2026-04-18 12:25:13 Service Control Manager — 7000 Service start failure for TieringEngineService
2026-04-18 12:25:13 DistributedCOM — 10005 COM-related failure involving CLSID {50D185B9-FFF3-4656-92C7-E4018DA4361D}
2026-04-18 12:25:13 Prefetch Execution of C:\Windows\System32\TieringEngineService.exe
2026-04-18 12:25:13 Prefetch Execution of C:\Windows\System32\c[m]d.exe
2026-04-18 12:25:16 Prefetch Execution of C:\Windows\System32\whoami.exe
2026-04-18 12:27:34 Defender Event ID 1116 On this host, Defender additionally detected Exploit:Win32/DfndrPERedSun.BB on C:\Windows\System32\TieringEngineService.exe
2026-04-18 12:27:57 Defender Event ID 1117 Successful quarantine/remediation action against Exploit:Win32/DfndrPERedSun.BB

This timeline supports a coherent exploitation narrative:

  1. A temporary GUID-named staging directory is created and populated with a decoy executable.
  2. Cloud Files-related registration artifact appears via .SyncRootIdentity.
  3. Defender detects the EICAR-based decoy.
  4. Remediation fails because the file is being actively held during the exploitation window.
  5. Service and COM-related errors appear around the privileged execution phase.
  6. Execution pivots into a System32 payload path.
  7. Follow-on c[m]d.exe and whoami.exe execution strongly suggest successful SYSTEM-level post-exploitation.
  8. On the investigated host, Defender later generated additional detections under Exploit:Win32/DfndrPERedSun.BB and eventually quarantined the System32 payload.

Hardening Recommendations

  • Treat suspicious EICAR detections as potentially hostile when they are associated with executable staging and remediation anomalies.
  • Monitor for Defender remediation failures on active files.
  • Collect and retain Windows Defender related event logs, MPLogs and MPDetection logs.
  • Monitor and alert for TieringEngineService outside of expected behavior, especially when correlated with recent Defender remediation anomalies and file creation in %TEMP% directory.
  • If Sysmon is available, add process creation, file create, and file delete coverage.

Conclusion

This article intentionally avoids over-reliance on the original public proof-of-concept binary name and instead focuses on forensic evidence more likely to persist in real intrusions where the exploit code is embedded or modified.

The strongest practical detection opportunities are:

  • Defender 1116 on Virus:DOS/EICAR_Test_File
  • Defender 1119 remediation failure with file-lock symptoms
  • Suspicious temporary staging and rename behavior
  • Cloud Files sync-root artifact such as .SyncRootIdentity
  • Placement or execution from C:\Windows\System32
  • DCOM correlation around the Storage Tiers activation path
  • On some systems, later Defender detection under Exploit:Win32/DfndrPERedSun.BB
  • Defender MPLogs showing failed remediation and privileged-path references

Taken together, these artifacts allow defenders to move from a generic Defender detection to a much stronger conclusion.

Articles by category

Contact