RedSun and UnDefend: The Unpatched Exploit Pair Turning Windows Security Against Itself

Microsoft patched BlueHammer. The researcher who wrote it came back with two more. RedSun and UnDefend have no CVE numbers, no patches, and working proof-of-concept code sitting openly on GitHub. Both have been used against real targets. This is the situation right now.

Within a span of twelve to thirteen days in April 2026, a researcher known as Nightmare-Eclipse (also going by Chaotic Eclipse) published three working exploit tools targeting the same attack surface inside Microsoft Defender. The first, BlueHammer, earned a CVE and got patched in the April 2026 Patch Tuesday cycle under CVE-2026-33825 with a CVSS score of 7.8. The other two, RedSun and UnDefend, remain unpatched as of this writing. No CVE identifiers have been assigned. Microsoft has issued no patch or official remediation timeline, and the next scheduled Patch Tuesday is weeks away. Huntress has already observed all three being used in real-world intrusions.

What makes this situation genuinely dangerous is not any single exploit in isolation. It is the architecture of the problem. These three tools were not written as independent curiosities. Together they form a complete offensive workflow that escalates privileges, executes arbitrary code with SYSTEM rights, and then cuts off Defender's ability to detect anything that follows. The patch for BlueHammer does nothing to address RedSun or UnDefend. Organizations that applied April's Patch Tuesday and moved on are still fully exposed to two-thirds of this toolkit.

A note on a dangerous mischaracterization circulating in consumer media: At least one widely-read technology outlet has described these exploits as requiring "direct, physical access to your Windows laptop or PC." That is incorrect, and the mischaracterization matters. Local privilege escalation means the attacker needs a user-level shell on the machine — not physical proximity. A phishing victim who clicks a malicious attachment, a user who downloads and runs a renamed exploit binary, or an employee whose credentials were used over an SSL VPN all provide exactly the level of access needed to trigger RedSun. Physical presence at a keyboard is not required. Enterprise and IT readers should be aware this framing exists in general-audience coverage and should not let it shape their risk assessment.

How We Got Here

The backstory matters here because it shapes the threat landscape. The researcher operating under the aliases Nightmare-Eclipse and Chaotic Eclipse released BlueHammer on April 3, 2026, after publicly stating that a disclosure attempt with the Microsoft Security Response Center went nowhere. BlueHammer exploited logic flaws in Defender's privileged file operations — specifically using opportunistic locks (oplocks) and NTFS junction points to redirect a SYSTEM-level write during Defender's quarantine/remediation workflow. The result was that an unprivileged user could overwrite a protected system binary and achieve SYSTEM-level code execution.

A note on the CVE and what it actually covers: Some coverage online — including headlines from reputable outlets — conflates CVE-2026-33825 with both BlueHammer and RedSun, or assigns it to RedSun directly. This is incorrect. CVE-2026-33825 (CVSS 7.8, CWE-1220: Insufficient Granularity of Access Control) was assigned specifically to BlueHammer and addresses that vulnerability only. RedSun and UnDefend have no CVE identifiers assigned as of this writing. When you see articles pairing the CVE number with RedSun, they are using it as contextual shorthand for the broader event cluster, not as a formal assignment. We are keeping these distinct here because the patch status depends on it.

A note on the BlueHammer mechanism itself: Descriptions of exactly how BlueHammer achieves SYSTEM access vary across coverage, and both characterizations in circulation are partially accurate because they describe different aspects of the same exploit. Some sources emphasize the TOCTOU race condition and the VSS snapshot interaction, where Defender reads SAM/SYSTEM/SECURITY hives from a mounted shadow copy, enabling offline NTLM hash extraction that then leads to SYSTEM via token duplication. Other sources describe the oplock-plus-NTFS-junction primitive that redirects a Defender file write into System32. The Cyderes analysis describes BlueHammer as a "privileged file read" exploit and RedSun as a "privileged file write" exploit — different primitives within the same class of vulnerability. Neither description is wrong; the exploit combines both techniques in sequence. What matters for defenders is that the two share an underlying assumption Defender fails to validate: that path resolution at write time will match path resolution at check time.

A note on researcher attribution: Microsoft's April 2026 Patch Tuesday credited the BlueHammer vulnerability to researchers Zen Dodd and Yuanpei Xu — not to Nightmare-Eclipse. Whether those researchers independently discovered and reported the same flaw, or whether there is overlap in the underlying research, has not been publicly clarified by Microsoft. Nightmare-Eclipse has stated publicly that their disclosure attempt was ignored. It is not known whether RedSun was privately reported to Microsoft before its public release; CSO Online noted this explicitly after Microsoft declined to comment. We are stating clearly here that the research behind these exploits belongs to Nightmare-Eclipse on the PoC releases, and that the attribution question around the CVE credit is unresolved.

On April 15 or 16 — sources differ by one day, with Blackswan Cybersecurity and CyberPress citing April 15 and Help Net Security citing April 16 — Nightmare-Eclipse published RedSun and UnDefend to the same GitHub repository. The stated motivation was frustration that the BlueHammer patch had been credited to others without acknowledgment of the systemic architectural issues raised during the original disclosure. Nightmare-Eclipse stated publicly: "They do everything but support the research community." The repository remains publicly accessible despite a warning from the Microsoft-owned GitHub platform. When Huntress reported active exploitation to media outlets, Microsoft responded with a statement affirming its commitment to investigating reported security issues, updating impacted devices, and supporting coordinated vulnerability disclosure as a widely adopted industry practice. The statement did not address the researcher's specific attribution grievances, the timeline for patches for RedSun and UnDefend, or the substance of the MSRC complaint. Nightmare-Eclipse publicly criticized the response as generic and dismissive. The effectiveness of the RedSun proof-of-concept has been independently confirmed by vulnerability analyst Will Dormann. This is not a theoretical threat. The code works, and it has already been picked up by threat actors.

RedSun: Turning Defender Against Itself

RedSun targets Defender's cloud file rollback mechanism, a feature tied to Windows Cloud Files infrastructure and the cldapi.dll library. The root cause, identified by Ampcus Cyber's technical analysis, is a missing reparse point validation in MpSvc.dll — the core Malware Protection Engine service DLL. When Defender detects a malicious file carrying Cloud Files attributes, it attempts to restore the file to its original detection path without verifying whether that path has been redirected via a junction point. The practical consequence: Defender's remediation logic for cloud-tagged files performs an unvalidated rewrite to the original path rather than quarantine or safe deletion, and that write happens under SYSTEM privileges. The exploit weaponizes that behavior to drop an attacker-controlled binary into C:\Windows\System32.

A note on PoC availability — there is confusing coverage here: Some sources, including CyberSecurityNews, state that the full PoC code has not been publicly released by the researcher, and that only the exploit methodology is documented on GitHub. This is outdated or inaccurate at time of publication. The RedSun GitHub repository (Nightmare-Eclipse/RedSun) contains the full C++ source file RedSun.cpp. Independent analyst Will Dormann confirmed the exploit works as written. The claim that the PoC is only partially released likely reflects the initial hours of disclosure before the repository was widely indexed. As of this writing, the complete source is accessible, and compiled variants are already circulating.

Nightmare-Eclipse described the flaw in the repository with characteristic bluntness — characterizing Defender's behavior as an antivirus that detects a malicious file and then inexplicably rewrites it back to the same location with its own elevated privileges. That is not editorializing — that is the root behavior. The why matters here: Defender was designed to restore cloud-backed files to their expected state when they are flagged, as part of its cloud file remediation workflow. The intention was protective. What was not validated is whether the "original location" of that file has been tampered with between detection and write. RedSun inserts that tampering in the gap.

The attack sequence works like this. The attacker registers a fake cloud sync provider using the CfRegisterSyncRoot API — a documented, non-privileged Windows API used legitimately by OneDrive, Dropbox, and similar clients. They create a crafted file containing an EICAR test string and mark it with a cloud tag. When Defender's real-time protection engine detects that file and initiates remediation, the exploit deploys a two-phase opportunistic lock (oplock) sequence to pause Defender's SYSTEM-level file operation at a precisely timed point. During that pause, the exploit modifies the filesystem by creating an NTFS junction (set via FSCTL_SET_REPARSE_POINT) that redirects Defender's target path from the attacker-controlled temporary directory to C:\Windows\System32. When the second oplock releases and Defender resumes its write, it follows the junction and writes to the redirected location under its own SYSTEM privileges. The attacker's payload lands in System32. The next time the affected service binary runs, it executes as SYSTEM.

Why a two-phase oplock matters — and why some descriptions get this wrong: Some coverage simplifies RedSun as a basic single-oplock race condition. Technical analysis of the RedSun source code makes clear it is not. A single oplock is insufficient — by the time Defender's scanner thread breaks it, the reparse point must already be stamped on the directory. The first oplock buys the time window; the directory rename and fresh directory creation happen during that window; the reparse point goes on the new directory; the second oplock holds Defender suspended while that entire sequence completes. Without the second oplock, the attack degrades into a timing-sensitive race condition with unreliable results. The two-phase design is what produces near-100% reliability. This also explains why the exploit is difficult to detect at the OS level — none of the individual operations are abnormal in isolation. CfRegisterSyncRoot is a documented API. FSCTL_SET_REPARSE_POINT is a documented NTFS operation. Defender simply was not written to validate that path resolution at write time matches what it verified at check time.

The target of the write in confirmed exploitation activity is TieringEngineService.exe. The reliability of this technique, confirmed by vulnerability analyst Will Dormann, is reported at close to 100 percent on fully patched Windows 10, Windows 11, and Windows Server 2019 and later. No kernel exploit is required. No driver is involved. No administrative interaction is needed. Any standard unprivileged user account on an affected system with Defender real-time protection enabled is a potential launch point.

"Any system that has cldapi.dll should be affected." — Will Dormann, vulnerability analyst, confirming RedSun's scope via CSO Online

Dormann's independent testing placed the success rate at close to 100 percent on fully patched Windows 10, Windows 11, and Windows Server 2019 and later running the April 2026 cumulative updates with Defender enabled. No kernel exploit, no driver, no administrator interaction required.

On the scope of affected systems — a detail most coverage misses: The cldapi.dll qualifier is significant. The Windows Cloud Files API library ships with Windows 10 version 1709 and later as a core OS component, not as an optional feature tied to OneDrive enrollment. It is present on systems where OneDrive has never been installed or run. The attack surface is not limited to organizations that use Microsoft cloud storage. Any Windows endpoint running a current OS build with Defender enabled carries the prerequisite, regardless of cloud storage configuration. Organizations that have never deployed OneDrive and assumed they were therefore outside this attack surface are not outside it.

A critical note on Defender's detection — and where some coverage misleads: When Huntress observed RedSun executing in the wild, it triggered a Virus:DOS/EICAR_Test_File alert from Defender. Some reporting has framed this as evidence that Defender catches the attack. It does not. The EICAR alert fires because the bait file contains an EICAR test string — that is the lure working as designed. Defender is reacting to the decoy, not to the privilege escalation that immediately follows. Vulnerability analyst Will Dormann confirmed this explicitly: Defender does not detect the exploit itself in either the EICAR variant or an encrypted variant of the bait. Additionally, some sources cite VirusTotal detections of the RedSun binary under the generic heuristic Program:Win32/Wacapew.C!ml. This heuristic flags the binary as a suspicious file — it does not detect the exploit behavior. An attacker can recompile RedSun from source, change the hash, and defeat sample-based detection while the underlying technique remains fully functional. Behavioral detection is the only meaningful defense here.

"These invocations followed after typical enumeration commands... indicating hands-on-keyboard threat actor activity." — Huntress SOC

Those commands — whoami /priv, cmdkey /list, net group — are the fingerprints of a person at a keyboard, not automated tooling. They assess what privileges the current session holds, what stored credentials exist, and what Active Directory groups are accessible. After that assessment, RedSun and UnDefend were the answer.

In the wild, Huntress observed RedSun being executed from C:\Users\[REDACTED]\Downloads\RedSun.exe on April 16. Notably, the binary was subsequently renamed — Huntress telemetry shows the attacker renamed it to z.exe before final execution — a deliberate evasion step. By contrast, BlueHammer had been observed as early as April 10, where Defender itself did block that attempt, detecting it as Exploit:Win32/DfndrPEBluHmrBZ. The attacker's pivot to RedSun days later reflects an awareness that Defender's detection of BlueHammer had failed the first operation and that a different technique was needed. The attacker proceeded to enumeration and lateral movement after the escalation.

On the "local-only" framing debate: Some commentary downplays these exploits by leading with "it requires local access first." That is accurate and worth stating plainly — RedSun is a local privilege escalation, not remote code execution. An attacker needs an existing unprivileged shell. What that framing omits is that local, unprivileged access is exactly where real intrusions land after phishing, malicious downloads, or browser exploitation. The "local only" qualifier reduces the theoretical attack surface but does not reduce operational relevance for any environment where endpoint compromise is a realistic scenario. The pre-exploitation enumeration commands Huntress observed — whoami /priv, cmdkey /list, net group — are exactly the fingerprints of an attacker who already has a shell and is assessing what to do next. RedSun is the answer to that assessment.

UnDefend: The Silent Blindfold

If RedSun is the escalation, UnDefend is the cover. It targets Defender's update mechanism rather than its file operations, and it operates in one of two modes depending on what the attacker wants to accomplish.

A note on UnDefend's release date — there is minor discrepancy in coverage: Most major outlets, including The Hacker News and Help Net Security, report UnDefend being published alongside RedSun on April 16, 2026. However, the Cyderes technical analysis and the Ampcus Cyber Shadow Ops Intel report list UnDefend's release date as April 12 — four days earlier than RedSun, which would make it the second tool released, not the third. Huntress observed both being deployed in the wild starting April 16. The most defensible reading of available evidence is that the GitHub repository commits may have been staged differently than the public disclosure dates tracked by different researchers. For defenders, the release date distinction is less important than the exploitation timeline: both UnDefend and RedSun were active in real intrusions from April 16 onward.

In passive mode, UnDefend blocks all signature updates from reaching the endpoint. Defender continues running, continues reporting as healthy to management consoles, and continues returning a green status to any monitoring dashboard checking on it. But it stops learning. Any new threat signature Microsoft pushes after UnDefend activates is silently intercepted before it reaches the engine. From that point forward, the endpoint is frozen at whatever threat intelligence it held at the moment of UnDefend's execution.

In aggressive mode, UnDefend waits for Microsoft to push a major Defender platform update affecting MsMpEng.exe or related core binaries. When that update arrives, UnDefend triggers, and Defender stops responding entirely. There is some debate in coverage about how to characterize this trigger: some descriptions present UnDefend as able to immediately and fully disable Defender at any time. That is not precise. The aggressive mode disable is conditional — it requires a major Microsoft platform update to be pushed to the endpoint before the full disable activates. This makes the timing somewhat unpredictable from an attacker's perspective, though the passive mode signature-blocking is immediate and unconditional. Both modes are dangerous; the aggressive mode is simply not an on-demand instant kill switch in the way some headlines have implied.

The critical detail here is the health reporting behavior. UnDefend does not disable Defender in a way that fires obvious alerts. Management consoles and remote monitoring tools continue to show the endpoint as protected. Security operations teams looking at a dashboard view of endpoint health will not see this compromise. The deception is the point. An attacker who has already escalated with RedSun can deploy UnDefend to create a detection gap, while the SOC's board reads nominal.

The Chained Kill Chain

The reason this triple zero-day cluster demands attention beyond what any individual vulnerability would justify is that the three tools together form a complete offensive workflow. None of them requires the others to function independently. But when chained, they eliminate the two defenses that endpoint protection is supposed to guarantee: privilege boundaries and real-time detection.

A realistic kill chain using these tools begins with initial access through an ordinary vector. Phishing, a malicious download, a browser exploit, or an exposed service with weak credentials are all sufficient. The attacker needs only a standard unprivileged shell on a Windows endpoint with Defender enabled. From there:

• RedSun escalates the session to SYSTEM by weaponizing Defender's own cloud file remediation logic. The attacker gains full administrative rights, the ability to read any file on the system including credential stores, and the ability to install, modify, or delete anything without restriction.
• From that SYSTEM shell, the attacker deploys UnDefend in passive mode to freeze Defender's signature intelligence at the current timestamp. Any new tooling dropped onto the endpoint after this point has a significant advantage against detection.
• Post-exploitation activity can then proceed without the normal constraint of real-time antimalware scanning recognizing recently developed payloads. Credential dumping, lateral movement tooling, ransomware loaders, and persistence mechanisms can all operate against a Defender instance that is effectively blind to anything the threat actor brought that Microsoft's threat intelligence has not already characterized.

What SYSTEM Access Enables — The Post-Escalation Playbook

A SYSTEM shell is not just an elevated prompt. It is the highest local privilege level on a Windows endpoint — above Administrator in several meaningful ways. Understanding what an attacker does with it closes the gap between "privilege escalation happened" and "here is what the damage assessment looks like."

Credential extraction. With SYSTEM rights, an attacker can dump credentials directly from LSASS memory using tools like Mimikatz or its derivatives, or by creating a minidump of the lsass.exe process using legitimate Windows APIs (MiniDumpWriteDump) that Defender's SYSTEM-level write restrictions would otherwise block at lower privilege. NTLM hashes extracted this way can be used immediately for Pass-the-Hash lateral movement without cracking. Kerberos tickets harvested from LSASS enable Pass-the-Ticket attacks against other domain resources. The SAM database at C:\Windows\System32\config\SAM becomes readable, exposing local account hashes. If the compromised endpoint has ever cached domain credentials, those hashes are now accessible.

Active Directory reconnaissance and lateral movement. The enumeration commands Huntress observed — whoami /priv, cmdkey /list, net group — are the beginning of this phase, not the end. cmdkey /list specifically enumerates stored credentials in Windows Credential Manager, which on enterprise endpoints often includes RDP credentials, service account passwords, and shared network resource access. net group "Domain Admins" /domain identifies which accounts are worth targeting next. From a SYSTEM shell with extracted credentials, an attacker can use wmic, PsExec equivalents, or WMI lateral movement to pivot to other hosts on the same network segment without touching the domain controller directly.

Persistence. SYSTEM-level access enables persistence mechanisms that survive reboots and survive Defender's recovery logic. A service created via sc.exe create at SYSTEM privilege runs under LocalSystem context at startup. Registry run keys under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run — writable at SYSTEM — survive user logoffs. Scheduled tasks created at SYSTEM privilege persist across patches and user account changes. WMI event subscriptions can trigger payloads on specific system events with no process visible in Task Manager. All of these techniques are available the moment RedSun succeeds.

The Defender loop. With SYSTEM access and UnDefend already deployed, an attacker can now pursue deeper Defender bypass: the SYSTEM → TrustedInstaller privilege elevation path using token impersonation allows unloading WdFilter.sys, the kernel minifilter driver that sits below Defender's file system protection layer. Unloading that driver effectively removes Defender's ability to intercept file operations at the kernel level. This is the difference between an attacker who is operating while Defender is blind to new signatures versus an attacker who has surgically removed Defender's ability to see file operations at all.

On the order of operations — there is a legitimate debate here: The natural instinct is to describe this as escalate-first-then-blind. However, UnDefend's signature-blocking operates at standard user privilege and does not require SYSTEM rights. An attacker with only an unprivileged shell can deploy UnDefend in passive mode immediately after gaining initial access, before attempting the RedSun escalation. This means Defender's signature update pipeline can be silently cut off from the moment of initial foothold, before any privilege escalation attempt appears in logs. The order is flexible, and defenders should not assume that RedSun execution is a necessary prerequisite for UnDefend activity.

Huntress observed exactly this pattern in the wild. In one documented case, a threat actor used compromised FortiGate VPN credentials to access a network, then deployed UnDefend and RedSun on the same Windows device before beginning credential discovery and lateral movement. After initial access, the attacker ran standard enumeration commands: whoami /priv, cmdkey /list, net group. These are hands-on-keyboard reconnaissance steps. Then the RedSun and UnDefend binaries were executed from user-writable folders, some renamed to blend with legitimate filenames. Huntress described this activity as indicating a skilled adversary conducting targeted intrusions rather than opportunistic automated exploitation. The SSL VPN entry vector — specifically a compromised FortiGate VPN appliance, as documented by Huntress — is a meaningful detail: it confirms this kill chain is being deployed in scenarios where the attacker already has some degree of access but needs to escalate and entrench.

That context matters: Huntress's 2026 Cyber Threat Report found that roughly 70 percent of active intrusions its SOC catches begin with adversaries simply authenticating through VPN access — not exploiting the VPN itself, but logging in with credentials that were already stolen. RedSun does not need a novel initial access technique. It needs only the kind of foothold that is already arriving at enterprises daily through credential theft, phishing, and infostealer markets. The privilege escalation step is what converts that ordinary initial foothold into full SYSTEM control with no additional exploit required.

Detection and Interim Mitigation

The absence of a patch means defenders need to operate on behavioral detection until Microsoft issues a fix. Static signature detection alone is insufficient for either exploit. Because the vulnerability lives in how Windows components interact rather than in a specific file, an attacker can recompile RedSun from source, change the binary hash, and defeat sample-based detection while the underlying technique remains fully intact. The behaviors that remain consistent regardless of compilation are what matter.

On whether an out-of-band patch is coming: As of this writing, Microsoft has not indicated whether emergency out-of-band patches are forthcoming for RedSun or UnDefend, or whether fixes will wait for the next scheduled Patch Tuesday. Given that both exploits have been confirmed active in real-world intrusions and their PoC code is publicly accessible on GitHub, some security researchers have argued that an expedited patch is warranted. Microsoft has not commented publicly on timelines. Defenders should operate under the assumption that a patch is not imminent rather than waiting for one before acting.

Why fixing this class of vulnerability is not trivial — and why more variants may follow: The underlying architectural problem is not a single logic flaw; it is a design assumption. Defender operates at SYSTEM privilege, therefore its writes are assumed to go to authorized paths. The mechanism that breaks that assumption — attacker-influenced path resolution during a SYSTEM write — is what both BlueHammer and RedSun exploit. The BlueHammer fix validated one specific oplock-plus-VSS interaction. RedSun uses a different API path entirely (CfRegisterSyncRoot rather than VSS), and the BlueHammer patch did not touch it. A genuine class fix would require Defender's remediation engine to canonicalize all write targets before committing — resolving the final path after all reparse points, verifying it falls within an expected namespace, and rejecting the write if it does not. That is a non-trivial change to code paths that handle file operations across every supported Windows version. Several security researchers have noted publicly that more variants targeting other Defender code paths are likely to follow from this disclosure, since the root cause is not yet patched at the architectural level.

Monitoring Priorities

Baseline the SHA-256 hash of C:\Windows\System32\TieringEngineService.exe on every endpoint in your environment immediately. Any modification to that file is a confirmed compromise indicator for RedSun. This is a high-confidence signal with an extremely narrow false positive surface.

On the BlueHammer detection name and what it tells you: Defender's detection for BlueHammer is Exploit:Win32/DfndrPEBluHmrBZ. Huntress observed this firing on April 10 during the documented intrusion — and the attacker's subsequent pivot to RedSun on April 16 is directly explained by it: Defender caught BlueHammer, so the attacker switched to a technique Defender could not see. If your logs show Exploit:Win32/DfndrPEBluHmrBZ from any endpoint, treat it as a confirmed hands-on-keyboard intrusion attempt even if Defender reports it blocked, because the absence of a RedSun alert in the same timeframe does not mean RedSun was not tried afterward. The attacker in the Huntress case renamed the RedSun binary to z.exe before executing it — a step that bypasses any name-based alert while the underlying exploit behavior remains unchanged.

Alert on Cloud Files sync root registration by untrusted processes. Calls to NtQueryDirectoryObject targeting HarddiskVolumeShadowCopy* from user-space processes that are not backup tooling or system processes have no legitimate use case in this context and should trigger immediate investigation. Watch for NTFS junction or reparse point creation in user-writable directories during the same timeframe as a Defender EICAR alert. As noted above, the EICAR alert itself is not a detection of the exploit — but the combination of an EICAR detection followed immediately by junction activity in the user profile is a behavioral signature for the RedSun execution sequence. A provider named SERIOUSLYMSFT registered via CfRegisterSyncRoot will not appear in any legitimate deployment and is a direct indicator of RedSun activity.

For UnDefend, monitor MsMpEng.exe for unexpected service stop events or failures to load the engine, particularly during periods when Microsoft is pushing platform updates. Alert on any detection where Defender reports healthy in the management console while signature update activity has gone silent for an anomalous period. A Defender instance that has not received a signature update in several hours during normal operations is worth investigating. The Undef.exe process name with the command line argument -agressive (note the spelling with one 's' — as observed in Huntress telemetry from the wild) spawned as a child process of cmd.exe under Explorer.EXE is a high-confidence UnDefend indicator.

Layered Defense Posture

Organizations relying on Defender as their sole endpoint protection layer carry materially elevated risk from these two unpatched exploits. A third-party EDR deployed alongside Defender provides detection capability for Defender-specific bypasses and anomalous filesystem operations that Defender itself cannot flag about its own behavior. Huntress and Cyderes have both demonstrated working detection for these specific techniques.

On running Defender in passive mode as an interim measure: Blackswan Cybersecurity and the Cloud Security Alliance both recommend running Defender in passive mode alongside a third-party real-time protection solution, particularly for high-risk or internet-facing endpoints. The reason this matters here is specific: in passive mode, Defender provides telemetry and logging but hands primary file enforcement to the alternative product. Because Defender's cloud file remediation activity — the exact behavior RedSun exploits — is reduced in passive mode, the attack surface for the RedSun technique narrows. This is not a universal recommendation — it only makes sense if you already have a fully functional alternative real-time AV in place. Running Defender in passive mode without a replacement means losing real-time protection entirely, which is worse. The point is that this is a legitimate interim mitigation worth evaluating if you have the stack to support it, not a workaround that applies to everyone.

On Tamper Protection — an important caveat defenders need to understand: Multiple advisories recommend enabling Defender Tamper Protection as a mitigation step. That is sound advice for defense-in-depth, and you should have it enabled. But defenders need to understand its limits here. Tamper Protection prevents standard users and even administrative processes from modifying Defender's core settings through the registry or PowerShell — it blocks many conventional disable-Defender techniques. What it does not block is post-SYSTEM-escalation abuse. Once an attacker achieves SYSTEM through RedSun, they are positioned to pursue deeper bypass techniques: the SYSTEM → TrustedInstaller privilege path can be used to unload the WdFilter.sys kernel minidriver, which disables tamper protection itself. Tamper Protection raises the cost and complexity of a follow-on attack, which is valuable — but it does not neutralize the risk once SYSTEM is achieved. Enable it, and understand that the real goal is to prevent that SYSTEM escalation from succeeding in the first place, not to rely on tamper protection as a backstop after it does.

For organizations without managed detection services, enabling Attack Surface Reduction rules reduces common initial access vectors. Block the known IOC file hashes at endpoint controls. Hunt for binaries named UnDefend.exe, Undef.exe, FunnyApp.exe, z.exe, or RedSun.exe staged in low-privilege user folders including Downloads, Pictures, and AppData. Renamed variants are in circulation, so hash-based hunting should supplement name-based hunting rather than replace it. Where your environment permits it, restrict CfRegisterSyncRoot calls from non-system, non-approved processes via application control policy. Consider auditing Cloud Files sync root registrations on high-value endpoints where OneDrive and similar services are not actively used — with the caveat that this affects legitimate cloud storage functionality and should be tested in a non-production environment before broad deployment.

Does Tamper Protection Stop This?

No — and this needs a careful explanation because "enable Tamper Protection" appears in virtually every advisory covering these exploits, including from organizations that should be more precise.

Tamper Protection prevents standard users and even local administrators from disabling Defender through conventional channels: registry edits to HKLM\SOFTWARE\Microsoft\Windows Defender, PowerShell Set-MpPreference commands, Group Policy overrides pushed locally. It is a meaningful hardening control that raises the cost of disabling Defender through conventional means. You should absolutely have it enabled.

What it does not protect against is the specific attack chain these exploits enable. RedSun does not attempt to disable Defender — it exploits Defender's own remediation logic to execute arbitrary code. Tamper Protection has no surface to protect against an exploit that weaponizes Defender's intended behavior rather than trying to stop it. Once RedSun succeeds and the attacker has a SYSTEM shell, they are elevated above the process level at which Tamper Protection enforces its restrictions. From SYSTEM, the path to TrustedInstaller via token impersonation opens. TrustedInstaller can unload WdFilter.sys directly, which bypasses Tamper Protection entirely because the unload happens at the kernel driver level rather than through the Defender settings interface Tamper Protection monitors. UnDefend's passive mode signature blocking similarly does not touch the settings Tamper Protection guards — it operates on the update delivery mechanism, not on Defender's configuration interface.

Enable Tamper Protection. But understand that its value here is as a speed bump against follow-on hardening removal by less sophisticated actors, not as a control that closes the RedSun or UnDefend attack paths.

What About Microsoft Defender for Endpoint?

This is the question enterprise security teams are asking that almost no coverage answers. There is a meaningful difference between Windows Defender (the built-in antimalware component, formerly called Windows Defender Antivirus) and Microsoft Defender for Endpoint (MDE, formerly MDATP) — the enterprise EDR product that includes behavioral detection, advanced hunting via KQL, and cloud-delivered analytics.

The detection gap discussed throughout this article applies specifically to Windows Defender's antimalware engine — the component responsible for real-time file scanning and the EICAR alert. MDE's behavioral detection layer operates separately from that engine and has different visibility. MDE's EDR sensors monitor process creation, file system events, network connections, and registry modifications through kernel-level telemetry that is not dependent on the antimalware signature database UnDefend starves. An MDE deployment with properly configured detection rules can alert on the behavioral patterns RedSun and UnDefend produce — the sync root registration, the reparse point creation, the junction activity during an EICAR event, the process tree of Undef.exe -agressive under Explorer — even when standalone Defender does not.

However, two caveats apply. First, MDE behavioral detection is only as useful as the rules and hunting queries configured against it — default alert thresholds may not catch these specific behaviors without customization. Second, once an attacker achieves SYSTEM and pursues the TrustedInstaller path to unload WdFilter.sys, the kernel minifilter that feeds MDE's file system telemetry is removed. MDE loses its file system event visibility on that endpoint at that point. The window between initial RedSun execution and kernel driver unload is the detection opportunity; once it closes, the sensor goes dark.

Organizations running MDE should prioritize building custom detection rules targeting the specific IOCs documented in this article — particularly the SERIOUSLYMSFT sync root registration and the TieringEngineService.exe hash change — in their Advanced Hunting workspace before those behavioral windows close.

Cloud Workloads, Virtual Machines, and MSP Risk

Cloud Workloads and Virtual Machines

The scope statement throughout most coverage — "Windows 10, Windows 11, Windows Server 2019 and later" — is accurate but understates the operational reach of these exploits for organizations running cloud infrastructure.

Azure virtual machines running Windows Server with Defender enabled are in scope. So are Windows Server instances running in AWS EC2, Google Cloud, or any other IaaS provider. The attack surface is the operating system and the Defender antimalware component — the hypervisor layer does not provide any protection against a privilege escalation that targets a Windows process running inside a guest VM. If the guest OS is Windows Server 2019+ with Defender active and an attacker has a shell inside that VM (via a web application exploit, a misconfigured RDP endpoint, or a compromised service account), RedSun works.

For organizations using Windows virtual desktop infrastructure — Azure Virtual Desktop, Citrix on Windows, VMware Horizon — the risk has a multiplier effect. A single shared session host running multiple user sessions under the same underlying OS gives an attacker who escalates in one session SYSTEM access that spans the entire host. Other users' active sessions, their cached credentials, and any data accessible through the host's service accounts all become reachable.

Cloud Security Groups and network segmentation provide no protection here because the exploit requires only local process execution, not inbound network connectivity. A compromised application running on a locked-down cloud Windows Server with no inbound ports exposed is still a valid RedSun launch point.

MSP and MSSP Exposure

Managed service providers represent a disproportionately high-value target for this kill chain, and no other coverage of these exploits has addressed the MSP angle directly.

The typical MSP deployment involves a Remote Monitoring and Management (RMM) agent running as a service on client endpoints under a service account with administrative or SYSTEM-level rights. Those credentials — stored on the endpoint, cached in Windows Credential Manager, or accessible through the RMM platform's authentication mechanism — are exactly what cmdkey /list is designed to enumerate. An attacker who uses RedSun to escalate on a single client endpoint and then runs that enumeration may find the MSP's administrative credentials cached or stored there.

From those credentials, the blast radius expands to every endpoint that MSP manages across all clients. This is not a theoretical scenario — it is the operational pattern that has driven multiple large-scale MSP compromise events in recent years. The RedSun/UnDefend toolkit does not change the underlying logic; it lowers the barrier to achieving the initial SYSTEM escalation that makes the MSP's cross-client credential exposure reachable.

MSPs running Defender on client endpoints without a secondary EDR layer and without actively monitoring for UnDefend's signature staleness pattern carry compounded risk: one compromised client endpoint can yield credentials that enable lateral movement across the MSP's entire managed estate before any alert fires.

Is There CISA Guidance or a KEV Entry?

As of April 19, 2026, CISA has not added RedSun or UnDefend to the Known Exploited Vulnerabilities catalog. This is partly a function of the KEV process: catalog entries require a CVE identifier, and neither RedSun nor UnDefend has been assigned one. The KEV catalog is a CVE-centric list by design, which means vulnerabilities actively exploited in the wild but not yet formally tracked can sit outside it even while threat actors are deploying them.

BlueHammer (CVE-2026-33825) is a candidate for KEV addition given Huntress's confirmed wild exploitation evidence, but as of this writing no CISA advisory specific to this cluster has been published. CISA's general guidance on keeping Windows Defender updated and applying Patch Tuesday cumulative updates applies, but provides no specific mitigation for the unpatched pair.

Organizations operating under federal compliance frameworks (FedRAMP, FISMA, CMMC) or following CISA's Binding Operational Directives should not wait for a KEV entry or a CISA advisory to act on these. The Huntress confirmation of active exploitation is sufficient evidence to treat these as exploited vulnerabilities regardless of their catalog status. The absence of a CVE does not reduce the operational risk.

Retrospective Forensic Triage — If You Think You May Already Be Compromised

The detection guidance above focuses on alerting to future RedSun and UnDefend activity. But a meaningful number of readers will be asking a different question: could this have already happened on my endpoints before I knew about it? Here is what to look for.

Check TieringEngineService.exe immediately. Run a hash comparison of C:\Windows\System32\TieringEngineService.exe against a known-good baseline from a clean system running the same OS and patch level. On Windows, Get-FileHash C:\Windows\System32\TieringEngineService.exe -Algorithm SHA256 generates the hash in under a second. Any deviation from the expected value on a patched system is a confirmed compromise indicator. This is the single highest-confidence post-incident check available for RedSun.

Review Defender protection history for EICAR alerts. An EICAR alert that has no corresponding legitimate file or test in your environment — particularly one sourced from a user's Downloads or Pictures folder from an unusual binary name — should be treated as a suspected RedSun execution attempt. The command Get-MpThreatDetection | Where-Object {$_.Resources -like "*EICAR*"} will surface these from Defender's local history.

Audit Cloud Files sync root registrations. The registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager holds all registered sync root providers. Any entry that is not OneDrive, SharePoint, Dropbox, Box, or another known cloud storage client installed in your environment is suspicious. An entry with the name or path containing SERIOUSLYMSFT is a confirmed RedSun indicator.

Check Defender signature update timestamps. Get-MpComputerStatus | Select-Object AntivirusSignatureLastUpdated, AntispywareSignatureLastUpdated shows when the last signature update arrived. If the timestamp is anomalously old — more than several hours in an environment that normally updates regularly — and the Defender service appears healthy, investigate for UnDefend passive mode. Compare against update timestamps on other endpoints in the same network segment.

Look for the two-letter subfolder in Downloads. Huntress telemetry documented the exploit binary staged in a two-letter subdirectory inside the user's Downloads folder before execution. Hunting for dir /ad C:\Users\*\Downloads\?? across endpoints via your RMM or EDR may surface staging artifacts that predate the execution event.

Review Defender event log for Exploit:Win32/DfndrPEBluHmrBZ. This is the BlueHammer detection name. If it fired on an endpoint — even if Defender reported it as blocked — treat the endpoint as a likely RedSun target. The documented intrusion pattern was BlueHammer attempt (blocked April 10) followed by RedSun execution (April 16). The gap between those events represents the attacker regrouping and switching tools.

Hunt Event ID 4724 on local Administrator accounts — especially in rapid pairs. BlueHammer resets a local Administrator password to an attacker-controlled value ($PWNed666!!!WDFAIL) using SamiChangePasswordUser, authenticates, and then restores the original hash — all within a few seconds. SamiChangePasswordUser is a privileged reset call (one account forcibly resetting another's password), which generates Event ID 4724 — "an attempt was made to reset an account's password." The restore step generates a second 4724 in close succession. Event ID 4723 ("a user attempted to change their own password") may also appear depending on how the SAM call is mediated, but 4724 is the primary artifact. Two Event ID 4724 entries on the local Administrator account within seconds, with no corresponding RDP session, console logon, or administrative task visible in the event log context, is a confirmed BlueHammer execution indicator that survives the cleanup step.

Look for GUID-named temporary services. BlueHammer uses CreateService to register a short-lived temporary service with a GUID-style name in the Service Control Manager. This service entry appears briefly in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services before being deleted. Sysmon Event ID 13 (registry value set) targeting that key from a non-administrative user process is a detection signal. A service entry with a GUID name created by a process running under a standard user account — even briefly — has no legitimate explanation.

Check for anomalous IUpdateSearcher COM API calls from non-system processes. BlueHammer polls for pending Defender updates via the Windows Update Agent COM interface from the exploit binary. On modern Windows (10 1903 and later, Windows 11), the Windows Update Agent COM interface is hosted in svchost.exe under the wuauserv (Windows Update) or UsoSvc (Update Orchestrator Service) services — wuauclt.exe is a legacy stub in these OS versions and its presence as an active process should itself be flagged. A call to IUpdateSearcher specifically filtering for KB2267602 from any process other than svchost.exe hosting wuauserv or UsoSvc, or a known update management agent, is anomalous. This signal predates the oplock and filesystem manipulation stages, representing an early-stage detection opportunity before the escalation completes.

How to Respond to RedSun and UnDefend Right Now

The following is a prioritized response sequence for security teams acting today, while no Microsoft patch exists for RedSun or UnDefend. Work through these steps in order. Estimated total time for a single-endpoint baseline plus environment-wide hunt: 2 to 4 hours. For larger estates, steps 3, 4, and 5 can be automated through EDR or RMM platforms.

1. Apply April 2026 Patch Tuesday updates across the estate. This closes BlueHammer (CVE-2026-33825) but does not address RedSun or UnDefend. Verify the Defender antimalware platform is at build 4.18.26030.3011 or later with Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion. Endpoints not on this build remain exposed to the BlueHammer leg of the chain.
2. Baseline the SHA-256 hash of TieringEngineService.exe on every endpoint. Run Get-FileHash C:\Windows\System32\TieringEngineService.exe -Algorithm SHA256 on a known-clean reference system at the same OS and patch level, then compare against every production endpoint. Any hash deviation on a patched endpoint is a confirmed RedSun compromise indicator. This is the highest-confidence single check available.
3. Hunt for the exploit binaries in user-writable folders. Search %USERPROFILE%\Downloads, %USERPROFILE%\Pictures, and %TEMP% across all endpoints for files named RedSun.exe, FunnyApp.exe, UnDefend.exe, Undef.exe, or z.exe. Huntress telemetry documented the exploit staged in two-letter subfolders inside Downloads, so expand the hunt to Downloads\??\*.exe as well. Renamed variants defeat name-based hunting, so pair this with SHA-256 hash checking against the published IOC sets.
4. Audit the Cloud Files sync root registry for SERIOUSLYMSFT. Examine HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager on every endpoint. A provider entry containing the string SERIOUSLYMSFT is an unambiguous RedSun execution indicator with zero legitimate false positives. Legitimate providers are OneDrive, SharePoint, Dropbox, Box, or the equivalents actively deployed in your environment.
5. Check Defender signature freshness against peer endpoints. Run Get-MpComputerStatus | Select-Object AntivirusSignatureLastUpdated, AntispywareSignatureLastUpdated across the estate. Any endpoint where the signature timestamp is materially older than the peer median — while the Defender service reports healthy — is a suspected UnDefend passive mode victim. The management console will not alert on this; it requires active hunting against the timestamp field.
6. Review Defender protection history for EICAR alerts from user folders. Run Get-MpThreatDetection | Where-Object {$_.Resources -like "*EICAR*"} to surface recent EICAR detections. Any EICAR alert sourced from a Downloads or Pictures path from an unusual binary name is a suspected RedSun execution attempt — the EICAR hit is the lure firing, not the exploit being blocked.
7. Enable Defender Tamper Protection on every endpoint. Tamper Protection does not stop RedSun or UnDefend directly, but it raises the cost of follow-on hardening removal by less sophisticated actors. Configure via Intune or Group Policy at the tenant level. Verify with Get-MpPreference | Select-Object TamperProtectionSource.
8. Deploy or validate a third-party EDR layer. Environments relying on Defender as the sole endpoint protection carry materially elevated risk from this cluster. A secondary EDR provides detection of Defender-specific bypasses and anomalous filesystem operations that Defender cannot flag about its own behavior. If a mature alternative AV/EDR is already deployed, evaluate running Defender in passive mode to reduce its cloud file remediation attack surface while awaiting the patch.
9. Build behavioral detection rules targeting the documented IOCs. In Microsoft Defender for Endpoint Advanced Hunting, SentinelOne, CrowdStrike, or your XDR of choice, create alerts for: Cloud Files sync root registrations with provider name SERIOUSLYMSFT, NTFS mount-point reparse (tag 0xA0000003) creation in user-writable directories during EICAR alert windows, Undef.exe or renamed equivalents with command-line argument -agressive (note the single-s misspelling) spawned under cmd.exe, and unexpected hash changes to TieringEngineService.exe.
10. Hunt for Event ID 4724 pairs on local Administrator accounts. BlueHammer generates two Event ID 4724 entries within seconds on the local Administrator account as it resets the password to $PWNed666!!!WDFAIL, authenticates, then restores the original hash. Pair events with no corresponding RDP or console session are a confirmed BlueHammer execution indicator that survives the cleanup step. If this pattern appears in logs, treat the endpoint as a likely RedSun target even if Defender blocked the initial BlueHammer attempt.
11. Restrict execution from Downloads and Pictures folders. Apply AppLocker or Windows Defender Application Control rules blocking executable launch from %USERPROFILE%\Downloads and %USERPROFILE%\Pictures. Where full block is operationally difficult, enable Attack Surface Reduction rule D4F940AB-401B-4EFC-AADC-AD5F3C50688A ("Block executable content from email client and webmail"). Test in audit mode before enforcement.
12. Subscribe to MSRC advisories and monitor for out-of-band guidance. Microsoft has not committed to an emergency patch timeline for RedSun or UnDefend. Given confirmed active exploitation, an expedited out-of-band release is plausible. Subscribe to the MSRC security update guide RSS feed and watch for advisories referencing TieringEngineService.exe, cldapi.dll, or Defender cloud file remediation. Re-baseline and re-scan every endpoint within 24 hours of any patch release.

Frequently Asked Questions

What are RedSun and UnDefend?

RedSun is an unpatched local privilege escalation zero-day that abuses Microsoft Defender's cloud file rollback mechanism to write an attacker-controlled binary into System32 and execute it as SYSTEM. UnDefend is a companion tool that either silently blocks Defender from receiving signature updates (passive mode, works at standard user privilege) or fully disables Defender when Microsoft pushes a major platform update (aggressive mode), without triggering alerts in management consoles.

Is there a patch for RedSun and UnDefend?

As of April 19, 2026, there is no patch available for RedSun or UnDefend. Microsoft's April 2026 Patch Tuesday only addressed BlueHammer, tracked as CVE-2026-33825. RedSun and UnDefend have no assigned CVE identifiers and no official remediation timeline from Microsoft. The next scheduled Patch Tuesday is weeks away, and Microsoft has not committed to an out-of-band release.

Does the CVE-2026-33825 patch fix RedSun?

No. CVE-2026-33825 applies exclusively to BlueHammer. Some coverage incorrectly pairs this CVE number with RedSun. The BlueHammer patch addressed a specific oplock-plus-VSS interaction in Defender's remediation logic. RedSun uses a completely different attack path via the Cloud Files API and is not mitigated by the BlueHammer fix.

Does Defender detect the RedSun exploit?

No. Defender fires a Virus:DOS/EICAR_Test_File alert during a RedSun attack because the bait file contains an EICAR test string, but this is the lure working as designed, not a detection of the privilege escalation. Vulnerability analyst Will Dormann confirmed that Defender does not detect the exploit itself in either the EICAR variant or an encrypted variant of the bait file. By contrast, BlueHammer was detected and blocked by Defender as Exploit:Win32/DfndrPEBluHmrBZ — which is precisely why the attacker in the Huntress-documented intrusion pivoted to RedSun.

What platforms are affected?

RedSun and UnDefend affect Windows 10, Windows 11, and Windows Server 2019 and later with Microsoft Defender real-time protection and cldapi.dll present. Exploitation has been confirmed on fully patched systems including those with the April 2026 cumulative updates applied. The cldapi.dll qualifier is significant: the Windows Cloud Files API library ships with Windows 10 version 1709 and later as a core OS component, so endpoints that have never deployed OneDrive are still in scope.

How did attackers get initial access in the confirmed Huntress intrusion?

Huntress documented an intrusion where the initial access vector was a compromised FortiGate VPN. The attacker authenticated without triggering alerts, then ran standard enumeration commands (whoami /priv, cmdkey /list, net group) before deploying RedSun and UnDefend from user-writable folders on a Windows endpoint. Huntress has separately noted that roughly 70 percent of the active intrusions its SOC catches begin with adversaries simply authenticating through VPN access using stolen credentials.

Does UnDefend require administrator rights?

No. UnDefend operates at standard user privilege in its passive mode, silently blocking Defender signature updates without requiring elevation. This means an attacker can deploy UnDefend immediately after gaining initial access, before any privilege escalation attempt, cutting off Defender's update pipeline from the moment of first foothold.

Does Microsoft Defender for Endpoint (MDE) detect RedSun and UnDefend?

Microsoft Defender for Endpoint's behavioral detection layer operates separately from the antimalware signature engine and has different visibility. MDE can alert on the behavioral patterns RedSun and UnDefend produce — sync root registration, reparse point creation, junction activity during an EICAR event — even when standalone Defender does not. However, default alert thresholds may need customization to catch these specific behaviors, and once an attacker achieves SYSTEM and unloads WdFilter.sys via the TrustedInstaller path, MDE loses file system event visibility on that endpoint. Organizations running MDE should build custom detection rules targeting the SERIOUSLYMSFT sync root registration and TieringEngineService.exe hash changes.

Are cloud workloads and virtual machines vulnerable to RedSun?

Yes. Azure VMs, AWS EC2 Windows instances, and any Windows Server 2019+ guest VM running Defender is in scope. The hypervisor layer provides no protection against a privilege escalation targeting a Windows process inside the guest. Windows virtual desktop infrastructure (Azure Virtual Desktop, Citrix on Windows) carries additional risk because a single shared session host may give an attacker who escalates in one session SYSTEM access that spans the entire host and all users on it.

Are MSPs at heightened risk from RedSun and UnDefend?

Yes. MSPs represent a disproportionately high-value target. RMM agent credentials stored on client endpoints are exactly what the cmdkey /list enumeration step in the documented intrusion is designed to surface. An attacker who escalates on a single client endpoint using RedSun and finds the MSP's administrative credentials can pivot to every endpoint that MSP manages across all clients. MSPs running Defender without a secondary EDR layer and without monitoring for UnDefend's signature staleness pattern carry compounded cross-client risk.

Has CISA issued guidance or added these exploits to the KEV catalog?

As of April 19, 2026, CISA has not added RedSun or UnDefend to the Known Exploited Vulnerabilities catalog. The KEV catalog requires a CVE identifier, and neither exploit has been assigned one. Organizations operating under federal compliance frameworks should not wait for a KEV entry — Huntress's confirmation of active exploitation is sufficient evidence to treat these as exploited vulnerabilities regardless of catalog status.

How do I check if my endpoints may already have been compromised by RedSun?

The highest-confidence check is to hash C:\Windows\System32\TieringEngineService.exe using Get-FileHash and compare it against a known-good baseline from a clean system at the same OS and patch level. Any deviation is a confirmed RedSun compromise indicator. Also audit the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SyncRootManager for any provider named SERIOUSLYMSFT, check Defender protection history for anomalous EICAR alerts sourced from user-writable folders, and compare Defender signature update timestamps against other endpoints in the same network segment.

Who released RedSun and UnDefend, and why?

The tools were released publicly by a security researcher using the aliases Nightmare-Eclipse and Chaotic Eclipse, as a protest against how Microsoft's Security Response Center handled their prior vulnerability disclosures. Microsoft's April 2026 Patch Tuesday credited the BlueHammer fix to researchers Zen Dodd and Yuanpei Xu, not to Nightmare-Eclipse. The researcher publicly stated that MSRC dismissed their reports and characterized Microsoft's approach to the research community as unsupportive. Microsoft issued a statement affirming its commitment to coordinated vulnerability disclosure but did not address the researcher's specific grievances or provide a timeline for patching RedSun and UnDefend.

The Disclosure Ethics Question

This is the question security professionals are debating and most coverage either ignores or handles with a single dismissive sentence. It deserves a direct treatment.

Nightmare-Eclipse published working exploit code for RedSun and UnDefend before Microsoft had issued patches. Two of the three exploits in this cluster went public with no patch in sight and have since been used against real organizations. That is an outcome the security community cannot simply accept as an inevitable feature of the disclosure ecosystem.

The researcher's stated grievance is not frivolous. Microsoft's attribution of CVE-2026-33825 to Zen Dodd and Yuanpei Xu — when Nightmare-Eclipse claims to have reported the vulnerability and been ignored — describes a pattern the community has seen before. Several high-profile disclosures in the past decade have followed the same arc: researcher reports to vendor, vendor ignores or delays, another party gets credit at patch time, researcher goes public in frustration. Whether or not the specific facts of this case support that narrative, the pattern is real and the frustration is legitimate.

At the same time, the harm is also real. Real organizations were compromised because working exploit code for an unpatched vulnerability was publicly available. The attacker who used compromised FortiGate credentials and then executed RedSun.exe from a Downloads folder was not performing security research. They were an adversary who used a publicly available tool to breach an organization. The researcher's dispute with Microsoft does not change the downstream impact on the organizations that were hit.

This tension is not resolvable with a clean verdict. What it does clarify is a systemic failure: a vendor process that treats security researchers dismissively, declines to communicate on disclosure timelines, and credits disclosures in ways that alienate independent researchers is creating the conditions for exactly this kind of frustration-driven full public release. The answer to "should researchers publish working exploits before patches exist" is clearly no — but the answer to "should vendors take researcher grievances seriously enough to prevent that outcome" is equally clearly yes, and the industry's record on the second question is why the first question keeps arising.

Sources and Further Reading

The following sources were used in the research and verification of this article. All were current as of April 19, 2026.

• Huntress: Attackers Love Your VPN To-Do List — Primary source for wild exploitation details, enumeration command sequence, FortiGate VPN entry vector, and the rename-to-z.exe detail
• The Hacker News: Three Microsoft Defender Zero-Days Actively Exploited; Two Still Unpatched — Huntress SOC reporting and Microsoft statement sourcing
• Help Net Security: Researcher drops two more Microsoft Defender zero-days, all three now exploited in the wild — April 16 publication date, Zen Dodd / Yuanpei Xu attribution detail
• BleepingComputer: Recently leaked Windows zero-days now exploited in attacks — Affected platform scope and PoC mechanics
• Blackswan Cybersecurity Threat Advisory: RedSun Zero-Day, April 17, 2026 — April 15 publication date, SERIOUSLYMSFT provider name, full PoC exploit chain verification, passive mode recommendation
• Ampcus Cyber Shadow Ops Intel: RedSun and UnDefend Zero-Day Exploits Hit Defender — BlueHammer mechanism details (VSS oplock, NTLM hash extraction path), UnDefend mode descriptions, MpSvc.dll root cause
• CSO Online: Caught, Quarantined, Re-Installed — RedSun Turns Microsoft Defender On Itself — Will Dormann quotes and Defender non-detection confirmation; MSRC non-response detail
• Cloud Security Alliance Research Note: Defender Zero-Days BlueHammer, RedSun, UnDefend — Independent academic cross-verification and passive mode recommendation sourcing

Key CyberSpit Notes

1. The patch gap is real and currently open: Applying April 2026 Patch Tuesday only closes BlueHammer (CVE-2026-33825). Despite some headlines pairing that CVE with all three exploits, RedSun and UnDefend are separate vulnerabilities with no CVE and no patch. The exposure window is unknown.
2. Defender-only environments face a specific structural risk: UnDefend is engineered to deceive exactly the monitoring approach that relies on Defender's own health reporting. Organizations without a secondary detection layer have no reliable visibility into whether UnDefend has already executed in their environment.
3. The EICAR alert is not a catch: Defender firing a Virus:DOS/EICAR_Test_File alert during RedSun execution means the bait file worked as designed. Defender does not detect the privilege escalation itself. This distinction matters enormously for defenders who see an EICAR alert and assume the threat was contained.
4. The chained attack is operational today: These are not theoretical research artifacts. Huntress confirmed hands-on-keyboard intrusion activity using all three tools in a documented case, with entry via compromised FortiGate VPN credentials. The kill chain from unprivileged access to undetected SYSTEM-level persistence is in active use.
5. Tamper Protection does not stop RedSun or UnDefend: It raises the cost of conventional Defender disabling through registry and PowerShell paths. It does not protect against an exploit that weaponizes Defender's own behavior rather than trying to disable it, and it does not survive a SYSTEM → TrustedInstaller escalation to unload WdFilter.sys.
6. Cloud and virtual environments are fully in scope: Azure VMs, EC2 Windows instances, VDI session hosts, and any Windows Server 2019+ guest running Defender are all vulnerable. The hypervisor layer provides no protection. VDI environments carry additional risk because SYSTEM access on a shared session host spans all users on that host.
7. MSPs carry compounded cross-client exposure: RMM agent credentials stored on any single client endpoint are a high-value RedSun post-exploitation target. One successful escalation in one client environment can yield credentials that reach every endpoint the MSP manages. The absence of a secondary EDR layer across a managed estate multiplies this risk significantly.
8. The KEV catalog gap is not a safety signal: Neither RedSun nor UnDefend has a CVE, so neither can appear in CISA's KEV catalog. The absence of a catalog entry does not mean these exploits are not actively used. Active exploitation is confirmed. Treat them as KEV-equivalent for prioritization purposes.
9. Expect more variants from this vulnerability class: The BlueHammer patch addressed one specific code path. The underlying class of vulnerability — attacker-influenced path resolution under a SYSTEM write — remains unaddressed architecturally. Multiple security researchers have noted that other Defender code paths with similar assumptions are likely to be targeted next. This is not a one-and-done disclosure event.
10. Behavioral detection is the only meaningful defense right now: Static signatures will not reliably catch recompiled variants. The indicators that matter are filesystem behaviors, process relationships, service health anomalies, and sync root registration by untrusted processes — not binary hashes alone.

The situation with RedSun and UnDefend is one where waiting on the vendor is not a viable security posture. The exploits are public, the PoC works against fully patched systems, and threat actors have already incorporated them into live operations that began with something as ordinary as compromised VPN credentials. The gap between disclosure and patch exists whether or not an organization acknowledges it, and the endpoint security tool that was supposed to be the last line of defense is currently the attack surface. Defenders who treat this as a patch management item to queue for next cycle are operating on an assumption this threat does not support.