Howler Cell

GreatXML: Windows Zero-Day Turns Defender Offline Scan Into BitLocker Backdoor

Written by Rahul Ramesh | June 11, 2026 6:59:31 PM Z

Key Findings

    • BitLocker bypass primitive abusing the state that Windows Recovery Environment enters after Microsoft Defender's offline scan has been used on a machine. No kernel bug, no memory corruption.
    • PoC published on GitHub on June 11, 2026 under the MSNightmare handle, with mirrors on git.projectnightcrawler[.]dev and git.churchofmalware[.]org. No coordinated disclosure, no CVE, no patch.
    • The chain is a planted unattend.xml plus a modified Recovery directory at the root of the recovery partition. The next entry into WinRE via Shift + Restart spawns a shell with unrestricted access to the BitLocker-encrypted volume. The trigger step requires no authentication, because Shift + Restart is available from the lock screen.
    • GreatXML is a post-compromise tool, not an initial access vector. Writing to the recovery partition root requires administrator rights. An attacker who lands admin once can plant the files silently. Credential rotation and loss of remote access do not remove them. The value is persistent data access that survives incident response.
    • Precondition: a Defender offline scan must have been initiated on the host at some prior point. The researcher acknowledges a no-prior-scan path is plausible but did not pursue it.
    • Cyderes Howler Cell verified the proof-of-concept on a fully patched Windows 11 machine.
    • Eighth tool from the Nightmare-Eclipse cluster in roughly ten weeks, and the second BitLocker bypass in the series after YellowKey.

Summary

On June 11, 2026, one day after publishing RoguePlanet, MSNightmare pushed another repository to GitHub. The exploit is named GreatXML, after the malicious Windows answer file at the center of the attack. Mirrors went up in parallel at git.projectnightcrawler[.]dev/NightmareEclipse and git.churchofmalware[.]org/Nightmare_Eclipse.

  • As with RoguePlanet: no CVE, no patch, no coordinated disclosure.

GreatXML is a BitLocker bypass. It abuses the state that Windows Recovery Environment enters after Microsoft Defender's offline scan has been used on a machine. With a malicious unattend.xml and a modified Recovery directory planted at the root of the recovery partition, the next entry into WinRE via Shift + Restart spawns a shell with unrestricted access to the BitLocker-encrypted volume. The trigger step does not require an authenticated session.

  • The exploit carries one significant constraint: writing to the recovery partition root requires administrator rights.

This rules out a standard-user-to-shell path. GreatXML operates as a persistence and data-access primitive after initial elevation, not as an initial access vector. An attacker who lands admin once can plant the files and walk away. Credential rotation, password resets, and loss of remote access do not remove the planted artifacts. Anyone with subsequent physical access can Shift + Restart from the lock screen, drop into WinRE, and read the encrypted volume without a recovery key.

  • This is the eighth tool from this researcher in roughly ten weeks, and the second BitLocker bypass in the cluster after YellowKey.

Figure 1: Howler Cell Team confirming GreatXML POC

The full technical breakdown of how the exploit chain operates follows below.

What is the Vulnerability?

GreatXML is a design-level abuse of the interaction between Windows Recovery Environment (WinRE), Windows answer file processing, and the state that Defender’s offline scan feature leaves on a machine. It does not exploit a memory safety bug. It does not bypass any cryptographic primitive in BitLocker directly.

WinRE is a minimal Windows environment that boots from the recovery partition and is used for repair, reset, and security scanning tasks. When Defender’s offline scan is used, WinRE is placed into a specific operational state that changes how it processes files present on the recovery partition, including Windows answer files. An unattend.xml placed at the recovery partition root (Figure 2) in this state is processed during the WinRE boot sequence before normal security boundaries are enforced, before BitLocker prompts the user, and before any interactive logon occurs.

Figure 2: Root of Recovery partition

The vulnerability emerges from the combination of that trusted processing context, the ability for a privileged user to write to the recovery partition, and the BitLocker volume available to WinRE during its operation. The answer file redirects that access to attacker-controlled commands.

More Than a String of Zero-Days

Reading the seven exploits Nightmare-Eclipse has published between April 3 and June 10, 2026, in isolation misses the point. Each disclosure on its own is a CVE. Taken together, they map cleanly to a full Windows attack chain with deliberate redundancy at the most valuable links. The set is structured from a vengeance-driven bug drop, but it also looks like an operator's toolkit.

The targeting pattern

Six of the seven land on components Microsoft positions as defensive guarantees:

    • Windows Defender: BlueHammer (CVE-2026-33825), UnDefend (CVE-2026-45498), and RoguePlanet. Three separate primitives in the EDR shipped by default on every Windows install.
    • BitLocker: YellowKey (CVE-2026-45585). The data-at-rest control Microsoft markets as the answer to lost or stolen devices.
    • CTFMON / Collaborative Translation Framework: GreenPlasma (CVE-2026-45586). A process loaded into nearly every user session and a recurring LPE surface historically.
    • Cloud Files Mini Filter Driver: Microsoft fixed CVE-2020-17103 in 2020, and MiniPlasma is the researcher's claim that the original fix was incomplete.
    • RedSun (CVE-2026-41091): technical specifics remain limited in public reporting.

This is not a spray across whatever bug surface was easiest to attack. The target list reads like Microsoft's endpoint security marketing page, in reverse. The researcher is hitting the components customers were told to trust.

Hypothesis on How the Pieces Chain Together

Read in the order an operator would run them, the seven cover the full kill chain:

1. Initial access

RoguePlanet was originally built as arbitrary code execution, abusing Defender's handling of files on remote SMB shares served from attacker-controlled .vhd(x) images. A mid-May Defender engine update changed the mpengine!SysIO* APIs and closed that path, so the published version is a local privilege escalation.

2. Defense evasion

UnDefend provides a Defender capability bypass. Used early, it suppresses the telemetry the rest of the chain would otherwise generate. This is the most operationally valuable position in the toolkit, because every later step becomes noisier without it.

3. Privilege escalation

Four independent local privilege escalation primitives are now public:

    • BlueHammer (Defender, to SYSTEM)
    • GreenPlasma (CTFMON, to SYSTEM)
    • MiniPlasma (Cloud Files filter, to SYSTEM)
    • RoguePlanet (Defender quarantine pipeline race, to SYSTEM)

Operators do not need four. They want four. LPE primitives have reliability problems: race conditions, build sensitivity, hardware variance. The researcher describes RoguePlanet itself as a hit or miss across machines, with 100% success on some and failure on others. A toolkit with four independent SYSTEM primitives across three subsystems is what you build when one payload has to run reliably across an enterprise estate with mixed Windows 10 and 11 builds. If BlueHammer fails on a hardened machine, RoguePlanet may win the race. If both Defender bugs are patched, CTFMON or the Cloud Files filter still provides a path.

4. Physical and data access

Once SYSTEM is achieved on a live host, the chain has full local control. YellowKey extends the same toolkit to physical-access scenarios: lost devices, evil-maid attacks against executive laptops, lab access for hardware-rooted persistence. It is the data-recovery counterpart to the remote chain.

Technical Analysis

The attack unfolds across three stages. File placement during the post-compromise window is the only step requiring runtime access. Once the files are in place, the bypass triggers on any subsequent Defender offline scan reboot without further attacker presence on the system.

Stage 1: File Placement (Post-Compromise, Requires Administrator Rights)

The attacker with administrator access copies two items to the root of the Windows recovery partition: unattend.xml, a Windows answer file carrying malicious configuration directives, and the Recovery directory (which contains a WindowsRE subdirectory) from the repository, which contains modified WinRE components. The recovery partition is not accessible to standard users. Administrator rights are required to write to it, which is the primary constraint on this exploit’s applicability.

The unattend.xml file is a standard Windows deployment answer file format. WinRE processes it natively during its boot sequence. The malicious version instructs WinRE to execute commands that spawn a shell environment with access to the BitLocker volume.

The recovery partition is not mounted or accessible as a drive by default in Windows. To write files to it from a running session, an attacker must first assign it a drive letter using diskpart, which requires an elevated administrator command prompt. Standard users cannot run diskpart without admin credentials and therefore cannot access the partition at all.

Note: The recovery partition is not mounted or accessible as a drive by default in Windows. To write files to it from a running session, an attacker must first assign it a drive letter using diskpart, which requires an elevated administrator command prompt. Standard users cannot run diskpart without admin credentials and therefore cannot access the partition at all.

Stage 2: Trigger State via Defender Offline Scan

The exploit requires the target machine to be in the WinRE offline-scan state. If Defender’s offline scan has been run at any point previously, the machine is in this state and no further action is required. The attacker reboots the machine into WinRE by holding Shift and clicking Restart from the Windows login or Start menu.

If the offline scan has never been initiated, the attacker must trigger it. With admin access already established for Stage 1, this is straightforward: initiate an offline scan through Defender’s interface (Figure 3), which schedules the offline scan to run on next WinRE boot. The machine can then be rebooted into the exploit state.

Figure 3: Defender Offline Scan

Stage 3: WinRE Boot and BitLocker Bypass

WinRE boots from the recovery partition and processes the malicious unattend.xml placed in Stage 1. The answer file directives execute within the trusted WinRE context before the operating system loads and before BitLocker requires user authentication. The result is a shell with unrestricted access to the BitLocker-protected volume, exposing all encrypted data without requiring the recovery key, PIN, or any credential.

Figure 4: GreatXML shell output showing BitLocker volume access

What Should Defenders Do?

No patch addressing the root cause has been released. Defenders should focus on detecting the file placement stage, which is the only point in the chain where observable attacker activity occurs on a live running system.

  • Monitor for unattend.xml being written to the recovery partition root by any process outside of Windows Update or WinRE setup context. No legitimate software places answer files at this path during normal operation.
  • Alert on new directories created at the recovery partition root, specifically Recovery or WindowsRE named directories, written by non-system processes.
  • Monitor for Defender offline scans being scheduled or initiated by user-context processes.
  • Alert on WinRE boot events that follow shortly after a non-automated Defender offline scan trigger, particularly where the preceding session included recovery partition file write.

Conclusion

GreatXML extends the Nightmare-Eclipse cluster beyond privilege escalation and into persistent data access. Where BlueHammer, RedSun, and RoguePlanet deliver SYSTEM shells on a live running system, GreatXML bypasses the one protection that is supposed to survive a system compromise: BitLocker encryption at rest.

The constraint of requiring administrator rights for file placement means GreatXML does not function as an initial access vector. Its value is as a second-stage capability: an attacker who achieves admin access once can plant the files silently and then extract data from the encrypted volume on any subsequent Defender offline scan, without logging in, without triggering runtime detections, and without needing the BitLocker key.

The WinRE answer-file processing path and the offline-scan boot state are both legitimate by-design Windows features. Until Microsoft constrains how unattend.xml files are processed in the offline-scan WinRE context, the only reliable defense is detecting the file placement before the next WinRE boot occurs.

Appendix

  • Zero-Day POC: https://github.com/MSNightmare/GreatXML
  • Mirror: https://git.churchofmalware[.]org/Nightmare_Eclipse/
  • Mirror: https://git.projectnightcrawler[.]dev/NightmareEclipse/
  • Blog: https://deadeclipse666.blogspot[.]com/

IOCs

SHA-256

Malicious unattend.xml - 785CCFA88C1AA0B33A0E9A27C5BAF68A8F146B435F57BF0247D5F15878B90389