GreatXML: How a WinRE Answer File Breaks BitLocker

What Is GreatXML?

On June 10, 2026, independent security researcher NightmareEclipse (GitHub: @MSNightmare) publicly disclosed a zero-day technique dubbed GreatXML. The technique enables an attacker with brief physical access to any BitLocker-encrypted Windows 10 or Windows 11 machine to obtain a SYSTEM-level shell and read the fully-encrypted OS volume — without knowing the password, BitLocker recovery key, or PIN.

The PoC is live on GitHub and has been mirrored to multiple independent hosting platforms, placing this within reach of any opportunistic attacker who can touch a laptop.

Root Cause: Trusted Processing in Pre-Boot

The flaw lives in how Windows Defender Offline Scan and the Windows Recovery Environment interact. When a Defender Offline Scan is triggered (MpCmdRun.exe -Scan -ScanType 3), the machine reboots into WinRE to perform the scan in a pre-OS environment. On boot, WinRE processes an unattend.xml answer file from the recovery partition if one is present.

Here is the critical finding: this processing runs with SYSTEM privileges before any user authentication gate and after the TPM has already unlocked the BitLocker volume. An attacker who places a malicious unattend.xml on the recovery partition can abuse this trusted execution path to spawn an administrator shell with full read/write access to the encrypted OS volume.

The attack is confirmed on Windows 11 24H2 (build 10.0.26100.1). Post-exploitation, manage-bde -status C: reports Protection Status: On — encryption appears active to any monitoring tool, yet the volume is fully accessible. This is the exact scenario the PoC demonstrates.

The Attack Chain

Two Exploitation Paths

GreatXML has two distinct exploitation paths depending on whether the target machine has previously had a Defender Offline Scan run.

MITRE ATT&CK Mapping

Detection Queries — Elastic SIEM / KQL

All queries target Sysmon process events (windows.sysmon_operational) and Elastic Endpoint events (endpoint.events.process). Sysmon configuration must include process creation (EID 1), file creation (EID 11), and registry modification (EID 13) to ensure coverage. Deploy Queries 1 and 3 as persistent detection rules first — they are the highest-fidelity and lowest-FP starting points.

event.dataset: ("endpoint.events.process" OR "windows.sysmon_operational")
AND event.action: "start"
AND process.name: "reagentc.exe"
AND process.command_line: (*"/boottore"* OR *"/setreimage"* OR *"/enable"* OR *"/disable"*)
| sort @timestamp desc

event.dataset: ("endpoint.events.process" OR "windows.sysmon_operational")
AND event.action: "start"
AND process.name: "bcdedit.exe"
AND process.command_line: (
    *"winre"* OR *"recovery"*
    OR *"ramdisksdidevice"* OR *"ramdisksdipath"*
    OR *"{current}"*
)
| sort @timestamp desc

event.dataset: "windows.sysmon_operational"
AND event.action: "creation"
AND winlog.event_id: 11
AND file.name: "unattend.xml"
AND NOT file.path: (
    *"C:\\Windows\\System32\\sysprep\\"*
    OR *"C:\\Windows\\Panther\\"*
    OR *"C:\\Windows\\Setup\\"*
)
| sort @timestamp desc

event.dataset: "windows.sysmon_operational"
AND event.action: "creation"
AND winlog.event_id: 11
AND (
    file.path: (*"\\Recovery\\"* OR *"\\Recovery\\WindowsRE\\"*)
    OR file.name: ("ReAgent.xml" OR "winre.wim" OR "boot.sdi")
)
AND NOT process.name: ("TrustedInstaller.exe" OR "TiWorker.exe" OR "svchost.exe")
| sort @timestamp desc

event.dataset: ("endpoint.events.process" OR "windows.sysmon_operational")
AND event.action: "start"
AND process.name: "manage-bde.exe"
AND process.command_line: (
    *"-status"* OR *"-protectors"*
    OR *"-on"* OR *"-off"* OR *"-unlock"*
)
| sort @timestamp desc

event.dataset: ("endpoint.events.process" OR "windows.sysmon_operational")
AND event.action: "start"
AND process.name: "MpCmdRun.exe"
AND process.command_line: (
    *"-Scan -ScanType 3"*
    OR *"OfflineScan"*
    OR *"-BootSectorScan"*
)
| sort @timestamp desc

// Step 1 — Identify machines where MpCmdRun offline scan ran in last 90 days
event.dataset: "endpoint.events.process"
AND process.name: "MpCmdRun.exe"
AND process.command_line: *"ScanType 3"*
| stats min(@timestamp) as first_offline_scan by host.name
| where first_offline_scan > now() - 90d

// Step 2 — Cross-reference with reagentc or bcdedit activity on those hosts
// Run separately; pivot on host.name results from Step 1
event.dataset: "endpoint.events.process"
AND process.name: ("reagentc.exe" OR "bcdedit.exe")
AND host.name: ("")
| sort @timestamp desc

False Positive Analysis

Indicators of Compromise

GreatXML has no network-based IOCs — it is a local, physical-access technique. Detection relies entirely on file system artifacts and process execution events.

Mitigations

# Disable WinRE — removes the attack surface for GreatXML
# Run as Administrator; verify your recovery workflow supports WinRE-off state
reagentc /disable

# Confirm WinRE is disabled
reagentc /info
# Expected output: "Windows RE status: Disabled"

# Optional: check BitLocker protector type (TPM-only = highest risk)
manage-bde -protectors -get C:
# If output shows "TPM" with no PIN, consider migrating to TPM + PIN for high-risk assets

Priority Actions

1. Identify immediately-exploitable machines (Path 1): Run Q6 across your SIEM to find all endpoints where MpCmdRun.exe -ScanType 3 has been executed. These machines can be exploited by physical access with no login required.
2. Deploy detection rules Q1 and Q3 immediately: reagentc.exe /boottore and unattend.xml at non-deployment paths are the highest-fidelity, lowest-FP indicators for this attack. These should be persistent alert rules, not hunt queries.
3. Disable WinRE on high-risk endpoints: Executive laptops, finance, legal, and M&A machines should be prioritised. Use reagentc /disable after confirming recovery workflow impact.
4. Do not communicate TPM-only as a sufficient control: Any stakeholder communication that presents BitLocker as protective against physical-access scenarios must be updated. TPM-only is explicitly ineffective here.
5. Monitor for GreatXML patch release: Microsoft has not issued a GreatXML-specific patch. Track the MSRC advisory and apply immediately on release. Reference CVE-2026-45585 and CVE-2026-50507 for related updates.

Intelligence Gaps

• Windows Server impact not confirmed in PoC — architecture is identical to workstation WinRE; assumed vulnerable. Server endpoints with BitLocker and Defender installed should be treated as at-risk pending Microsoft confirmation.
• TPM+PIN mitigation unconfirmed — adding a PIN may prevent automatic boot into the WinRE bypass state but has not been confirmed by Microsoft as a full mitigation for GreatXML. Do not present it as a definitive fix.
• No attribution to active threat campaigns at time of disclosure — PoC is available but no confirmed in-the-wild exploitation has been reported. Opportunistic exploitation risk is high given low barrier (physical access only).
• PoC mirroring — the PoC has been mirrored to independent repositories beyond the original GitHub, increasing long-term availability even if the original is taken down.

References

• GitHub — MSNightmare/GreatXML (original PoC)
• CVE-2026-50507 — Microsoft Security Update Guide
• YellowKey — HiveSecurity Blog (related bypass, same researcher)
• MITRE ATT&CK — T1006: Direct Volume Access
• MITRE ATT&CK — T1542.001: Pre-OS Boot: System Firmware