BlueHammer, RedSun, UnDefend: The Defender Zero-Day Cluster SMB Hardening Guide

On April 3, 2026, an anonymous researcher operating as Chaotic Eclipse / Nightmare Eclipse dropped a working Microsoft Defender LPE exploit on GitHub, after stating that an earlier disclosure to MSRC went nowhere. They named it BlueHammer. On April 14, Microsoft shipped a patch in the Patch Tuesday cycle and assigned CVE-2026-33825, credited to Zen Dodd and Yuanpei Xu — parallel discovery, not the same researcher. On April 16, the same anonymous researcher dropped two more Defender zero-days into the repo: RedSun, a separate LPE through a different code path, and UnDefend, which lets a standard user block Defender signature updates or disable it outright. Help Net Security broke that disclosure.

As of writing, RedSun and UnDefend remain unpatched. Huntress observed all three in real-world intrusions: BlueHammer blocked on April 10, RedSun and UnDefend observed in the wild on April 16. The Belgian CCB’s April advisory notes that CVE-2026-33825 was used as part of a chained attempt to deploy BeigeBurrow, a tunneling or proxy agent. CISA added CVE-2026-33825 to its Known Exploited Vulnerabilities Catalog on April 22 with a federal remediation deadline of May 6, which has now passed.

For SMBs this is the awkward kind of incident: the only one with a CVE is patched, the other two are not, and Defender — frequently the only endpoint protection on the host — is the target. Patching Windows is necessary but not sufficient. This piece walks through what each exploit does, why patching closes only a third of the door, and the durable hardening and detection posture every Defender-protected fleet should be running this week.

What the three exploits actually do

All three abuse Defender from the inside. The point for posture: Defender runs as SYSTEM and handles user-supplied content during real-time scanning and remediation, so any flaw in how it touches the filesystem is by construction a SYSTEM-context flaw.

BlueHammer (CVE-2026-33825) exploits a TOCTOU race in Defender’s remediation logic. Picus Security details the chain: a low-privileged user drops a file Defender will detect, then uses a batch opportunistic lock to pause Defender mid-remediation. While Defender is frozen, the attacker swaps the path with an NTFS junction pointing at C:\Windows\System32. When the oplock releases, Defender resumes its write under SYSTEM and overwrites a legitimate system binary with attacker content. Executing that binary lands SYSTEM.

RedSun is a separate LPE through Defender’s cloud-file rollback path. When Defender detects a file tagged as a cloud placeholder via the Windows Cloud Files API, it tries to restore the file to its original location without validating the target path. The exploit triggers detection, replaces the file with a cloud placeholder, and uses NTFS junctions plus oplocks to redirect the restore target to System32. Same outcome as BlueHammer (SYSTEM via overwritten binary), different code path. Microsoft has not shipped a fix.

UnDefend does not escalate privileges — it weakens the control plane. A standard user can use it to block Defender’s signature update channel or push Defender into a degraded state if Microsoft happens to be shipping a major Defender update at the time. It is the slow, quiet companion to the loud LPE bugs: if you can land on a host with a standard-user foothold, UnDefend keeps Defender from getting smarter about you while you stage the rest of the attack.

Two operational notes hide in the public PoC. First, ProArch highlights that exploit binaries were staged from user-writable directories — Downloads, Pictures, Temp — consistent with an attacker who already has a phishing foothold and is using these chains to move from user to SYSTEM. Second, the BlueHammer PoC ships with a credential-dump pathway already wired: SAM is uncommented, SYSTEM and SECURITY commented out. A careful read of the code points out that uncommenting two lines turns it from “SYSTEM on this host” into a full LSA-secret, DPAPI-master-key, cached-domain-credential extraction. Hours of work, not weeks.

Why patching alone is not the answer

If you only walk away with one thing from this incident: applying KB updates from the April 2026 cumulative is necessary, and it is not enough. Three reasons.

First, RedSun and UnDefend remain unpatched. Microsoft has not, as of writing, shipped fixes for either, and there is no public schedule. Any host with a standard user that can execute code in a writable directory is exposed to a SYSTEM escalation via RedSun and to a quiet Defender-degradation via UnDefend. Hosts that you patched on April 14 are still exposed.

Second, the BlueHammer pattern generalizes. A TOCTOU race in a SYSTEM-context scanner is not a one-off — this is the third public Defender LPE chain in 18 months that uses oplocks plus junctions. Treating the EDR as an attack surface, not just a defense, is the durable shift. Vulnerability analyst Will Dormann confirmed the RedSun PoC works as advertised, and the same researcher could quietly release a fourth bug tomorrow.

Third, exploitation is already opportunistic. Huntress flagged all three in real intrusions within 13 days of the first PoC, and the CCB advisory confirms BlueHammer used in a chained attempt to drop BeigeBurrow tunneling. Researcher curiosity is now commodity attack chain.

The SMB hardening playbook

Step 1: Confirm the April cumulative is actually installed

Confirm, do not assume. The KB number you are looking for varies by OS build, but every supported Windows version has an April 14, 2026 or later cumulative update that resolves CVE-2026-33825. Quick checks across the fleet:

# Per-host, verify cumulative installed after April 14 2026
Get-HotFix | Where-Object {$_.InstalledOn -ge (Get-Date "2026-04-14")} `
  | Select-Object HotFixID, Description, InstalledOn

# Defender engine + platform version (target April 2026 release or newer)
Get-MpComputerStatus | Select-Object AMEngineVersion, AMProductVersion, `
  AntispywareSignatureVersion, AntivirusSignatureVersion, `
  AntivirusSignatureLastUpdated

# Fleet-wide via Intune Endpoint Analytics or your RMM:
# query devices where AVSignatureLastUpdated < (today - 3 days)
# or AntivirusEnabled = $false

Hosts that have not received signature updates in three or more days are the first sign of UnDefend-style tampering, EDR disablement, or simple connectivity loss. All three deserve a ticket.

Step 2: Turn on Tamper Protection and enforce it from the cloud

UnDefend works because Defender’s configuration and update path can be disrupted from a local-user context. Tamper Protection, when enforced from Intune or Defender for Endpoint, blocks the most common local techniques for disabling or weakening Defender. Most SMB tenants have it available; many have it off, set to user-controlled, or never enforced at the policy level.

In the Microsoft Defender portal, enforce Tamper Protection at the tenant level. Then enable the recently shipped Defender Secure Score recommendations called out in the April 2026 monthly news: Block outbound network connections from mshta.exe and Block file transfer over RDP. Neither directly mitigates BlueHammer, but both close standard staging paths that the same attacker class uses before and after the LPE.

For unmanaged or RMM-managed fleets, the equivalent settings live under HKLM\SOFTWARE\Microsoft\Windows Defender\Features\TamperProtection and the matching MDM policy CSPs. End state: Tamper Protection on, enforced from the cloud, immune to local administrator override.

Step 3: Add ASR rules that break the exploitation pattern

Attack Surface Reduction rules are the cheapest control with the highest payoff for this class of attack. The exploitation chain depends on writing payloads to user-writable directories, then using legitimate-looking processes to interact with them. Two ASR rules that fit:

• Block executable content from email client and webmail — reduces the volume of initial-access payloads that land in Downloads in the first place.
• Block credential stealing from the Windows local security authority subsystem (lsass.exe) — not a BlueHammer block per se, but cuts the post-SYSTEM credential-dump step the PoC is two commented lines away from executing.
• Block process creations originating from PSExec and WMI commands — closes a common lateral-movement step after SYSTEM is obtained on one host.

Roll them out in Audit mode first for a week, review events in the Defender portal, then promote to Block. “Just turn it on” produces enough false positives to get the rules disabled entirely; audit-then-promote is the only sustainable path.

Step 4: Detection rules for the specific exploit pattern

If you have Microsoft Defender for Endpoint or another tool that can query Windows event telemetry, two detection patterns catch what the PoCs do. Sample KQL for the Defender advanced hunting query:

// 1. New executable written to System32 with non-Microsoft signature,
// shortly after a Defender remediation event on the same host.
DeviceFileEvents
| where FolderPath startswith @"C:\Windows\System32\"
| where ActionType == "FileCreated" or ActionType == "FileModified"
| where InitiatingProcessFileName !in~ ("MsMpEng.exe", "TrustedInstaller.exe",
    "msiexec.exe", "wuauclt.exe")
| where Signer !startswith "Microsoft"
| join kind=inner (
    DeviceEvents
    | where ActionType has "AntivirusDetection"
    | project remediationTime = Timestamp, DeviceId
  ) on DeviceId
| where Timestamp between (remediationTime .. remediationTime + 5m)

// 2. Suspicious junction creation under user-writable paths followed by
// Defender process activity on the same target path within seconds.
DeviceFileEvents
| where ActionType == "FileCreated"
| where FolderPath has_any (@"\Users\", @"\Temp\", @"\Downloads\", @"\AppData\")
| where FileName endswith ".lnk" or FileName has "junction"
| project Timestamp, DeviceId, FolderPath, FileName, InitiatingProcessFileName

For shops without Defender for Endpoint, the same logic runs against Sysmon Event ID 11 (FileCreate) and Event ID 1 (ProcessCreate) joined on time and target path; the SwiftOnSecurity Sysmon configuration is a sane starting point. Forward both event sources to your SIEM and alert on the joined pattern.

Step 5: Plan for the “Defender is degraded” signal as a real alert

UnDefend’s value to an attacker is silent degradation. The control that catches it is not a vendor signature — it is your own monitoring of Defender health. Build a fleet-wide alert on:

• Defender signature age greater than 72 hours on any host that is online.
• Get-MpComputerStatus.AntivirusEnabled returning false on any managed endpoint.
• Defender engine version stuck at a pre-April 2026 build on hosts that should auto-update.
• Any change to Tamper Protection state from the management plane.

Treat each of those as a P3 incident worth a same-day human look. Defender being out of date on a single laptop is normally noise; in the context of an active UnDefend campaign it is a triage signal.

The bigger pattern

The Defender cluster sits next to two other patterns we have covered this week. The PAN-OS CVE-2026-0300 story was about a network edge defense that had no patch yet. The Adaptavist breach was about a SaaS partner whose infrastructure was the attack path into your tenant. BlueHammer + RedSun + UnDefend is the endpoint version of the same thing: the tool that is supposed to protect you is also, by virtue of running everywhere with SYSTEM privileges, the most valuable target on the host.

The durable answer is the same in all three places: defense in depth, monitoring of the defenders themselves, and never trusting that a single control is enough because the vendor said so. Patching the one bug that got a CVE is the table-stakes move. Hardening Defender, instrumenting tamper detection, and instrumenting your own visibility into what Defender is and is not doing is what closes the gap RedSun and UnDefend will keep open until Microsoft ships the next round of fixes.

Footnote: the credential-dump comment in the BlueHammer PoC is worth thinking about as a discipline marker, not as a defensive control. Two commented lines is the difference between a SYSTEM exploit and a complete identity compromise on a domain-joined host. Plan response accordingly: if you find a successful BlueHammer or RedSun exploitation in your environment, treat domain credentials, DPAPI-protected secrets, and any cached service-account material on that host as already exfiltrated.