GreatXML: How a Setup File Unlocked BitLocker — And Why Microsoft Can’t Stop This Researcher

"This was an accidental discovery. It took a total of 4 hours to find this." — Nightmare-Eclipse, June 10, 2026

If you've ever clicked "Scan with Windows Defender Offline" on your PC, your BitLocker encryption may have already been quietly compromised — and Microsoft has no patch for it yet.

This is the story of GreatXML: a zero-day BitLocker bypass that abuses a Windows setup file designed for OEM factories, a recovery environment that trusts everything it reads, and a researcher that Microsoft has been trying to silence for months.

Who Is Nightmare-Eclipse?

Before diving into the vulnerability, it's worth understanding who's behind it — because the context is just as interesting as the bug itself.

Nightmare-Eclipse (also known as MSNightmare, Chaotic Eclipse, and Dead Eclipse) is an anonymous security researcher who has developed a pattern that's become almost rhythmic: every major Microsoft Patch Tuesday, a new zero-day drops from this researcher — often the same day patches are released, or immediately after.

Their track record over the past few months reads like a Microsoft nightmare (pun intended):

🔴 RedSun — Windows component flaw. Silently patched by Microsoft, no CVE issued.

🔴 GreenPlasma — Windows component flaw. Patched in June 2026 Patch Tuesday.

🔴 YellowKey (CVE-2026–45585) — BitLocker bypass via WinRE. Patched in June 2026 Patch Tuesday.

🔴 BlueHammer — Windows Defender exploit. Publicly released, no patch.

🔴 RoguePlanet — Windows Defender LPE → SYSTEM. Publicly released, 341 GitHub stars.

🔴 GreatXML — BitLocker bypass via WinRE + unattend.xml. No patch. No CVE.

Microsoft has banned multiple GitHub and GitLab accounts belonging to this researcher. The response? Alternative hosting on git.projectnightcrawler.dev and git.churchofmalware.org, with PGP-signed blog posts ensuring authenticity across every disclosure.

The adversarial relationship here is real. In one blog post, Nightmare-Eclipse wrote:

"Microsoft forgot that even if they banned my GitLab and Github accounts, they cannot unwrite my code. Once it's public, you can't remove it."

GreatXML is the latest move in this chess match.

The Foundation: Why WinRE Is a Critical Attack Surface

To understand GreatXML, you first need to understand what happens when your computer boots into the Windows Recovery Environment (WinRE).

BitLocker's entire security model rests on keeping your encryption keys away from unauthorized parties. It uses the TPM chip to bind those keys to your system's boot state — normally, if someone yanks your hard drive, they get an encrypted brick.

But here's the architectural tension: WinRE needs to access your drive to fix it.

When Windows boots into recovery mode — whether to run diagnostics, system restore, or a Defender Offline Scan — BitLocker automatically unlocks the volume. It has to. Otherwise, recovery would be impossible.

This creates a trust boundary problem. WinRE operates with elevated privileges on an already-unlocked volume, and it processes configuration files from that same volume. The question then becomes: what happens if those configuration files are malicious?

GreatXML answers that question.

The Vulnerability: An OEM File in the Wrong Hands

What is `unattend.xml`?

unattend.xml is a Windows Answer File — a legitimate XML format that Microsoft created to allow OEMs and system administrators to automate Windows setup without user interaction. It's how laptop manufacturers pre-configure your language, user accounts, and regional settings before the OS even boots.

The file is processed during various Windows Setup passes, including windowsPE — which runs in the pre-installation environment before Windows fully loads.

The critical insight Nightmare-Eclipse had: WinRE is essentially a WinPE environment. And WinPE processes unattend.xml.

The Missing Piece: Defender Offline Scan State

Windows Defender's Offline Scan feature boots the machine into a special WinRE state to scan for malware that hides from a running OS. When this state is active, the recovery environment handles the transition differently — and in that specific boot path, WinRE will parse an unattend.xml found in the recovery partition without sufficient integrity validation.

This is the unlock condition. This is GreatXML.

The Attack: Step by Step

Prerequisites

Physical access to the target machine (brief — even a few minutes)
A USB drive or ability to write to the recovery partition
Target must have ever initiated a Windows Defender Offline Scan at some point

Files Required

The repository contains two key artifacts:

unattend.xml — The malicious answer file. In its windowsPE settings pass, it contains:

<RunSynchronousCommand wcm:action="add">
    <Order>1</Order>
    <Path>cmd.exe /c >>X:\pe.cmd (echo:start X:\Windows\System32\conhost.exe)</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
    <Order>2</Order>
    <Path>cmd.exe /c "X:\pe.cmd"</Path>
</RunSynchronousCommand>

<RunSynchronousCommand wcm:action="add">
    <Order>1</Order>
    <Path>cmd.exe /c >>X:\pe.cmd (echo:start X:\Windows\System32\conhost.exe)</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
    <Order>2</Order>
    <Path>cmd.exe /c "X:\pe.cmd"</Path>
</RunSynchronousCommand>

Translation: when WinRE boots and processes this file, it executes a batch command that spawns conhost.exe — a Windows console host. In the WinRE context, this is a fully privileged shell with unrestricted access to the now-unlocked BitLocker volume.

Recovery/WindowsRE/ReAgent.xml — The recovery configuration file that tells WinRE how to locate and use the recovery environment.

Exploitation Flow

[Attacker has physical access]
        ↓
Copy unattend.xml + Recovery/ to the ROOT of the recovery partition
        ↓
Reboot target via: Shift + Click Restart → Troubleshoot → Advanced → ...
        ↓
Machine enters WinRE (offline scan state)
        ↓
WinRE parses unattend.xml from recovery partition
        ↓
windowsPE pass executes → conhost.exe spawns
        ↓
SYSTEM-level shell on BitLocker-unlocked volume ✓

[Attacker has physical access]
        ↓
Copy unattend.xml + Recovery/ to the ROOT of the recovery partition
        ↓
Reboot target via: Shift + Click Restart → Troubleshoot → Advanced → ...
        ↓
Machine enters WinRE (offline scan state)
        ↓
WinRE parses unattend.xml from recovery partition
        ↓
windowsPE pass executes → conhost.exe spawns
        ↓
SYSTEM-level shell on BitLocker-unlocked volume ✓

Two Attack Scenarios

Scenario A — No login required (high impact): If the victim has ever run Defender Offline Scan, the machine is passively vulnerable. The attacker only needs brief physical access to copy the files and trigger a WinRE reboot. No credentials needed whatsoever.

Scenario B — Login required: If Defender Offline Scan was never run, an attacker must either log in and initiate the scan themselves, or find a method to put the machine into WinRE's offline scan state without authentication — something Nightmare-Eclipse believes is achievable.

Why This Matters Beyond the Technical

BitLocker Was Reporting "Protected"

One of the most striking details in the screenshots shared by the researcher: BitLocker still reported the drive as fully protected during the entire attack. The encryption was not broken. The keys were not extracted. The drive was simply accessed through the environment that BitLocker itself trusts.

This is the uncomfortable truth about disk encryption: it protects your data from someone pulling your drive. It doesn't protect you from a trusted environment being weaponized against you.

No CVE. No Patch. No Coordinated Disclosure.

As of June 12, 2026, GreatXML has:

No CVE assigned
No Microsoft security advisory
No patch

The timing is notable. Microsoft's June 2026 Patch Tuesday addressed YellowKey (CVE-2026–45585) — Nightmare-Eclipse's previous BitLocker bypass using the same WinRE attack surface. GreatXML was released the day after those patches dropped.

Security analysts at Hive Security noted this isn't likely coincidental:

"GreatXML appeared immediately after that patch window, which makes it look less like a random one-off and more like the next move in the same recovery-environment research sequence."

The Pattern: Recovery Environments Are the New Attack Surface

YellowKey. GreatXML. Both weaponize WinRE. Both bypass BitLocker through the environment Windows itself uses for recovery. This is not a single bug — it's an attack class.

The implication for defenders is significant: patching one bypass doesn't close the research avenue. As long as WinRE operates with elevated trust on unlocked volumes and processes files without integrity verification, this attack surface remains open.

Defensive Recommendations

While there is no official Microsoft patch, organizations and individuals can take the following interim steps:

1. Physical access control is non-negotiable. GreatXML requires physical access. If your threat model includes adversaries who can physically touch machines (insider threats, targeted attacks, laptop theft), standard endpoint controls are insufficient.

2. BitLocker + TPM + PIN. Using TPM alone means BitLocker unlocks automatically on boot — including into WinRE. Adding a PIN (TPM+PIN configuration) requires the user to authenticate before the volume unlocks. This breaks the automatic unlock that GreatXML depends on.

Note: Nightmare-Eclipse separately described a technique called YellowKey that worked against TPM+PIN configurations — but that PoC was not released due to the researcher's personal reliance on BitLocker.

3. Audit and restrict WinRE access. Enterprise environments should review Group Policy settings around WinRE access. Disabling or hardening recovery boot options where operationally feasible reduces the attack surface.

4. Monitor recovery partition integrity. Unexpected files (unattend.xml, unfamiliar XML configs) in the recovery partition root are a red flag. Consider implementing file integrity monitoring on these partitions.

5. Reconsider using Defender Offline Scan on sensitive machines. If a machine has never run Defender Offline Scan, Scenario A doesn't apply. This doesn't eliminate the risk (Scenario B may be feasible), but it narrows the passive attack surface.

6. Watch for Microsoft's patch. Track CVE-2026-* assignments related to WinRE and BitLocker bypass. When a patch drops, prioritize it.

The Broader Picture

Nightmare-Eclipse is a polarizing figure. Their methods — full public disclosure with no coordinated reporting to Microsoft, openly adversarial blog posts, infrastructure built to survive Microsoft's takedown attempts — put them outside mainstream responsible disclosure norms.

But the research itself is technically rigorous. Every vulnerability disclosed has been reproducible. RoguePlanet (341 GitHub stars) demonstrated a real Windows Defender LPE chain. YellowKey became a CVE with a Patch Tuesday fix. And now GreatXML: technically plausible, publicly demonstrated, and unpatched.

The uncomfortable question for defenders isn't about this researcher's motivations. It's that the Windows Recovery Environment has now been used as an attack vector multiple times in quick succession, with public PoCs, and the architectural root cause — recovery environments operating with elevated trust on unlocked volumes — remains unresolved.

That's what security teams should be focused on.

Key Takeaways

GreatXML is a zero-day BitLocker bypass using unattend.xml in WinRE
Requires physical access + target must have run Defender Offline Scan at least once
Spawns a SYSTEM-level shell on the encrypted volume with no decryption key needed
Released by Nightmare-Eclipse (MSNightmare), a prolific Windows vulnerability researcher
No CVE, no patch as of June 12, 2026
Part of a larger pattern of WinRE-based BitLocker bypass research
Interim defense: TPM+PIN, physical access controls, recovery partition monitoring

References:

GitHub: github.com/alisalive | LinkedIn: linkedin.com/in/camalzads

Contents