RoguePlanet: The Fourth Defender Zero-Day, and Why the Patch Is Not the End of It

Three months ago I wrote up BlueHammer while it was still an unpatched, leaked proof of concept and Microsoft had not shipped a fix. RoguePlanet is the fourth Defender local privilege escalation from the same researcher, and this time the story is inverted: it already has a CVE, it already has a patch, and for most of you it already deployed itself without anyone lifting a finger.

That last part is exactly why it is worth a post. When the fix arrives silently through the antimalware engine channel rather than as a KB in your patch ring, “we patched it” becomes an assumption instead of a fact. This piece is about turning that assumption back into a fact, and about hunting for the window between disclosure and engine rollout when your fleet was exposed.

Two things up front, same as last time. First, I have not run the exploit. Everything below is derived from the CVE-2026-50656 advisory, the public reporting, and the published descriptions of the proof of concept. Microsoft deliberately withheld the mechanical detail, and I am not going to reconstruct it here. Second, the detection queries are hypotheses built from the vulnerability class and the one behavioral signal that reporting agrees on. They are starting points for your own hunt, not validated production analytics. The schema notes at the end tell you which columns I trust and which I do not.

TL;DR

• Class: Local privilege escalation. TOCTOU race plus improper link resolution (CWE-59) in the Microsoft Malware Protection Engine, the scanning core shared by Defender Antivirus, Security Essentials, and System Center Endpoint Protection.
• Exploit primitive: A standard user triggers the engine’s privileged scan path, then swaps the target during the check-to-use window using an NTFS junction, symbolic link, or reparse point. The SYSTEM engine follows the redirect. Oplock timing widens the race.
• Impact: SYSTEM on fully patched Windows 10 and 11. An interactive shell inheriting SYSTEM was demonstrated.
• Real-time protection is irrelevant. The published PoC works whether Defender RTP is on or off, and signature-based blocking is largely ineffective against PoC variants because the abused component is the scanner itself.
• Prerequisites: Local code execution as an unprivileged user. The ability to create links or reparse points in a path the engine will traverse.
• Patch status: Fixed in Malware Protection Engine 1.1.26060.3008. Anything at or below 1.1.26050.11 is vulnerable. Shipped as an out-of-band engine update in early July 2026, plus defense-in-depth hardening.
• Exploitation: Rated “Exploitation More Likely” by Microsoft, but not observed in the wild and not on the CISA KEV list. A public PoC exists; that is the risk driver.
• Do this today: Confirm AMEngineVersion is at least 1.1.26060.3008 across the fleet, then hunt the exposure window. Details below.
• CVSS: 7.8 (CVSS 4.0), High.

Timeline

For context, this is the fourth in the sequence the same researcher has run through Microsoft’s disclosure process: BlueHammer, UnDefend, RedSun, and now RoguePlanet. In prose the researcher goes by Chaotic Eclipse; several outlets refer to the same person by the Nightmare-Eclipse handle used on the published repositories, so if you are cross-reading coverage, those are one and the same.

What Makes RoguePlanet Different From BlueHammer

Three things, and they change what you actually do about it.

It is patched, and the patch is invisible to your normal process. The Malware Protection Engine auto-updates out of band from Windows Update. On a connected, default-configuration fleet, 1.1.26060.3008 rolled itself out within a day or two of release, and you were never asked. That is the good news and the trap in the same sentence. The engine does not auto-update everywhere: air-gapped and isolated networks, environments that pin the engine version for change-control reasons, systems where the update channel is broken or blocked, and long-dormant machines that boot up weeks later all sit on the old engine until something intervenes. Those are precisely the environments where “Defender keeps itself current” is assumed rather than verified. Your job is to find them.

Turning Defender off does not help, and neither does turning it on. The PoC runs with real-time protection in either state, because the vulnerability lives in the engine’s file resolution, not in real-time scanning behavior you can toggle. This kills the two reflexes people reach for. You cannot mitigate by disabling Defender, and you gain nothing by confirming RTP is enabled. The only real controls are the engine version and the filesystem primitives the exploit needs.

Signatures will not catch it. The abused code is the thing that runs the signatures. Reporting is explicit that signature-based attempts against PoC variations are largely ineffective. This is a behavioral hunt or nothing.

What the Chain Does

I am keeping this deliberately high level, because the advisory withholds the mechanics on purpose and reconstructing them adds nothing for a defender.

The engine, running as SYSTEM, resolves and opens files while it scans. RoguePlanet is a classic time-of-check-to-time-of-use problem against that resolution: an unprivileged attacker who can influence a path the engine will touch swaps it, between the moment the engine validates the path and the moment it opens the file, for a link or reparse point pointing somewhere the attacker could not reach on their own. The privileged engine follows the redirect and performs a file operation as SYSTEM that the attacker chose. From there the published PoC reaches an interactive SYSTEM shell.

This is the same failure family as BlueHammer, which was TOCTOU plus path confusion against the signature update path. Different code path, same lesson: the most privileged process on the endpoint is the one whose job is to inspect attacker-controlled files, and link resolution is where that privilege leaks.

MITRE ATT&CK Mapping

• T1068 Exploitation for Privilege Escalation. The core of the issue.
• T1574 Hijack Execution Flow. The link and reparse-point swap that redirects the privileged file operation.
• T1211 Exploitation for Defense Evasion, as framing rather than a literal technique. The abused component is the security product, so success both elevates and undermines the control you would otherwise detect with.

Post-exploitation depends on what the operator does with SYSTEM and is not specific to this bug. Map that half to whatever they actually run.

Detection

Ordered by signal quality. The first anchor is the clean one and the only query here I would consider promoting toward a custom detection after tuning. The rest are hunts.

Anchor A: MsMpEng.exe Spawning an Interpreter at SYSTEM Integrity

This is the load-bearing signal. MsMpEng.exe runs as SYSTEM, but it does not launch interactive shells or scripting hosts as part of normal operation. A child process of the Defender engine that is a command interpreter, running at System integrity, is the observable tail of the published PoC and has almost no benign explanation.

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "MsMpEng.exe"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe",
    "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe"
  )
| where ProcessIntegrityLevel == "System"
| project Timestamp, DeviceName, FileName, ProcessIntegrityLevel,
          ProcessCommandLine, AccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine

If this returns rows, treat the host as compromised until proven otherwise and pivot on the process tree from there. The 30-day lookback is deliberate: you are hunting the exposure window between mid-June disclosure and your fleet actually landing on the fixed engine, not just today. Extend it to cover your own disclosure-to-patch gap if that was longer. MpCmdRun.exe is a legitimate Defender child and is intentionally not in the list, so this stays tight.

Anchor B: Link and Reparse-Point Abuse in User-Writable Paths

This is the mechanism-side signal, and I am being honest that native visibility into it is weak. Reparse-point and symlink creation is not cleanly surfaced by DeviceFileEvents as a distinct action, so there is no crisp cross-tenant KQL I am willing to hand you as production-ready. Where you can get at it:

• Sysmon Event ID 11 (FileCreate) will record the creation of the link object, though it does not label it as a reparse point. Hunt for link objects created by unprivileged processes under user-writable roots that Defender then traverses, correlated in time with scan activity on the same host.
• The Windows Microsoft-Windows-Kernel-General and object-manager symbolic link auditing, where enabled, is the more precise source, but few fleets enable it.

If you already ingest Sysmon into Sentinel or Defender XDR, build the correlation there. If you do not, this anchor is aspirational, and Anchor A carries the detection.

Anchor C: Reuse the BlueHammer File-Side Anchors

Because RoguePlanet is the same CWE-59 family, the file-side hunts I wrote for BlueHammer transfer directly and I am not going to duplicate them here. In particular, the BlueHammer detection section covers a non-Defender process touching the engine’s own files, SAM or SYSTEM hive reads out of a VSS shadow copy, and a low or medium integrity parent spawning a SYSTEM child. That last one is a generic LPE net worth having deployed permanently regardless of which Defender bug is current. Run those alongside Anchor A rather than reinventing them.

Patch Validation and Mitigation

The whole point of this post. Do the validation first; it is where the real residual risk is.

Confirm the Engine Version, Do Not Assume It

Ground truth per host is the engine version reported by the product itself. A deployment report that says the update “succeeded” is not the same as the engine actually running the fixed build.

Get-MpComputerStatus |
  Select-Object AMEngineVersion, AMProductVersion, AMServiceVersion, NISEngineVersion

AMEngineVersion is the field that matters. Anything below 1.1.26060.3008 is still vulnerable. Roll this into whatever you use for fleet queries, Intune proactive remediations, a Configuration Manager configuration item, or a scheduled script writing back to inventory, and alert on anything under the fixed build. Pay specific attention to the environments listed earlier: isolated networks, version-pinned engines, and machines that were off during the rollout.

For a cross-fleet view in Defender XDR, once Microsoft populates the CVE into threat and vulnerability management you can pivot there:

DeviceTvmSoftwareVulnerabilities
| where CveId == "CVE-2026-50656"
| project DeviceName, CveId, SoftwareName, SoftwareVersion, VulnerabilitySeverityLevel

Treat TVM as a convenience layer that depends on Microsoft’s own cataloging and telemetry freshness, not as authoritative. Get-MpComputerStatus is the value the engine will actually load. Where the two disagree, the local check wins.

Compensating Controls for the Unpatched Tail

Only relevant for hosts that genuinely cannot take the engine update yet. These raise the cost of the link-swap primitive rather than fixing the flaw, so document each with a sunset tied to getting the engine current.

• Restrict SeCreateSymbolicLinkPrivilege. By default unprivileged users cannot create symbolic links, and you want to keep it that way. Audit for accounts or configurations that have granted it more broadly, and pull it back on privileged endpoints.
• Application control on privileged endpoints. If WDAC or AppLocker is already deployed on your tier-0 and admin workstations, it constrains the attacker’s ability to run the local code the exploit needs in the first place. If those projects are not already in flight, this single bug is not the reason to start them under emergency pressure.
• Do not disable Defender. Same as BlueHammer, and doubly so here: RTP state does not affect exploitability and turning the engine off only removes the telemetry Anchor A depends on.

Appendix: Schema Verification Notes

Honesty about how far I trust each query.

• DeviceProcessEvents columns used in Anchor A (InitiatingProcessFileName, FileName, ProcessIntegrityLevel, and the "System" integrity value) are documented in Microsoft Learn and stable across tenants. Anchor A is verified against the schema. What is not verified is the benign-rate in your specific environment; test the lookback before promoting it to a custom detection.
• Anchor B is deliberately prose. I could not construct a DeviceFileEvents query that cleanly isolates reparse-point creation, so I did not pretend one exists. The Sysmon 11 path is real but noisy and requires you to already ingest Sysmon.
• DeviceTvmSoftwareVulnerabilities carries whatever Microsoft has cataloged for the CVE. Coverage and freshness are outside your control, which is why the local Get-MpComputerStatus check is the authority here.
• Get-MpComputerStatus and the AMEngineVersion field are documented and stable. This is the one check in the post I would stake the patch-validation claim on.

References

• Microsoft Security Response Center advisory - CVE-2026-50656
• Help Net Security - Microsoft working on patch for RoguePlanet Defender zero-day (June 2026)
• The Hacker News - Microsoft patches RoguePlanet Defender flaw that can grant SYSTEM privileges (July 2026)
• Morphisec - Microsoft Defender zero-day RoguePlanet: when your detector becomes the attack surface
• My earlier writeup - BlueHammer: a defender’s perspective on the unpatched Windows LPE

If you have telemetry from a real exploitation attempt that lets you validate or refine Anchor A, or a cleaner way to surface reparse-point abuse natively, I want to hear it. Reach me at marcel@graewer.com.