GreatXML Bypasses BitLocker Through a Trusted Recovery Path

Another week, another bypass that exploits the seams between Windows' own components.

A researcher going by Chaotic Eclipse — also seen as Nightmare-Eclipse and MSNightmare — has dropped a BitLocker bypass technique they're calling GreatXML. The release came roughly a day after the same researcher posted a separate Microsoft Defender exploit. By their own account it was an accidental find, about four hours of poking at Windows Defender Offline Scan before something gave.

The ingredient list is mundane: XML configuration files that live in the recovery partition. That's the point. The recovery partition is treated as trusted by design, because the bootloader needs to read something before BitLocker unlocks the OS volume. Anything parsed in that pre-boot or recovery context becomes a candidate attack surface, and XML parsers have a long, embarrassing history.

The failure mode here is familiar to anyone who's looked at secure boot research over the past few years. BitLocker's security model assumes the recovery environment is integrity-protected. If an attacker with physical access — or a prior foothold sufficient to write to the recovery partition — can modify XML that gets consumed by a trusted component, you've essentially smuggled instructions across the encryption boundary. The disk math is still correct. The trust math is wrong.

In practice, this is a physical-access or evil-maid scenario, not a remote unauthenticated RCE. That matters for triage. But it also matters for anyone shipping laptops to field staff, anyone running shared kiosks, and any incident responder who assumed "BitLocker was on" closed the lost-device ticket.

Microsoft has not, at time of writing, published an advisory tied to this technique, and no CVE has been assigned that I can verify. Treat the researcher's writeup as proof-of-concept disclosure rather than a patched issue. The Defender bypass from the day prior suggests this is part of a small series rather than a one-off, so expect more.

A few things worth doing now if you manage Windows fleets at scale:

• Audit which machines actually have TPM+PIN versus TPM-only BitLocker. TPM-only is the configuration most exposed to recovery-partition trickery.
• Confirm your MDM or Intune policy is enforcing pre-boot authentication on devices that leave the building.
• Treat lost or stolen encrypted laptops as potentially compromised until Microsoft publishes guidance, not as resolved tickets.
• Watch MSRC for an advisory and a likely servicing-stack or WinRE update.

The broader lesson is the one the post-mortem will say out loud eventually: full-disk encryption protects bytes at rest, not the boot-time code path that decides whether to hand you the keys.

Operational takeaway: if your threat model includes physical access, TPM-only BitLocker is not a control — it's a checkbox.