RedSun and UnDefend: A Technical Walkthrough of Two Exploited Defender Vulnerabilities and Their Fixes

What Microsoft and CISA said about RedSun and UnDefend

Microsoft and CISA treated RedSun and UnDefend as urgent because both Defender flaws were reported as actively exploited in the wild. That matters more than the CVE labels themselves: once a bug is in live use, patch timing stops being theoretical.

Both issues were fixed with emergency out-of-band updates, which tells you two things right away:

1. the vulnerable code path sits close to a security boundary, and
2. the normal monthly cadence was not fast enough for the attack window they were seeing.

Why Defender bugs matter more than ordinary application bugs

A browser bug can expose a session. A Defender bug can expose the machine that is supposed to protect every session on it.

That is why RedSun and UnDefend matter beyond the Windows security team. Defender sits in the endpoint control plane: scanning, quarantine, telemetry, policy enforcement, and often incident response hooks. If an attacker can abuse that surface, they may not need a separate payload first. They can pivot through the product you already trust.

The practical impact is higher than a typical app flaw:

• payloads may run with elevated trust relative to userland software
• tampering can suppress detection or delay response
• exploit chains can move from one host to adjacent systems faster than a normal ransomware entry point

What RedSun and UnDefend appear to have in common

Actively exploited in the wild

The biggest commonality is simple: these were not lab-only bugs. The reporting tied both vulnerabilities to live intrusions, which usually means the exploit path was stable enough for operational use.

That should change how you triage them. If a Defender exploit is already in an intrusion set, you should assume attackers have moved from “can be exploited” to “has been weaponized.”

Why out-of-band patching matters here

Out-of-band patches are a signal that waiting for the next planned update cycle is not acceptable. In practice, they also create deployment friction:

• systems with delayed update rings may miss the fix for days
• offline or semi-managed endpoints can stay exposed
• EDR baselines may not notice the Defender component changed beneath them

That means patch verification matters as much as patch application.

Impact on real Windows environments

Enterprise exposure and lateral movement risk

On a managed Windows fleet, the first-order risk is endpoint takeover. The second-order risk is lateral movement.

If an attacker can weaken Defender on one box, they can often use that host to:

• stage credential theft tools with fewer alerts
• tamper with scheduled tasks or services
• reduce the chance that post-exploitation artifacts are quarantined
• use the host as a cleaner launch point for internal recon

This is especially ugly in environments where Defender is also the primary telemetry source for SOC triage.

Detection and response blind spots

There is a nasty operational side effect here: the product under attack may also be the product generating your alerts.

So I would look for two failures:

• missing telemetry because the agent was disrupted
• misleading “all clear” signals because tampering changed local behavior before central logging caught up

If your detection logic depends on Defender events alone, you need a second source of truth.

How to verify whether you are affected

Inventory Defender versions and update channels

Start with inventory. You need to know which Defender engine and platform versions are actually running, not just which Windows release is installed.

Useful checks:

Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusEnabled, AntispywareEnabled, AntivirusSignatureVersion, NISEngineVersion

Get-CimInstance Win32_QuickFixEngineering | Sort-Object InstalledOn -Descending | Select-Object -First 20

Compare the installed Defender platform versions against Microsoft’s fixed builds and your update channel. If you have multiple rings, confirm the emergency fix reached all of them.

Check for emergency patch deployment gaps

I usually look for the boring failures first:

• laptops outside VPN during rollout
• servers with update deferrals
• images cloned before the patch
• devices excluded from normal management for “stability” reasons

The gap is often not the patch itself. It is the subset of hosts that never saw it.

Look for suspicious child processes, service changes, and Defender tampering

You want evidence of misuse, not just patch status. Review for:

• unexpected child processes spawned by Defender-related services
• service configuration changes
• disablement of realtime protection
• exclusions added shortly before suspicious activity
• failed attempts to stop or reconfigure security services

Example hunting query ideas:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 200 |
  Where-Object { $_.Id -in 5001, 5007, 5010, 5012 } |
  Select-Object TimeCreated, Id, Message

Practical defense steps for patching and monitoring

Prioritize patch rollout by exposure and asset value

Do not patch everything in the same order. Start with:

1. internet-facing endpoints
2. admin workstations
3. servers with high privilege or high connectivity
4. laptops used off-network
5. everything else

If you have to choose, protect the systems that can unlock the most internal access.

Harden endpoint visibility and alerting

Add alerts that do not depend on Defender alone:

• service stop or restart events
• new exclusions or policy drift
• unexpected Defender-related process trees
• unsigned binaries launched after security-tool tampering
• gap detection for devices missing the emergency build

Validate recovery and rollback procedures

Security tooling breaks in a different way than ordinary software. Before you need it, test:

• how quickly you can redeploy Defender components
• whether tamper protection survives your remediation path
• whether offline repair media includes the fixed package
• how you roll back a bad update without reintroducing exposure

A patch that cannot be safely deployed is not really a fix in production.

What this incident says about security tools as attack surfaces

The uncomfortable lesson is that defensive software is not inherently safer than business software. It is just more valuable to attackers.

When a product like Defender has a locally exploitable flaw, the payoff is disproportionate. You are not just getting code execution or a crash. You are potentially disturbing the system that is supposed to catch the next attack.

That changes how I review endpoint controls:

• assume protection software is part of the threat model
• track its versioning with the same discipline as browsers and runtimes
• watch for tampering as a primary signal, not a secondary one
• treat emergency security patches as operational incidents, not maintenance

Conclusion

RedSun and UnDefend are a good reminder that security tools are high-value targets. The response is straightforward but not optional: confirm you have the out-of-band fix, verify every update ring, and hunt for signs that Defender was tampered with before the patch landed.

If your environment is large, the real risk is not just the vulnerabilities. It is the gap between “Microsoft shipped a fix” and “every host that matters actually got it.”