RoguePlanet (CVE-2026–50656): I Didn’t Touch System32 — Defender Did It for Me

A month ago, an anonymous researcher going by NightmareEclipse dropped the RoguePlanet proof-of-concept. Plenty of articles have described what it does — but very few explain how and why it actually works. After digging through the code myself, here's my attempt to the flow in a more layman manner. It might not be 100% correct, but it should be roughly there. I think?

If I told you there's an exploit that replaces a protected Windows system file — and it never once writes to that file itself — would you believe me?

That's exactly what RoguePlanet does. Instead of fighting Windows Defender, it befriends it. It tricks Defender into doing the dirty work: deleting the real wermgr.exe and writing the attacker's payload in its place.. All without the exploit ever touching C:\Windows\System32.

This is the story of how that works, explained for anyone who's ever wondered what "TOCTOU," "junction," or "oplock" actually mean in practice.

— -

The Core Trick in Plain English

Imagine you're at a restaurant. You order a steak. The chef cooks it, then realizes it's spoiled and sets aside a "clean" replacement. While the chef isn't looking, you swap their clean steak with your own. Then you switch the menu so that when the chef tries to put the replacement back on your plate, it actually lands on the VIP table (System32).

The restaurant manager (a SYSTEM process) unwittingly delivers your steak to the VIP table. You never touch the VIP table yourself.

That's it. The entire exploit.

— -

The High-Level Idea

Windows protects C:\Windows\System32. You can't just write there as a normal user. But Windows Defender can — it runs as SYSTEM and is allowed to remediate files anywhere.

RoguePlanet's insight is simple: what if we make Defender want to "remediate" a file inside System32, while feeding it our own payload as the "clean" version?

The exploit creates a fake System32 directory in the user's temp folder, tricks Defender into scanning a file there, then swaps the directory with a junction that silently redirects to the real C:\Windows. When Defender tries to clean up, it follows the redirect and overwrites the real wermgr.exe — with the attacker's code.

Defender does all the work. The exploit never touches System32.

— -

The Three Techniques

The exploit uses three tricks to pull this off:

1. Directory Junctions. An NTFS junction makes one path transparently point to another. Defender can't tell the difference. The exploit uses three of these — the last one is the killer.

2. Oplocks (polite pauses). Oplocks let the exploit freeze Defender mid-operation, buying time to set up the next trick.

3. Open Handles. Even after a file is renamed, an open handle still points to its data. The exploit uses this to keep the payload accessible after it's been "moved away."

— -

The Flow

The exploit carves out a workspace in %TEMP% with a fake System32 directory, mounts a small ISO containing the EICAR test file, copies EICAR from the ISO into the fake System32\wermgr.exe, and tells Defender to scan it via its internal API. Defender takes the bait and begins scanning. This is where the game starts.

While Defender is busy scanning, the exploit starts shuffling things around using junctions:

• Junction #1 points the fake System32 to a mounted ISO, so if Defender looks again, it finds the EICAR there instead.
• The exploit then waits — using ReadDirectoryChangesW — for Defender to leave breadcrumbs (temp files it creates during scan). Once spotted, Junction #2 points the fake System32 somewhere else, keeping Defender chasing the EICAR across different directories.

At this point, Defender's remediation has begun creating its own internal "clean copy" of the file it's trying to fix. The exploit watches for this. When Defender creates that temp file, the exploit uses an oplock to freeze Defender's I/O on the directory — a polite way of saying "hold on, I'm not done yet."

While Defender is paused, the exploit reads its own binary from disk and writes it into that temp file — overwriting Defender's clean copy with the actual payload.

Here's where open handles come in. The exploit renames the payload file away to a random path, but deliberately keeps the handle open. The file is now "moved" on the filesystem, but the handle keeps the data alive and accessible.

With the workspace emptied, the exploit creates Junction #3: the temp working directory → C:\Windows. This is the big one. From this point on, any path through that temp folder silently resolves to the real Windows directory.

Defender's remediation finishes. It tries to delete the "threat" at the scanned path — which now resolves to C:\Windows\System32\wermgr.exe. Then it tries to restore its "clean copy" to the same path. Both operations land on the real wermgr.exe. The real file is deleted. The "clean copy" — which is actually the payload, kept alive by the open handle — is written in its place.

A SYSTEM process just did the exploit's dirty work.

Finally, the exploit triggers QueueReporting, a scheduled task that runs C:\Windows\System32\wermgr.exe as SYSTEM. That file is now the payload. The payload connects back through a named pipe, confirms it's running as SYSTEM (via IsRunningAsLocalSystem()), and hands the attacker a SYSTEM shell.

— -

Why It Survives Reboot

The payload is physically written to disk at C:\Windows\System32\wermgr.exe. It's a real file, written by Defender's SYSTEM process.

— -

The Takeaway

RoguePlanet is a TOCTOU (Time-of-Check to Time-of-Use) attack. Defender checked the file when it was in a harmless temp directory. By the time it acted on that path, the exploit had swapped the directory with a junction to System32. The check and the use saw two completely different targets.

The exploit doesn't break the rules. It just makes the rules apply somewhere else.

— -