TL;DR

A pseudonymous researcher dumped three Microsoft Defender zero-days on the internet in 13 days. Microsoft patched one (BlueHammer, CVE-2026-33825) on April 14. The other two, RedSun and UnDefend, were dropped on GitHub on April 16, and Huntress saw real attackers wiring them into intrusions within hours. As of today, RedSun and UnDefend have no patch, no CVE, and no out-of-band fix on the calendar.

What happened

On April 3, a researcher using the handles “Chaotic Eclipse” and “Nightmare Eclipse” posted proof-of-concept code for a Microsoft Defender bug they called BlueHammer. They said MSRC had refused to triage their report without a video demo, and they were tired of waiting. Microsoft assigned CVE-2026-33825 and shipped a patch on the April 14 Patch Tuesday rollup, rated CVSS 7.8.

On April 16, the same researcher dropped two more PoCs: RedSun and UnDefend. Both work against fully-patched Windows 10, Windows 11, and Windows Server 2019 and later. Both abuse Defender itself — the thing that’s supposed to be protecting the box. Within a day, Huntress was watching the exploits run in customer environments.

“I was not bluffing Microsoft, and I’m doing it again.” — Chaotic Eclipse, on the second drop.

The unpatched bugs aren’t theoretical. Huntress’s SOC has caught all three techniques in real intrusions, including one chain that started with a stolen SSLVPN credential and ended with SYSTEM-level access on a fully-updated machine.

The three zero-days at a glance

NameCVEWhat it doesPatch statusFirst exploited
BlueHammerCVE-2026-33825Local privilege escalation via Defender’s file remediationPatched April 14 (CVSS 7.8)April 10
RedSunNone assignedSYSTEM access via Defender’s cloud-tagged file restoreUnpatchedApril 16-17
UnDefendNone assignedStandard user can block Defender signature updates or kill it during major updatesUnpatchedApril 16-17

Both unfixed bugs abuse the AV agent that ships on every Windows box, and both are running in real intrusions today.

How RedSun gets to SYSTEM

RedSun abuses Defender’s cloud-tagged file restore. When Defender sees a cloud-synced file it doesn’t trust, it will sometimes restore the original to its prior path. Chaotic Eclipse’s PoC uses NTFS junction points combined with batch opportunistic locks to redirect that restore. Instead of putting the file back where it came from, Defender writes it into C:\Windows\System32\.

Now drop a malicious DLL or executable named to match a real System32 binary, and the next time something loads it, you’re running as SYSTEM. The file write happens under Defender’s own credentials, which means the standard ACLs don’t matter.

The April Patch Tuesday update doesn’t close this. Defender is still doing the restore, the restore is still impersonating SYSTEM, and the junction-point trick still misdirects it. There’s no Defender setting that turns it off, either — the cloud file remediation behavior is core to how Defender works.

What UnDefend does

UnDefend is less dramatic but arguably worse. It lets a standard, unprivileged user silently disable Defender’s update mechanism. Once UnDefend runs, the AV stops getting fresh signatures. If Microsoft pushes a major Defender platform update during that window, UnDefend can also kill the engine entirely.

The exploit doesn’t need admin. It doesn’t trigger Defender’s tamper protection. And from the user’s perspective, nothing changes. The Defender icon still sits in the system tray, the Security Center still says “Your device is being protected,” signature updates just quietly fail.

Pair this with RedSun and you have a clean two-step intrusion: UnDefend to make sure no signature update can catch what comes next, RedSun to escalate. Huntress’s SOC has already seen exactly that chain.

The attack chain Huntress saw

The sequence from one of the incidents Huntress reported went like this:

  1. Initial access via stolen SSLVPN credentials (unrelated to Defender, likely credential stuffing or phishing).
  2. The intruder lands as a standard user, runs reconnaissance to map privileges and stored credentials.
  3. Drops UnDefend.exe and a renamed RedSun binary into the user’s Pictures and Downloads folders. Renaming is a cheap evasion trick: IOC hunters often only match exact filenames.
  4. UnDefend disables Defender signature updates so the next stage stays invisible to fresh detections.
  5. RedSun runs, abuses the junction-point trick, and overwrites a System32 binary. The intruder now has SYSTEM.
  6. Lateral movement and credential harvesting from there.

Huntress described it as “hands-on-keyboard threat actor activity”: a human at the other end of the session, picking the next move based on what they see. That’s a bigger problem than worm-like exploitation, because a human will adapt to whatever detection rule you write.

Why Microsoft only patched one

Microsoft has not publicly committed to an out-of-band patch for RedSun or UnDefend. The next regular Patch Tuesday is May 12, three weeks away. By the time you’re reading this, the exploits have been weaponized in production for somewhere between three days and three weeks.

There are two plausible reasons MSRC hasn’t shipped an emergency fix:

  • The fix is hard. RedSun in particular touches Defender’s core remediation flow. Changing how the AV restores files without breaking legitimate cloud-sync scenarios is the kind of thing that takes a real engineering cycle, not a hotfix. UnDefend likely needs Defender’s update channel itself rebuilt with stronger trust anchors.
  • The triage process is broken. The researcher’s whole grievance is that MSRC asked for video demos before triaging. If that’s still happening internally, even a known-exploited bug might not be prioritized fast enough to make an out-of-band release.

Neither reason helps you if your fleet is running Defender as the only AV layer right now.

What to do today

If you run a Windows fleet, this is the realistic mitigation list. Most of it is detection-side, because there’s no patch you can apply for the two unfixed bugs.

  • Apply the April 14 cumulative update everywhere. This closes BlueHammer (CVE-2026-33825). Don’t skip it because the other two are unpatched.
  • Hunt for the staged binaries: UnDefend.exe and RedSun.exe are the filenames the researcher’s PoCs ship with. Check Downloads, Pictures, and other low-privilege user folders. Also look for renamed variants — anything new and writable by a standard user that wasn’t there yesterday.
  • Baseline C:\Windows\System32\TieringEngineService.exe. This is the file RedSun’s PoC overwrites. Take its SHA-256 hash on a clean box and alert on any modification. If that hash changes on a non-update day, you have an active intrusion.
  • Watch for Defender signature update failures. UnDefend’s signal is the absence of new signatures. Most SIEMs already collect Defender event logs; alert on consecutive failed update events from the same machine.
  • Restrict NTFS junction point creation through group policy where you can. RedSun depends on the standard user being able to create junction points; locking that down breaks the exploit.
  • Audit SSLVPN access logs. Huntress’s observed intrusion started with a stolen VPN credential. Look for new IPs, unusual geographies, and concurrent sessions on the same account.
  • If you can, layer a second EDR. Anything that doesn’t rely on Defender’s signature pipeline gives you a fallback while UnDefend is unpatched. CrowdStrike, SentinelOne, Sophos: pick one and turn it on.

For developers building on Windows: don’t assume Defender is doing what it claims to be doing on user machines for the next few weeks. If you’re shipping software that lives or dies by AV trust signals, this is a good moment to add a second layer.

Why this one stings

Most Defender bugs get reported to MSRC, sit through coordinated disclosure, and ship in the next Patch Tuesday with nobody outside Redmond ever knowing. Compare that to the ActiveMQ Jolokia RCE CISA added to its Known Exploited Vulnerabilities catalog three days ago: 13 years old, coordinated, patched, then a CISA listing once attackers caught up. This Defender chain didn’t go that way. The breakdown was in MSRC’s triage process. The researcher says they were asked for a video demo before MSRC would triage, so they posted the PoC publicly.

Whether that’s a fair characterization of MSRC’s process is a debate for another day. But the result is two unpatched local-privilege-escalation bugs in the AV agent on every consumer and enterprise Windows machine, with active exploitation already in progress, three weeks from the next scheduled fix.

If you’re running an internal vuln management program, this is the conversation to have with your CISO this week: what does our exposure look like for the next 21 days, and what compensating controls do we turn on now.

FAQ

Are RedSun and UnDefend patched?

No. As of April 19, 2026, only BlueHammer (CVE-2026-33825) has a patch, shipped in the April 14 Patch Tuesday cumulative update. RedSun and UnDefend remain unpatched, and Microsoft hasn’t publicly committed to an out-of-band release. The next regular Patch Tuesday is May 12.

Which Windows versions are affected?

All three exploits work against Windows 10, Windows 11, and Windows Server 2019 and later, on systems where Microsoft Defender is enabled. Older Windows Server releases that don’t ship Defender by default aren’t directly affected.

Do the exploits need admin privileges to run?

No. Both RedSun and UnDefend run as a standard, unprivileged user. RedSun escalates to SYSTEM; UnDefend disables signature updates without ever asking for elevation. An attacker who lands as a normal user via phishing or stolen credentials can chain them to full control.

Who is the researcher behind these zero-days?

The researcher operates under the aliases “Chaotic Eclipse” and “Nightmare Eclipse” and hasn’t disclosed their real identity. Their stated reason for public release was that MSRC required video demonstrations of exploits before triaging the original report.

How do I detect if I’ve been hit?

Three signals to start with: (1) staged binaries named UnDefend.exe or RedSun.exe (or renamed copies) in user folders; (2) modifications to C:\Windows\System32\TieringEngineService.exe (RedSun’s overwrite target); (3) Defender signature update failures that don’t recover on retry. Any of those on an endpoint warrants immediate investigation.

Should I disable Defender as a workaround?

No. Disabling Defender opens you to every other piece of commodity malware in exchange for protection from a narrow PoC. Layer a second EDR on top instead, and apply the detections above.

Sources

Bottom line

Two unpatched local-privilege-escalation bugs in Defender, weaponized inside a week, with no out-of-band fix scheduled. If your detection-and-response stack assumes Defender is the bottom of the trust stack on Windows endpoints, that assumption is broken until further notice. Apply the April 14 patch, deploy the detections above, and don’t be the org that finds out about RedSun the hard way.