RoguePlanet and GreatXML: Detecting Local Privilege Escalation and BitLocker Security Boundary Abuse

Following our previous research, LevelBlue SpiderLabs continued monitoring a series of Windows security component disclosures published under multiple online aliases, including Nightmare-Eclipse, Chaotic Eclipse, Dead Eclipse, and most recently MSNightmare.

Shortly after Microsoft’s June 2026 Patch Tuesday release, a new proof‑of‑concept (PoC) named RoguePlanet was published targeting Microsoft Defender on fully patched Windows 10 and Windows 11 systems. The technique demonstrated a local privilege escalation path that allows a standard user to obtain SYSTEM-level execution without requiring administrative privileges, kernel exploitation, or memory corruption.

One day later, another technique, GreatXML, was published targeting Windows Recovery Environment and BitLocker-protected systems. Unlike RoguePlanet, GreatXML does not provide local privilege escalation or initial access. Instead, it targets the recovery workflow after administrative access has already been obtained, allowing an attacker to maintain access to protected data by modifying recovery partition contents.

From a defensive perspective, these techniques reinforce the importance of behavioral detection. The most valuable indicators are not necessarily malicious files or known hashes, but unexpected interactions between trusted Windows components.

This research examines the technical mechanisms behind RoguePlanet and GreatXML, including exploitation workflows, forensic artifacts, and detection opportunities grounded in EDR telemetry.

RoguePlanet: Microsoft Defender Workflow Abuse Leading to SYSTEM Execution

RoguePlanet is a local privilege escalation technique that demonstrates how legitimate Windows components can be combined to produce an unintended execution path. Rather than exploiting a kernel vulnerability or memory corruption, it relies entirely on orchestrating normal system behavior across Microsoft Defender, NTFS reparse points, opportunistic locks, and Windows Error Reporting.

By sequencing these interactions, the technique creates a controlled path from a standard user context to SYSTEM-level execution, ultimately causing a trusted process to run attacker-controlled content.

Figure 1. High-level RoguePlanet execution flow.

The vulnerability exists in the interaction between these components rather than in any single feature. From a detection perspective, the technique produces consistent secondary artifacts despite relying entirely on legitimate system components.

Technical Analysis: The Seven-Stage Execution Chain

The objective of RoguePlanet is straightforward: cause a SYSTEM-level scheduled task to execute an attacker-controlled binary. The implementation is significantly more complex. Each stage relies on a legitimate Windows capability. The security issue emerges from how those capabilities are combined. The following stages describe how these components are combined to transition from controlled setup to SYSTEM-level execution.

Stage 1: Dual-Mode Entry

RoguePlanet uses a self-referential binary design that allows the same executable to operate in both user context and SYSTEM context. The binary first determines whether it is already running as LocalSystem. Relevant PoC code:

Figure 2. Logic that checks whether the program is running with SYSTEM privileges and switches behavior to deliver a high-privileged shell if so.

When executed by SYSTEM later in the chain, the binary connects back to a named pipe created by the original user process, identifies the interactive session, and launches a console process under SYSTEM privileges. When executed by the user, the same binary operates as the orchestrator and performs the preparation steps required for exploitation. This design eliminates the need for a separate payload file.

From an EDR perspective named pipe usage such as \\.\pipe\RoguePlanet may not be consistently observable depending on telemetry coverage. As a result, while it can be a useful indicator if present, it should not be relied upon as a primary detection signal.

Stage 2: Poseidon I/O Saturation

RoguePlanet includes an I/O pressure mechanism designed to improve reliability during timing-sensitive filesystem operations. The component, named Poseidon in the source code, creates sustained write activity across available processor cores. Its purpose is to make the timing window created by the oplock condition more predictable.

Figure 3. Component that creates sustained disk activity using multiple threads to make timing-dependent operations more reliable.

One generator thread continuously fills a 4KB buffer using the Windows cryptographic random number generator. Worker threads then write the buffer to UUID-named temporary files under %TEMP%\RP_. The threads remain synchronized until the Defender scan begins, at which point they are released to create filesystem pressure. This activity is not inherently malicious, but the combination of UUID-based temporary files, sustained high-frequency writes, multiple worker threads, and timing correlation with Defender activity creates a valuable behavioral detection opportunity.

In practice, EDR telemetry does not expose the underlying timing manipulation but does reveal intense file system activity, including rapid create, modify, rename, and delete cycles across UUID-named directories. This high-frequency file churn provides a stronger detection signal than the I/O mechanism itself. At this point, the exploit is not yet privileged, but it is shaping the system state to make later timing-dependent operations reliable.

Stage 3: Working Directory and ISO Preparation

The exploit creates its working environment and mounts an embedded ISO image containing a modified copy of wermgr.exe. The file is signed with an EICAR test signature, allowing Defender to detect and process it as part of the quarantine workflow. A key implementation detail is the naming structure. The exploit uses GetWERDir() to retrieve the final directory component associated with Windows Error Reporting:

%TEMP%\RP_<UUID>\System32\wermgr.exe

This path is structurally identical to the legitimate system binary C:\Windows\System32\wermgr.exe — a fact that becomes critical in the final stage. The ISO is mounted without a drive letter, referenced through its raw NT kernel device path to bypass Win32 path restrictions.

EDR telemetry consistently confirms this directory layout across executions. The presence of a System32 directory under %TEMP% is a highly anomalous condition with near-zero legitimate use, making it one of the most reliable detection anchors in this technique. This stage introduces one of the earliest high-confidence detection opportunities, as such directory structures have virtually no legitimate usage.

Stage 4: EICAR Delivery, VSS Discovery, and Oplock

The EICAR-signed wermgr.exe is written to the System32 subdirectory. An NTFS Alternate Data Stream named :WDFOO is also created on the file using low-level NT file APIs, bypassing Win32 ADS creation restrictions. Poseidon I/O threads are released. A separate thread triggers a Defender scan of the file by calling into MpClient.dll directly via runtime-resolved exports through the Defender RPC interface.

A ShadowCopyFinderThread polls the NT object manager directory \Device, comparing against a baseline snapshot of pre-existing shadow copy devices, and watching for Defender to create a new HarddiskVolumeShadowCopy* device as part of its remediation workflow:

Figure 4. Routine that continuously looks for newly created shadow copies to detect when Defender reaches a specific processing stage.

Once a new shadow copy device appears, the exploit constructs the full path to the EICAR file's :WDFOO ADS through that VSS volume, then places an opportunistic lock on it. When Defender's internal processing reaches the point where it opens this file through the shadow copy, the oplock fires, WaitForSingleObject returns, and Defender is paused mid-operation:

Figure 5. Code placing an opportunistic lock on a file and waiting for it to trigger, effectively pausing Defender at a controlled moment.

EDR telemetry consistently shows the creation of the wermgr.exe:WDFOO alternate data stream, typically involving small fixed-size writes.

Figure 6. SentinelOne telemetry illustrating repeated file creation and modification activity within %TEMP% directories during RoguePlanet execution, including the deterministic creation of wermgr.exe:WDFOO alternate data streams. The activity is characterized by high-frequency file churn and consistently sized 4,096-byte writes, producing a stable and repeatable behavioral pattern suitable for detection.

This behavior is highly deterministic across runs and represents one of the most reliable low-level indicators of the exploit chain. In practice, the ADS artifact is far easier to detect than the timing logic it enables. At this stage, the exploit transitions from preparation to active manipulation of Defender’s workflow, with observable filesystem side effects becoming increasingly prominent.

Stage 5: Junction Swap Chain

While Defender is paused by the oplock, the exploit performs the first junction swap. The System32 directory handle is converted to a reparse point junction targeting the mounted ISO. When Defender resumes, it follows the junction and observes the legitimate-looking wermgr.exe on the ISO rather than the EICAR file. Defender effectively sees a clean binary.

The exploit then watches C:\Windows recursively for Defender creating a temporary file matching the pattern Temp\TMP with exactly sixteen trailing characters — the signature that Defender has advanced into active quarantine workflow. On that signal, the junction is swapped again so System32 now points to the wdtest_temp directory.

A second EICAR is written through the junction path, landing inside wdtest_temp. The ISO's wermgr.exe is then byte-range locked to prevent Defender from removing it. Faced with a locked source file, Defender creates a quarantine placeholder, which also lands inside wdtest_temp through the active junction. The exploit watches for size changes in wdtest_temp, capturing the quarantine file's full path. The result is a SYSTEM-owned file sitting in attacker-controlled territory. At this point, the exploit has effectively redirected a trusted remediation workflow into attacker-controlled paths, establishing the conditions required for privilege escalation.

Figure 7. Logic performing timed directory redirection (“junction swaps”) and monitoring file events to capture Defender’s quarantine output.

In EDR telemetry, the junction swaps themselves are not directly visible. However, related activity such as mount point creation and references to raw device paths (for example, \Device\CDROMX) can be observed, providing indirect detection opportunities for reparse point abuse.

Stage 6: Payload Injection

The reparse point is removed from the System32 directory handle, reverting it to a plain directory. The captured quarantine file is opened with full write access and overwritten with the exploit binary, read from the current process's own image on disk. The quarantine file now contains the exploit binary but retains the SYSTEM-level ownership and ACLs that Defender assigned to it.

All working artifacts are then atomically renamed to random UUID paths using NtSetInformationFile with FileRenameInformationEx, preserving open handles while freeing the original paths. Then the root working directory is converted into a reparse point junction targeting C:\Windows.

Figure 8. Final stage: Replacing the quarantined file with attacker code and redirecting paths so it is executed as a trusted system binary.

After this operation, the path %TEMP%\RP_\System32\wermgr.exe resolves transparently through the junction to what appears to be C:\Windows\System32\wermgr.exe.

EDR telemetry confirms that Microsoft Defender (MsMpEng.exe) modifies and interacts with files located in attacker-controlled temporary directories during this stage, demonstrating a key behavioral contradiction: a trusted system process operating on untrusted filesystem paths. This represents the critical boundary violation in the chain, where trust assigned to system processes is implicitly extended to attacker-controlled content.

Stage 7: WER Task Trigger and Shell Delivery

The Windows Task Scheduler COM interface is used to trigger the QueueReporting scheduled task inside the Windows Error Reporting task folder. This task runs under SYSTEM and can be triggered by a non-privileged user.

Figure 9. Code triggering a built-in Windows Error Reporting scheduled task, causing the system to execute the controlled binary with SYSTEM privileges and complete the exploit chain.

The task executes wermgr.exe at the System32 path, which resolves to the attacker payload. The exploit binary launches as SYSTEM, connects back to the orchestrator, and spawns a shell. In telemetry, this stage may also generate Windows Error Reporting artifacts, including WerFault.exe activity, providing additional secondary signals tied to exploitation. With this step complete, the exploit achieves its objective: controlled execution of attacker code under SYSTEM privileges.

Chain Summary

While each stage serves a specific role in the chain, the most reliable detection opportunities arise from the artifacts and behavioral inconsistencies introduced across multiple stages rather than any single step.

Detection Guidance

The detection of this technique is best approached as a correlation problem rather than a signature-matching exercise. Signature-based detections targeting the compiled PoC offer minimal protection. The behavioral chain survives recompilation and remains detectable primarily through runtime activity.

Three points require clarification based on telemetry validation. Named pipe artifacts may not consistently appear across EDR platforms and should be treated as optional signals. Application shimming detections sometimes triggered during execution are not part of the exploit and should be considered noisy correlations rather than meaningful indicators. Similarly, occasional LSASS-related detections observed during execution are incidental and not tied to the attack chain.

In contrast, several behavioral indicators are consistently observable. The presence of a System32 directory under %TEMP% is a high-confidence anomaly. These artifacts are not part of the exploit logic itself, but rather unavoidable side effects of how the exploit manipulates system behavior. The use of alternate data streams on wermgr.exe, specifically the :WDFOO stream, is highly deterministic and represents a strong detection signal. The repeated creation of UUID-based directories combined with high-frequency file activity provides a clear behavioral profile.

Executing or modifying wermgr.exe outside standard system directories and filesystem inconsistencies, such as header-extension mismatches, further strengthen detection coverage. Evidence of SYSTEM processes interacting with user-controlled paths and mount point activity referencing raw device paths are also strong indicators of exploitation.

Additionally, defenders should test highlighted visibility gaps when WMI-based execution paths are involved. In some EDR platforms, particularly those relying heavily on process lineage, WMI-driven execution can result in incomplete telemetry. This limitation is particularly relevant when analyzing post-compromise behavior, including scenarios associated with GreatXML.

While RoguePlanet demonstrates how trusted runtime workflows can be manipulated to achieve privilege escalation, GreatXML’s technique explores how similar assumptions can be abused in recovery scenarios.

GreatXML: BitLocker Bypass via Recovery Partition Answer File Abuse

GreatXML is a design-level abuse of three intersecting Windows behaviors: how WinRE processes Windows answer files, how the offline-scan boot state changes that processing context, and how BitLocker volume access is handled during WinRE's operation.

The Malicious unattend.xml

The PoC unattend.xml was generated using the open-source Schneegans unattend-generator tool (the generator URL is embedded in an XML comment in the file). This is notable for two reasons: It demonstrates the low barrier to creating a functional payload using freely available tooling, and it means the file's XML structure closely follows the documented Windows answer file schema, making it structurally indistinguishable from a legitimate deployment file.

The exploit does not require a novel or malformed XML construct. It uses the standard answer file processing pipeline exactly as documented. The malicious behavior lies entirely in the command content rather than in any parsing flaw or schema abuse.

Processing Passes and Execution Points

The file defines settings across the standard answer file passes. The critical execution occurs in the windowsPE pass, which runs in the pre-OS WinRE environment before any user interaction. The table below describes the structural elements of the malicious file and what each does, without reproducing the payload commands:

The key architectural insight is the two-stage execution in the windowsPE pass: writing to the X: ramdisk first, then executing from it. This sidesteps the path-length and character-escaping constraints that apply to commands specified directly in the RunSynchronousCommand Path element, while remaining entirely within normal answer file behavior.

Attack Chain

The full exploit unfolds across three stages. Only Stage 1 requires an active attacker presence on a running system. Stages 2 and 3 can occur at any later time and require only physical or remote access to the login screen.

Unlike RoguePlanet, the value of this technique lies not in immediate execution, but in the persistence of a configuration change that remains dormant until triggered.

Stage 1: Recovery Partition File Placement

The recovery partition is a hidden partition (typically 500MB to 1GB) that stores WinRE and associated files. It is not assigned a drive letter by default and is not visible in Windows Explorer. To write files to it from a running Windows session, an attacker must:

• Identify the partition: Use diskpart or WMI to identify the recovery partition number.

• Assign a drive letter: Requires an elevated administrator command prompt. Standard users cannot run diskpart. This is the hard constraint, no standard-user path exists for this step.

• Copy the two items: unattend.xml to the partition root, and the modified Recovery directory (containing WindowsRE\ReAgent.xml) to the partition root. These overwrite or supplement existing WinRE configuration.

• Remove the drive letter: Optional cleanup step to reduce visibility. Removing the assigned letter returns the partition to its hidden state.

From an attacker's perspective, this is a one-time action that can be scripted and executed in seconds inside an existing elevated session. The artifacts (two files on a hidden partition) generate no ongoing process activity and produce no runtime detections after placement. This makes Stage 1 the most critical detection point, as it represents the only phase where observable system activity reliably occurs.

Stage 2: Triggering the Offline-Scan WinRE State

If the machine has previously had a Defender offline scan initiated, it may already be in the vulnerable state, and no additional attacker action is required for this stage. If not, the attacker uses their existing admin access to schedule an offline scan through Defender's interface or command-line tooling. The scan does not need to complete; scheduling it is sufficient to set the boot state flag that WinRE reads. The researcher noted uncertainty about whether an attacker with no login access could trigger this state remotely or through some other mechanism. This path was not developed in the PoC.

Stage 3: Trigger from the Lock Screen

With the files planted and the machine in offline-scan WinRE state, the trigger is trivial and requires no credentials. From the Windows login screen, holding Shift while clicking the power button and selecting Restart causes Windows to boot into WinRE on the next cycle. This Shift+Restart behavior is a documented feature and cannot be disabled without Group Policy changes.

On the WinRE boot, the offline-scan state causes WinRE to process the malicious unattend.xml. The windowsPE pass commands execute, the staging script runs, and a console shell spawns with access to the BitLocker-encrypted volume. At this point, the attacker can read, copy, or stage files from the encrypted drive without providing the BitLocker recovery key, PIN, or any credential.

Context: Where GreatXML Sits in the Nightmare-Eclipse Toolkit

Assessed independently, GreatXML looks like a constrained post-exploitation utility with a contested trigger condition. Assessed as part of the full Nightmare-Eclipse cluster, its positioning is more deliberate.

Six of the eight releases target components Microsoft markets as security guarantees: three Defender primitives (BlueHammer, UnDefend, RoguePlanet), two BitLocker bypasses (YellowKey, GreatXML), CTFMON (GreenPlasma), and the Cloud Files mini-filter driver (MiniPlasma). The cluster as a whole maps to a complete Windows attack chain with redundancy at the privilege escalation step and two independent methods of defeating data-at-rest protection.

The most operationally significant aspect of GreatXML is not what it does during the initial compromise – it is what it enables afterward considering the following scenario:

• An attacker achieves administrator access on a BitLocker-protected endpoint.

• The attacker plants the GreatXML files on the recovery partition and initiates an offline scan.

• The attacker's access is detected. Credentials are rotated. Remote access is revoked. The incident is closed.

• The planted files remain on the recovery partition. They survived credential rotation, remote access termination, and the incident response process.

• At any later time, anyone with physical access to the device (including at a locked screen in an unattended office, a travel scenario, or a device seizure) can Shift+Restart and access the encrypted volume.

The value is not defeating BitLocker in real time during active access. The value is that BitLocker ceases to protect data against physical access scenarios for as long as the files remain planted. For an attacker targeting executive devices, sensitive workstations, or devices likely to be physically recovered in an incident — this is the scenario GreatXML was built for.

Detection Guidance

No patch addressing the root cause has been released at the time of writing. The primary detection opportunity is Stage 1 — file placement. This is the only point where the attacker must perform observable actions on a running system. Stages 2 and 3 occur outside the normal Windows telemetry context.

During testing, activities involving WMI usage and recovery partition manipulation demonstrated reduced visibility in some EDR platforms. This suggests that detection strategies for GreatXML should not rely exclusively on process lineage or command-line logging but instead incorporate filesystem monitoring and recovery partition integrity validation.

Conclusion

Taken together, these techniques highlight two distinct but related classes of abuse: real-time workflow manipulation and persistent configuration subversion. RoguePlanet and GreatXML reflect a continued shift in how security boundaries are challenged in modern Windows environments. Rather than exploiting traditional vulnerabilities, both techniques rely on carefully orchestrated interactions between trusted components, showing how legitimate functionality can be combined to achieve unintended outcomes. In this model, the risk lies less in individual features and more in how those features interact under certain conditions.

For defenders, this reinforces the need to move beyond static indicators and toward a behavioral understanding of system activity. The most reliable signals are subtle inconsistencies – trusted processes operating in unexpected contexts, system binaries resolving outside their intended locations, or filesystem structures that should not exist during normal operation. These techniques demonstrate that effective detection depends on identifying when expected relationships between components break down.

RoguePlanet provides clear examples of this through deterministic artifacts such as alternate data stream creation and anomalous directory structures, while GreatXML emphasizes the risk of persistent configuration changes that can silently undermine security assumptions over time. Together, they underscore the importance of correlating activity across system components rather than relying on isolated events.

Ultimately, these findings reflect a broader evolution in attacker tradecraft. As adversaries increasingly operate within the boundaries of legitimate system behavior, defensive strategies must focus on validating those boundaries and detecting when they are crossed. Organizations that prioritize behavioral visibility and contextual analysis will be better positioned to identify and respond to techniques of this kind and those that follow.

Indicators of Compromise: RoguePlanet

Indicators of Compromise: GreatXML