On 26 Mar 2026, a researcher with the alias Chaotic Eclipse publicly released BlueHammer, a Microsoft Defender local privilege-escalation exploit that was later linked to CVE-2026-33825 7.8 High-severity elevation-of-privilege vulnerability. Microsoft addressed that flaw in the April 14, 2026, Patch Tuesday updates. Two days later, the author released a second Defender-focused exploit, RedSun, as a separate technique capable of regaining SYSTEM-level execution by abusing Defender’s handling of a cloud-tagged flagged file even after the BlueHammer fix. In the same broader disclosure cycle, UnDefend was released to interfere with Defender’s ability to receive newer signature updates, weakening protection against newly emerging threats.
The urgency is not purely theoretical: Huntress Labs has publicly indicated that threat actors are already attempting to operationalize these techniques.
| CVSS Score | Severity | Version | Vector String |
|---|---|---|---|
| 7.8 | High | 3.1 | Not specified in the provided text |
RedSun
Not Confirmed Yet
Undefend
Not Confirmed Yet
BlueHammer
| Product | Component | Vulnerable Versions | Patched Versions |
|---|---|---|---|
|
Microsoft Defender Antimalware Platform | <= 4.18.26020.6 | 4.18.26030.3011 |
RedSun
Not Confirmed Yet
UnDefend
Not Confirmed Yet
BlueHammer
BlueHammer is a Windows local privilege-escalation proof of concept that abuses how Microsoft Defender handles signature updates. At its core, it relies on a TOCTOU-style race condition to trick Defender into giving access to a protected file from a Volume Shadow Copy, which the attacker then uses for credential-focused post-exploitation.
The exploit starts by waiting for a Defender definition update, downloading the update package, and preparing its own fake update directory. It then uses an EICAR bait file to make Defender react, watches for a new shadow copy to appear, and uses Cloud Files behavior together with batch oplocks to pause Defender at exactly the right moment. While Defender is paused, the exploit swaps the expected update path using object-manager links so that Defender ends up opening the SAM hive from the shadow copy instead of the normal update file.
Once it gets that protected file handle, the code reads the SAM data, rebuilds the LSA boot key from registry values, decrypts local users’ NT hashes, and then uses that access for follow-on actions such as temporarily changing passwords, logging in as other local users, spawning consoles, and, for administrator accounts, creating a short-lived service to reach SYSTEM execution.
RedSun
RedSun is a Windows local privilege-escalation proof of concept that abuses how Microsoft Defender handles a cloud-tagged malicious file. Instead of focusing on credential access like BlueHammer, RedSun turns Defender’s trusted file handling into the overwrite of a protected system binary and then uses that overwritten binary to obtain elevated execution.
The exploit works by creating a bait file named TieringEngineService.exe, placing it in a Cloud Files context so it is treated as cloud-tagged content, and then manipulating the file and directory state to control how Defender rewrites it.
By combining that setup with path redirection, the PoC causes Defender’s privileged file handling to land in C:\Windows\System32 rather than the original low-privileged working directory. As a result, C:\Windows\System32\TieringEngineService.exe is replaced with attacker-controlled code. The PoC then copies its own executable into that path and triggers execution through the tiering engine COM path, leading to elevated execution.
UnDefend
UnDefend is a Windows proof of concept designed to disrupt Microsoft Defender’s update workflow rather than directly achieve privilege escalation. Based on the code, it monitors Defender-related update locations and locks signature or related update files as they change, interfering with normal update and replacement behavior. In practical terms, it is best understood as a Defender update-blocking and protection-degradation tool.
The author described it as working in passive and aggressive modes. In passive mode, it is intended to block signature updates so Defender cannot learn about newly released threats. In aggressive mode, it is described as targeting major Defender platform updates in an attempt to make Defender stop responding entirely.
The PoC begins by creating a temporary working directory under %TEMP%\RS-{GUID} and staging files used later in the exploit chain, including a bait file named TieringEngineService.exe containing EICAR-like content so that Microsoft Defender will inspect and act on it. The EICAR content is not the real payload; it is only used to force Defender into the exploit path.
Detection opportunity: creation of suspicious temp directories with short-lived GUID-like naming, especially when followed by creation of TieringEngineService.exe in user-writable paths.
label=File label=Create
path="*\Temp\RS-*" file="TieringEngineService.exe"
| chart count() by user, host, "process", path,file
Guardsix Alertrule: File Dropped in Suspicious Location can detect this technique.
Analyst can also follow up on the events and get detailed event execution using Process Tree.
Defender will successfully detect the file as malware or other potentially unwanted software that we can verify in the SIEM using below query:
label=Malware label=Detect label=Threat
threat="Virus:DOS/EICAR_Test_File" | chart count() by user, domain, host, path
The PoC first registers a Cloud Files sync root and creates a placeholder-backed TieringEngineService.exe file inside its temporary working directory. This matters because the exploit depends on Defender handling the bait file as cloud-tagged content, which influences how the file is reopened, recalled, or rewritten during remediation.
To create the race window, the PoC repeatedly changes the state of the working directory and bait file through rename, delete, reopen, and re-creation operations. These transitions are not the final objective by themselves; they are used to control timing and prepare the directory for redirection at the moment Defender interacts with the file.
Once that state is in place, the PoC converts the temporary working directory into a mount-point reparse path targeting C:\Windows\System32. This is the critical redirection step, because it causes later file operations that appear to target the attacker-controlled temp directory to land in a privileged system path instead.
With the redirection established, the PoC attempts to supersede and overwrite C:\Windows\System32\TieringEngineService.exe, then copies its own executable into that location. This is the clearest payload stage in RedSun: the exploit turns Defender-linked handling of a cloud-tagged bait file into replacement of a trusted system binary, which can then be used for elevated execution.
Detection opportunity: file creation, replacement, or modification of C:\Windows\System32\TieringEngineService.exe, especially when preceded by activity in a temp or other user-writable directory, or when the initiating process originates from such a path.
label=File label=Create
path="*C:\Windows\System32" file="TieringEngineService.exe"| chart count() by user,host,"process",path,file
After replacing the system binary, the PoC triggers execution through a tiering-engine-related COM path so that C:\Windows\System32\TieringEngineService.exe is launched with SYSTEM privileges. A useful detection is to look for services.exe spawning TieringEngineService.exe under System Integrity.
label="Process" label=Create
(integrity_label="SECURITY_MANDATORY_SYSTEM_RID" or integrity_level=System)
"parent_process"="C:\Windows\System32\services.exe" "process"="C:\Windows\system32\TieringEngineService.exe"
| rename integrity_label as integrity_level | chart count() by user,host,parent_process,"process",command,integrity_level
TieringEngineService.exeIn the final stage, the RedSun PoC may spawn conhost.exe as a child of the overwritten TieringEngineService.exe. This is a strong late-stage confirmation artifact because it suggests the replaced system binary has already been executed successfully with elevated privileges.
label="Process" label=Create
parent_process="C:\Windows\System32\TieringEngineService.exe"
"process"="*\conhost.exe"
(integrity_label="SECURITY_MANDATORY_SYSTEM_RID" OR integrity_level=System)
| rename integrity_label as integrity_level
| chart count() by user, host, "process", parent_process, command, integrity_level
The current compiled available binary for BlueHammer is funnyapp.exe, but this should not be relied on as a primary detection artifact because an attacker can easily rename the binary. Detection should therefore focus on the broader execution pattern, especially suspicious executable drops followed by network activity and related Defender events.
BlueHammer also drops a test file to trigger Microsoft Defender detection behavior. That activity can be detected by searching for file creation events and defender detection events, as shown below:
label=File label=Create label=Overwrite
"process" IN ["C:\ProgramData*", "*\AppData\Local*", "*\AppData\Roaming*", "C:\Users\*"]
path="*\Temp\*" file="*.exe"
norm_id=winserver label=Malware label=threat label=Detect
| chart count() by path
If Sysmon or equivalent telemetry is available, a stronger approach is to correlate network connection activity with executable file creation under the same process context. This can help identify the binary download or staging phase associated with the exploit.
[ label=Network label=Connection] as s1
followed by
[label=File label=Create
path="*" file="*.exe"] as s2 within 1 minute on s1.process_guid=s2.process_guid
| rename s2.path as path, s2.file as file, s1.destination_host as destination_host
| chart count() by path,file,destination_host
After identifying a suspicious file drop, pivot to the process tree using process_guid to review the full execution chain, including parent process, child processes, related network activity, and any nearby Defender detection events. This helps confirm whether the dropped file is part of normal software activity or exploit-related staging.
A key detection angle for BlueHammer is not only the initial exploit path, but the privileged follow-on actions that occur after the exploit succeeds. In the PoC, one such behavior is the creation of a temporary Windows service to launch code with elevated rights. Although the service name may be generated dynamically, including values such as the current session ID, defenders should not focus on the name itself because that detail is easy to change. The more reliable signal is a service being installed from a user-writable or otherwise suspicious path such as C:\Users\, C:\ProgramData, C:\Windows\Temp, or C:\PerfLogs.
Guardsix Alertrule: Suspicious Windows Service Creation
label=Service label=Install label=Successful
path IN ["C:\Users\", "C:\ProgramData", "C:\Windows\Temp*", "C:\PerfLogs*"]
start_type="demand start"
Another notable artifact is local user password reset activity. The PoC uses privileged access obtained through the exploit to change account passwords as part of its post-exploitation flow. This makes password reset events valuable because they represent a concrete operational use of the gained privileges rather than just an internal exploit step.
label=User label=Password label=Reset
| chart count() by host, user, target_user
Taken together, these behaviors are useful because they are downstream effects of successful exploitation. Even if the underlying race condition or protected file access is difficult to observe directly, suspicious service installation and unexpected password reset activity can still reveal that BlueHammer-like tradecraft has moved from exploitation into active privileged use.
For customers with EDR and file monitoring, alert on non-standard processes locking or persistently accessing Windows Defender-related files, as this may indicate attempts to disrupt Defender updates or protection.
Monitor Defender health continuously, not just its enabled/disabled state.
Track signature age, engine and platform versions, and last successful update time so silent protection degradation or update blocking is identified early. Analysts should also avoid dismissing Defender detections on seemingly harmless test files, as such activity may be part of a privilege-escalation chain.
Use application control and reduce unnecessary execution paths.
Restrict unsigned, unapproved, or rare binaries from running, especially from user-writable locations, to reduce the attacker’s ability to stage tools and expand access after compromise.
Investigate suspicious persistence and proxy execution paths.
Review unexpected scheduled tasks, services, startup entries, and trusted Windows processes spawning unusual child processes or interacting with security-sensitive locations.
Isolate affected hosts as soon as key tampering or related indicators are detected.
If a system shows Defender degradation, suspicious persistence, or abnormal interaction with security components, remove it from the network quickly to reduce follow-on activity and lateral movement.
Disable or restrict impacted user accounts and rotate credentials.
If there is any indication that an affected host may have been used for credential access or privilege escalation, disable compromised accounts, reset passwords, and revoke active sessions promptly.
Apply least privilege and tightly control administrative access.
Limit local administrator rights, restrict service-account permissions, and separate privileged accounts from day-to-day user accounts so one compromised user cannot easily expand control.
Segment the network to limit lateral movement.
Separate user workstations, servers, domain controllers, management systems, and security infrastructure so compromise of one segment does not provide easy access to the rest of the environment.
Prepare for recovery, not only prevention.
Maintain tested incident response procedures, offline or otherwise protected backups, and a clear containment checklist so the team can respond quickly if the activity progresses beyond defense evasion.