Nightmare Eclipse's GreatXML BitLocker bypass looks shaky, but it's a good excuse to audit your homelab's disk encryption

Nightmare Eclipse, the prolific zero-day hunter currently waging a one-person campaign against Microsoft, published another exploit late Wednesday. This one, named GreatXML, claims to spawn a command prompt with unrestricted access to a BitLocker-protected volume. The researcher called it an "accidental discovery" that took roughly four hours to find, and it lands a day after their RoguePlanet local privilege escalation drop pushed the public 0-day tally to eight.

I run encrypted Windows nodes in my lab alongside the usual pile of Linux hypervisors, so a BitLocker bypass gets my attention fast. But before anyone yanks drives out of their rack in a panic, the technical reality here matters more than the headline, and the reality is messy.

What GreatXML actually claims to do

The attack, as written up by Nightmare, works like this:

1. Copy unattend.xml and the Recovery directory to the root of the recovery partition.
2. Reboot into the Windows Recovery Environment (WinRE) by Shift-clicking Restart.
3. If everything lines up, a shell with full access to the BitLocker volume spawns.

The stated prerequisite is that the target system has run a Microsoft Defender Offline scan at some point in the past. If it never has, you'd first need to log in and trigger one, or, as the researcher vaguely puts it, "figure out a way to boot into WinRE in offline scan state."

That prerequisite is where the whole thing starts to wobble.

The reproduction problem

Will Dormann, a security researcher who is hard to wave away when it comes to Windows internals, tried to follow the steps and called the writeup "flawed." In his testing, the command prompt only appeared the next time a Defender Offline scan actually ran, not on demand after planting the two files and rebooting.

His point cuts to the bone:

"In order to trigger a Microsoft Defender Offline scan, you both need to be logged in to Windows, and also have admin credentials. And if you've already got that level of access, you can just turn off bitlocker."

That is the load-bearing critique. The entire value of a BitLocker bypass is defeating encryption without already holding the keys to the machine. If the attack path requires an authenticated admin session to arm it, the threat model collapses into "an admin can decrypt their own disk," which has never been a vulnerability. Dormann added that across all three lineages of Windows 11 he had on hand, planting the files and Shift-rebooting into WinRE did not automatically drop the system into Defender Offline scan mode, contradicting the core mechanism of the writeup.

Microsoft acknowledged it is "actively investigating" RoguePlanet but had not commented on GreatXML or any patch timeline. The company has also said none of these eight bugs came through its official disclosure channels before going public.

Why a homelab builder should still care

Even if GreatXML turns out to be a dud, it points a flashlight at a part of the Windows boot chain that a lot of people who deploy encrypted machines never think about: the recovery partition and the unattended-install plumbing.

BitLocker's security guarantees lean heavily on the TPM measuring the boot path and refusing to release the volume key if something upstream changed. WinRE sits in an awkward spot. It is a separate, typically unencrypted partition that has historically been a soft underbelly. Microsoft has patched WinRE-based BitLocker bypasses before (CVE-2022-41099 is the famous one, where a stale WinRE image let you boot a recovery shell that could touch the protected volume), and the fix involved patching the recovery image itself, something a huge number of systems silently missed because WinRE updates are notoriously fragile.

The unattend.xml angle is the part worth internalizing. That file drives automated Windows setup, and historically it has been a place where people leave plaintext local admin credentials, autologon settings, and post-install scripting. If an attacker can write an unattend.xml to a partition that gets parsed during a recovery or setup phase, that is a meaningful primitive regardless of whether this specific Defender Offline trick pans out. The combination of "unencrypted recovery partition" plus "a config file that controls automated setup behavior" is exactly the kind of seam attackers probe.

A practical audit checklist

Rather than chase an unconfirmed exploit, here is what I actually did on my own encrypted Windows boxes this week, and what I'd suggest if you run any in a lab or homelab:

• Confirm WinRE is patched. Run reagentc /info to see the WinRE status and location, then verify the recovery image picked up the post-CVE-2022-41099 servicing. Microsoft's KB5025175 guidance covers the manual reseal steps if your image was never updated, which is depressingly common on machines built from older media.
• Use TPM plus PIN, not TPM alone, on anything physical. TPM-only protectors release the key automatically once the measured boot path validates. Adding a pre-boot PIN means a recovery-environment trick that doesn't break the actual key derivation still leaves the volume sealed. For a lab box you walk up to, the friction is trivial.
• Don't leave secrets in unattend.xml. If you image machines with autounattend files, scrub credentials out and use a first-boot script that pulls secrets from somewhere protected. Treat the recovery partition as readable by an attacker with physical access, because it is.
• Check whether you even need WinRE on the recovery partition. On servers and headless nodes, a local recovery environment is often more attack surface than convenience. You can manage recovery from external media instead.

None of this requires waiting on Redmond. The recovery partition has been a recurring weak point for years, and the right posture is to assume that part of the disk is hostile and lean on TPM+PIN and a properly serviced WinRE image to carry the actual security.

Where this leaves the Nightmare saga

The broader story remains a disclosure mess. Six of Nightmare's earlier bugs, RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma, picked up patches in this week's Patch Tuesday. Microsoft banned the researcher's original GitHub account and reportedly waved legal threats around before backing off after the security community pushed back. The researcher, rumored to be an ex-Microsoft employee, keeps promising more drops while publicly waffling on timing, at one point pledging a dramatic July 14 release and then walking it back, saying RoguePlanet "drained me."

GreatXML fits the pattern: a fast, dramatic announcement with a reproduction story that doesn't hold up cleanly under independent testing. That doesn't make the underlying area uninteresting. WinRE and the recovery partition genuinely deserve scrutiny, and if this episode nudges people to finally verify their recovery image is patched and switch on a pre-boot PIN, the net effect is positive even if the specific exploit fizzles. Measure your own attack surface instead of trusting either the hype or the dismissal, and you'll come out ahead either way.