One day after publishing RoguePlanet, a Windows Defender local privilege escalation zero-day, the researcher known as Nightmare Eclipse (also referred to as Chaotic Eclipse) released a second exploit in a single week: GreatXML, a zero-day that bypasses BitLocker encryption on Windows systems without requiring any login credentials. As with RoguePlanet, the full technical details and proof-of-concept code are publicly available on GitHub. No patch exists.
The disclosure pattern continues a sequence that began three months ago. Nightmare Eclipse has now released multiple zero-day exploits in consecutive months, timed to coincide with or immediately follow Microsoft’s Patch Tuesday cycle, as a stated protest against what the researcher describes as Microsoft’s failure to respond appropriately to responsible disclosure.
How GreatXML bypasses BitLocker
The exploit targets an interaction between the Windows Recovery Environment (WinRE) and an unattend.xml configuration file used during Windows Defender Offline Scan operations.
Windows Defender Offline Scan is a built-in security feature that runs a malware scan outside the normal Windows session by rebooting into a minimal recovery environment. When this feature is triggered, the operating system writes configuration artefacts to the recovery partition, including an unattend.xml answer file that automates behaviour in the recovery session.
The GreatXML exploit works by placing a maliciously crafted unattend.xml file, along with a Recovery directory, on the recovery partition of a target machine that has previously had Defender Offline Scan initiated. When the machine reboots into WinRE, the recovery environment processes the attacker’s configuration file instead of the expected system configuration, and the result is an unrestricted shell against the BitLocker-encrypted volume.
Critically, this does not require the attacker to know the BitLocker PIN or recovery key. The WinRE boot sequence, influenced by the GreatXML configuration file, bypasses the normal authentication step entirely. The attacker obtains full read and write access to the contents of the encrypted volume.
The vulnerability has a specific precondition: the target machine must have had Defender Offline Scan initiated at least once at any point in its history. However, because Defender Offline Scan is a standard response to many malware detection alerts and is triggered automatically in some managed security configurations, this precondition will be met on a large proportion of enterprise endpoints.
TPM-only BitLocker increases exposure
The exploit is most reliably triggered on systems using TPM-only BitLocker protection, meaning systems where BitLocker unlocks automatically at boot without requiring a user PIN or USB key. TPM-only is the default BitLocker configuration in enterprise deployments managed through Microsoft Intune and most Group Policy configurations, because it provides encryption at rest without requiring user interaction at boot time.
On systems where BitLocker is configured to require a pre-boot PIN, the WinRE boot sequence still requires PIN entry, which limits the exploit’s effectiveness depending on how the recovery environment handles that requirement.
The consistent implication is that organisations using the default TPM-only BitLocker configuration, which describes the majority of enterprise Windows deployments, are fully exposed to GreatXML on any machine that has previously run Defender Offline Scan.
The broader context: a researcher in conflict with Microsoft
GreatXML and RoguePlanet, published a day apart, follow the same pattern as the researcher’s earlier disclosures. Nightmare Eclipse has stated publicly that this approach will continue until Microsoft addresses their vulnerability reports through its normal coordinated disclosure process. Microsoft has not confirmed a timeline for addressing GreatXML.
The security community’s response has been divided. Some researchers have pointed out that the disclosures are creating unnecessary risk for organisations that rely on BitLocker for data protection. Others have noted that the researcher’s previous coordinated disclosures did not produce timely patches, and that public disclosure may be the only lever available. Regardless of where the responsibility lies, the operational effect on organisations is the same: a working exploit for a BitLocker bypass is publicly available and no patch is scheduled.
What this means for organisations using BitLocker
BitLocker is the standard disk encryption solution for Windows-based workstations and servers across European enterprise environments. It protects data at rest, which matters most in scenarios involving device theft, physical access attacks, and decommissioning without secure erasure.
GreatXML reduces that protection to nothing on affected machines. An attacker with brief physical access to a machine, the ability to boot from a USB device or access the recovery partition, and knowledge of the GreatXML technique can read the full contents of a BitLocker-encrypted drive without any credentials.
For organisations with remote or field workers whose laptops represent the primary BitLocker use case, this is a significant development. It is also relevant for on-premise server infrastructure where BitLocker is used to protect data volumes and for build servers or CI/CD agents where an attacker who bypasses disk encryption gains access to stored secrets, signing certificates, and deployment credentials.
Immediate steps while awaiting a patch
Audit BitLocker configuration across your Windows estate. Identify which machines are using TPM-only protection and which are configured with a pre-boot PIN. The PIN configuration does not fully close the GreatXML attack vector but it does add friction and may limit the most opportunistic exploitation scenarios.
Review whether Defender Offline Scan has been triggered on high-value machines. Endpoint management platforms that log Defender activity can identify which devices have this historical condition. Prioritise physical access controls for those machines.
Assess physical access risk for your endpoint estate. GreatXML requires physical access to the machine or the ability to interact with its recovery partition. Devices in locked facilities or data centres with access controls are lower risk than field laptops or machines in shared office environments.
Monitor for Microsoft advisories. Given the public availability of exploit code for two zero-days in three days, an out-of-band advisory is possible, though Microsoft has not confirmed one.
If your organisation needs an assessment of BitLocker configuration across its Windows estate, a review of pre-boot authentication policy, or guidance on mitigating the GreatXML risk in the absence of a patch, contact Excello Digital. We work with European organisations to audit endpoint encryption posture and design compensating controls for unpatched vulnerabilities in Windows infrastructure.