When Your Defender Becomes the Attacker: How Trusted Windows Processes Get Weaponized

In April 2026, a security researcher published working exploit code that uses Windows Defender itself to overwrite critical system files — granting full administrative control over any patched Windows 10 or 11 machine. The tool you rely on to protect your computer became the weapon.

This wasn’t a one-off accident. It’s part of a trend years in the making.

TL;DR

Windows Defender and other trusted system processes run with the highest possible privileges — making them valuable targets

A researcher published two working exploits (BlueHammer, RedSun) that weaponize Defender’s own file-handling behavior to gain SYSTEM access

Security software (AV/EDR) has historically been one of the most exploited categories of software on Windows

Attackers love trusted processes because they’re whitelisted, rarely monitored, and extremely powerful

Defenders need to monitor what trusted processes do, not just whether they run

Why This Should Concern Everyone

You don’t need to be a cybersecurity professional for this to matter. If you run Windows at home or at work, Windows Defender is almost certainly active on your machine right now. It runs silently in the background with SYSTEM-level privileges — the highest access level on the operating system, above even a local administrator account.

When a piece of software that powerful has a flaw in how it handles files, any regular user on that computer can potentially leverage that flaw to take complete control of the system. No password theft needed. No phishing email required. Just running a small program.

That’s exactly what the recent RedSun and BlueHammer exploits demonstrated.

The Paradox of High-Privilege Security Software

To understand why this problem keeps happening, you need to understand a fundamental tension in how security software works.

Antivirus programs and EDR (Endpoint Detection and Response) tools — software that monitors your computer for threats in real time — need deep access to do their job. They have to:

Read and write files anywhere on the system
Intercept processes before they execute
Monitor network connections
Modify kernel-level behavior

This deep access requires SYSTEM privileges, which is Windows’ way of saying “this process can do anything.” There’s no meaningful restriction. A SYSTEM-level process can overwrite the Windows kernel, delete any file, or create new administrator accounts silently.

The problem is obvious in hindsight: when you build a piece of software with that much power, any bug in that software becomes extremely dangerous. A vulnerability in your text editor lets an attacker read your documents. A vulnerability in your antivirus lets an attacker own your entire machine.

Security software is, by design, one of the most dangerous categories of software to have bugs in.

Case Study: BlueHammer and RedSun

In early April 2026, a researcher operating under the alias “Chaotic Eclipse” published two back-to-back exploits targeting Windows Defender. Both were described as Local Privilege Escalation (LPE) vulnerabilities — meaning a regular, unprivileged user could run them to gain SYSTEM access.

BlueHammer (CVE-2026-33825)

Published on April 3rd with no prior warning to Microsoft. The researcher included a pointed message: “I was not bluffing Microsoft, and I’m doing it again.”

Microsoft patched BlueHammer in the April 2026 Patch Tuesday security update. However, according to the researcher, the fix was incomplete — it addressed the symptom but not the root cause of the vulnerability.

RedSun

Published on April 15th, just days after the BlueHammer patch. This one remained unpatched as of its release. The exploit worked with near-100% reliability against fully updated Windows 10, Windows 11, and Windows Server systems.

How RedSun works (simplified):

Windows Defender has a feature where, if it detects a suspicious file, it can “restore” the file — rewriting it to its original location. RedSun abuses this restoration behavior:

The attacker creates a bait file using a Windows cloud storage API, tagging it in a way that triggers Defender’s restoration mechanism
An opportunistic lock (oplock) — a legitimate Windows file-locking feature — pauses Defender’s file write operation mid-way
While Defender is paused, the attacker redirects the write destination using NTFS directory junctions (essentially Windows symbolic links) to point at C:\Windows\System32
When Defender resumes, it faithfully writes the file to the redirected location — overwriting a critical system binary with SYSTEM-level privileges
The attacker’s payload is now in System32. Privilege escalation complete.

Think of it like this: you ask a trusted postal worker to deliver a package to your house. Halfway through the delivery, you secretly change the address on the package to your neighbor’s house. The postal worker, trusting the address label, delivers it there instead — without realizing anything changed.

Defender trusted itself to finish the job. The attacker just changed the destination.

This Isn’t New — Security Software Has Always Been a Target

The RedSun and BlueHammer exploits are dramatic, but they’re part of a long-established pattern. Security software has been a high-value target for attackers for over a decade.

Year	Product	Issue
2016	Symantec/Norton	Remote code execution via malformed archive scanning — no user interaction needed
2019	Trend Micro	Local privilege escalation via insecure service permissions
2021	Bitdefender	Privilege escalation via race condition in file quarantine
2022	ESET	Arbitrary file deletion as SYSTEM via antivirus engine
2023	CrowdStrike Falcon	Agent process suspension logic flaw
2024	SentinelOne	”Bring Your Own Installer” bypass — uninstall agent by timing the updater
2026	Windows Defender	BlueHammer + RedSun LPE chain

The pattern is consistent: the scanning engine, the file quarantine system, the update mechanism, or the restore feature — all trusted, all powerful, all exploitable when implemented with subtle bugs.

Google’s Project Zero team has noted that security products routinely process complex, attacker-controlled input (files, network traffic, memory contents) with SYSTEM privileges and minimal sandboxing. That’s a recipe for high-impact vulnerabilities.

The Broader Pattern: Trusted Processes as Weapons

RedSun and BlueHammer represent one category of a broader attack class: Trusted Process Abuse. The core idea is simple — instead of writing your own malicious code, make the operating system or a trusted application do the dangerous work for you.

This works because:

Trusted processes are whitelisted. Security tools typically don’t flag activity from Windows Defender, Windows Update, or Task Scheduler — even when that activity would look suspicious coming from an unknown process.
Trusted processes are powerful. SYSTEM-level processes bypass most access controls.
Trusted processes are expected. An alert about MsMpEng.exe (Defender’s engine) writing to System32 looks routine. An alert about evil.exe doing the same thing would immediately trigger alarms.

Other well-known examples of this technique:

LOLBins (Living Off the Land Binaries) — using legitimate Windows tools like certutil.exe, mshta.exe, or regsvr32.exe to download and execute malicious payloads. These tools are signed by Microsoft and trusted by most security products.
Windows Update abuse — using the update service’s SYSTEM-level write permissions to plant files in protected directories.
Task Scheduler persistence — creating scheduled tasks that run under SYSTEM to maintain access without touching the registry in obvious ways.
BYOVD (Bring Your Own Vulnerable Driver) — loading a signed but vulnerable kernel driver to kill EDR processes from inside the kernel, where antivirus has no visibility.

The common thread: use what Windows already trusts.

Why Microsoft Keeps Getting Here

It’s worth asking: why does the world’s most valuable company keep shipping software with these kinds of flaws?

The answer is complexity. Windows has to maintain compatibility with software written decades ago. The APIs that RedSun abuses — opportunistic locks, NTFS junctions, cloud file tags — all exist for legitimate reasons and have been part of Windows for years. Building secure systems on top of these primitives requires extreme care about race conditions, timing, and file path resolution.

Security researchers have noted that Microsoft’s Security Response Center (MSRC) is slow to acknowledge these classes of bugs, and often patches the specific exploit rather than the underlying pattern. The researcher behind BlueHammer and RedSun was explicit about this frustration — the BlueHammer patch addressed that specific vulnerability but left the architectural weakness intact, enabling RedSun.

This isn’t unique to Microsoft. But given Windows’ market share — over 70% of desktop operating systems globally — the impact of each unpatched Defender flaw is enormous.

What You Can Do Today

For Home Users

Keep Windows Update enabled and apply patches immediately. BlueHammer was patched in April 2026 Patch Tuesday. The faster you apply updates, the shorter your exposure window.

Know your attack surface. LPE vulnerabilities like RedSun require the attacker to already have a foothold on your machine — typically via phishing, a malicious download, or a browser exploit. Strong browser hygiene and not running untrusted software dramatically reduces risk.

Monitor Microsoft Security Advisories at msrc.microsoft.com for unpatched zero-days. When a PoC exploit is public and unpatched, awareness is your first line of defense.

For Security Teams and Sysadmins

Apply mitigations for unpatched zero-days. For RedSun specifically, Microsoft has not issued a patch. Consider temporary mitigations:

Monitor MsMpEng.exe write activity to System32 via EDR behavioral rules
Audit Windows Cloud Files API usage (cldapi.dll) for unusual patterns
Alert on unexpected NTFS junction creation in user-writable directories

Don’t assume your EDR is invisible to attackers. Review whether your EDR product has known vulnerabilities, and treat EDR agents as part of your attack surface. Subscribe to vendor security bulletins.

Implement Privileged Access Workstations (PAW) for sensitive administration tasks. Reducing where SYSTEM-level processes run limits blast radius.

Hunt for LOLBin abuse. Query your SIEM for certutil, mshta, wscript, and similar binaries downloading content or spawning unexpected child processes. These are strong indicators of trusted process abuse.

Patch aggressively. The gap between a public PoC and active exploitation in the wild is measured in hours, not days. For BlueHammer, exploitation was confirmed within days of the PoC release.

The Uncomfortable Truth

Security software running with SYSTEM privileges is a necessary evil. You can’t protect a system without deep access to it. But “deep access” means “catastrophic when wrong.”

The industry has been slow to apply the same security rigor to security products that it demands of everything else. Sandboxed scanning engines, reduced-privilege architectures, and formal verification of file-handling code are all technically feasible — they’re just expensive and slow.

Until that changes, attackers will keep finding Defenders that defend everything except themselves.

BYOVD: Bring Your Own Vulnerable Driver Attacks — how attackers use signed drivers to kill EDR from the kernel
LOLBins: Living Off the Land on Windows — using built-in Windows tools to evade detection
AV vs EDR vs XDR: What’s the Difference? — understanding the security tooling landscape
Modern Attack Techniques 2026 — broader Windows attack technique overview