June 10, 2026

Microsoft Defender zero-day RoguePlanet grants SYSTEM privileges

Written by:

ThreatLocker Threat Intelligence

New Microsoft zero-day disclosed after Patch Tuesday

On June 9, 2026, the author of several recent Windows exploits, Nightmare Eclipse, released their eighth project within the last three months, RoguePlanet.

This exploit abuses Windows Defender functionality to perform local privilege escalation (LPE) allowing SYSTEM level access on Windows 10 and Windows 11 machines, with successful replication after the June 9 Patch Tuesday updates pushed by Microsoft. This exploit is currently unpatched and appears to affect all Windows 10 and 11 operating systems with varying degrees of success.

The researcher shared the proof-of-concept exploit on a self-hosted Git repository and stated that the GitHub and GitLab repositories previously hosting their exploits had been removed by Microsoft.

Previous zero-day disclosures from Nightmare Eclipse (also known as Chaotic Eclipse) include YellowKey, GreenPlasma, Bluehammer, and RedSun.

How RoguePlanet escalates low-level user to SYSTEM privileges

The author of the exploit took time to give a brief history of its development and explained that it began as remote code execution before a Microsoft patch changed the functionality it relied on. After this patch, the exploit was rewritten to provide a local privilege escalation.

Similarly to the first exploit released by Nightmare Eclipse, BlueHammer, Windows Defender functionality is abused to escalate a low-level user to SYSTEM level privileges.

This exploit begins by writing an EICAR lure to a fake wermgr.exe file to trigger Windows Defender remediation. By watching for a new HardDiskVolumeShadowCopy device, the exploit can time Defender’s remediation behavior and request an oplock on the file’s alternate data stream, allowing for a favorable race condition to be exploited.

The result of this race condition being won is that the C:\Windows\System32\wermgr.exe file is replaced by a copy of the RoguePlanet executable itself.

Once Defender remediation is abused to overwrite wermgr.exe, the \Microsoft\Windows\Windows Error Reporting\QueueReporting scheduled task is manually triggered. This task attempts to execute wermgr.exe by filename but instead executes RoguePlanet with SYSTEM privileges. The exploit then uses this privileged token to open a SYSTEM level shell to the user, granting full administrative control.

Code analysis

The exploit opens with the dynamic resolution of several ntdll.dll Windows APIs including NtSetInformationFile, NtDeleteFile, NtOpenDirectoryObject, NtQueryDirectoryObject, and NtQueryInformationFile. These APIs are used for direct object manager enumeration, file renaming, file deletion, and reparse point manipulation, as opposed to traditional Win32 file-only APIs. The key primitive is path manipulation: The exploit forcibly opens handles, renames files & directories with FileRenameInformationEx, creates NTFS mount point reparse points, and uses oplocks & locks to control timing.

The large byte array within the code is used to write and create a temporary file that is mounted as a read-only virtual ISO, which is opened using OpenVirtualDisk and AttachVirtualDisk with the ATTACH_VIRTUAL_DISK_FLAG_NO_DRIVE_LETTER option. The ISO file contains a file named wermgr.exe, which is a ZIP file containing the EICAR test string to reliably coerce Defender into scanning and detecting a file.

To trigger the file scan, the exploit loads Defender’s MpClient.dll file from the install directory, and resolves and invokes internal & exported Defender APIs MpManagerOpen, MpScanStart, MpScanResult, MpThreatOpen, MpThreatEnumerate, MpCleanOpen, MpCleanStart, and MpHandleClose. As a result, Defender will then scan zippath, check if a threat was identified (which triggers on the EICAR data), and MpCleanStart will be called to initiate remediation actions. The exploit queries existing shadow copy snapshots by watching the NT object namespace under \Device and then watches for newly created ones. Once a new shadow copy is created and caught in the watcher loop, the exploit verifies that \Windows is accessible through the shadow copy device and returns the VSS device path.

An alternate data stream path named WDFOO is opened through the newly detected shadow copy, and an oplock is requested to control timing over Defender file actions while the filesystem is actively modified. The exploit creates a temporary falsely constructed System32 directory tree which resembles a Windows directory layout under %TEMP%\RP_<GUID>. The directory is continuously modified with mount point reparse points being modified to associate the directory with the mounted ISO device, and a created directory wdtest_temp.

The CreateJunction function is used to build a REPARSE_DATA_BUFFER with IO_REPARSE_TAG_MOUNT_POINT and applies it with FSCTL_SET_REPARSE_POINT. Additionally, FSCTL_DELETE_REPARSE_POINT is used to delete a reparse point, LockFile is used to lock files, and ReadDirectoryChangesW to detect files created or modified by Defender. The combination of these methods creates the foundation for controlling a target path prior to access or manipulation by a privileged process. Once the Defender remediation process has been started and delayed, the exploit reads its own executable from disk and writes a copy into a file path created during the remediation race.

The intended outcome during this process is for a copy of the exploit executable to be written to the real Windows directory tree, overwriting the real Windows Error Reporting executable C:\Windows\System32\wermgr.exe.

The CoCreateInstance API creates a new COM object to connect to the TaskScheduler service and trigger the \Microsoft\Windows\Windows Error Reporting\QueueReporting scheduled task. This task executes wermgr.exe with SYSTEM privileges by default, which has been overwritten with the exploit file.

Once this task is triggered, the logic from this instance exits. The new instance of the exploit file, now executed with SYSTEM privileges, connects to the previously created named pipe \\.\pipe\RoguePlanet, uses the GetNamedPipeServerSessionId API to identify the original user session, and executes the function LaunchConsoleInSessionId, which duplicates the SYSTEM token and spawns a shell.

Mitigations for RoguePlanet

Mitigation for RoguePlanet should focus on two key objectives: preventing execution of the untrusted local binary and detecting the Defender cleanup and path-redirection sequence before control is transferred to wermgr.exe.

Effective mitigation is heavily dependent on application control.

Organizations should prevent the malicious binary from executing by enforcing allowlisting policies that block unsigned, untrusted, or unapproved executables from user-writable locations, such as %TEMP%.

Organizations should also avoid relying on broad path-based trust rules, particularly for locations such as C:\Windows\*.

RoguePlanet attempts to relocate attacker-controlled content into trusted Windows directories to inherit path-based trust. As a result, approval decisions based on signature, publisher, or file hash provide significantly stronger protection than path or filename based rules alone.

Monitoring for unusual file movement within trusted Windows paths (particularly when followed by execution of wermgr.exe) can provide additional opportunities to detect and disrupt exploitation before payload execution occurs.