BlueHammer & RedSun: Windows Defender CVE-2026-33825 explained

On 3 April 2026, a researcher operating under the alias Chaotic Eclipse published a working proof-of-concept for a local privilege escalation in Microsoft Defender. The exploit was dubbed BlueHammer. Eleven days later, in the April 2026 Patch Tuesday batch, Microsoft shipped a fix and assigned the flaw CVE-2026-33825. In the days between, a shorter variant nicknamed RedSun surfaced, abusing a different Defender code path to achieve the same SYSTEM-level outcome.

We did not discover this vulnerability. The technical research belongs to Chaotic Eclipse, and the most readable writeup of the exploit chain is Picus Security's piece from 16 April. What we can add is what Dutch SOC and endpoint teams should actually do about it this week, in the order that matters.

What actually happens in BlueHammer

Defender's real-time protection engine (MsMpEng.exe) runs as a protected SYSTEM service. When it flags a malicious file, it quarantines or deletes it. That is a file operation performed with SYSTEM privileges. The catch is how it validates the path between the check ("is this still the file I intended to act on?") and the use("write the new content there").

BlueHammer wins the race between those two moments. The exploit works roughly as follows:

1. Drop a file that is guaranteed to trigger Defender. The researcher used an EICAR-shaped lure under an attacker-controlled directory the exploit owns.
2. Place a batch opportunistic lock (oplock)on that file. When Defender opens it for remediation, the kernel suspends Defender's I/O at the exact instruction boundary the exploit needs.
3. While Defender is frozen mid-remediation, swap the attacker-owned directory for an NTFS junction point pointing at C:\Windows\System32. Release the oplock.
4. Defender resumes, follows the junction, and writes the quarantine/rollback output to the redirected path, with SYSTEM rights. The victim is a system binary or a scheduled-task DLL the attacker has chosen to overwrite.
5. The next time that binary executes (service start, logon task, update hook), the attacker's payload runs as SYSTEM.

The variant reported alongside BlueHammer, RedSun, chains the same oplock+junction primitive, but against Defender's cloud file rollback path (the Windows Cloud Files API / OneDrive placeholder logic) instead of local quarantine. The outcome is identical: Defender writes into System32 under SYSTEM. What it matters for: depending on how a given Defender build was patched, one primitive may be closed while the other is not.

How worried should a Dutch SOC actually be?

Honest framing, because the Dutch infosec press likes to flatten everything into "new zero-day, patch now":

• It is a local privilege escalation. The attacker needs code execution on the box first. If you are already running a malicious binary on the endpoint, you have a bigger problem than CVE-2026-33825.
• But local is exactly where the modern intrusion lives. Phishing delivers an unprivileged foothold; BlueHammer promotes it to SYSTEM without dropping a second payload that EDR would see. That is the playbook for the next ransomware wave targeting Dutch MKB and uitvoerings­ organisaties.
• Microsoft reports no in-the-wild exploitation at patch time. That window is closing. Public PoCs get weaponised; the RH-ISAC release from 3 April is already drop-in ready.
• Defender is default-on across Dutch endpoint estates: municipalities, zorg, MKB on Microsoft 365 Business Premium. The attack surface is effectively every Windows workstation you have.

What your team should do this week

In priority order, not alphabetical order.

The bigger pattern

Picus, the Zero Day Initiative and CrowdStrike all flag the same thing: BlueHammer is not an isolated bug. In a 13-day window across early April 2026, three separate techniques against Defender surfaced: BlueHammer (privilege escalation via quarantine), UnDefend (gradual protection degradation via the update mechanism), and RedSun (privilege escalation via cloud rollback). The common factor is Defender itself: a privileged, always-on process that has to touch every file the user touches. That architecture creates a systemic TOCTOU surface that patches can close only one path at a time.

Practically, this means: the April 2026 platform update is necessary but not sufficient. If your detection content only looks for CVE-2026-33825 by name, you will miss the next variant.

Detect the behaviour, not the CVE. Three signals together give away the whole class of bugs, even the ones that are still nameless:

• Writes into protected paths (System32, Program Files, driver stores) initiated by MsMpEng.exe or another privileged Defender component. Defender has no business writing there under normal operation, so every single event is worth triaging, not sampling.
• Reparse-point or NTFS junction creation from non-admin processes that targets System32 or a similarly sensitive directory. That is the setup step for every TOCTOU variant against the remediation mechanism, regardless of which code path the attacker eventually abuses downstream.
• Modifications to service executables or scheduled-task DLLs outside a known patching or install window. That is the payload step: the file that is about to execute SYSTEM code the next time the service starts or the task runs.

Detect those three and you get coverage for variant five before it has a name.

What we're doing for clients

Nothing dramatic, and that is the point. We did not find this bug; Chaotic Eclipse did. What we did do is reproduce the public PoC in our lab so we could write detection content against real behaviour rather than the advisory. What that yields this week for our Managed SOC and IR clients:

• Sigma and Sentinel detections for the behavioural outcomes listed above, tested on a lab image running the public PoC and then shipped to client tenants.
• A compliance diff: for each client estate, which endpoints have the April 2026 Defender platform build and which do not, handed over as a sortable list rather than a dashboard.
• A short pentest validation (for IR-retainer clients): we drop the public PoC on a representative endpoint in a controlled window and confirm the detection fires before it is blocked. If it doesn't, we revise.

None of that is novel. It is the job. The value is that it actually gets done on a predictable cadence, with someone accountable for the outcome, before the next variant.