A few days ago we wrote about YellowKey, the newest entry in what has become a remarkably long list of BitLocker bypasses. That article walked through one specific attack with a practical workflow. This follow-up steps back and surveys the broader landscape: where BitLocker has been broken before, where it is still broken today, and what an investigator should expect to encounter on a seized Windows machine in 2026.

We tried to keep it deliberately high-level. There are no step-by-step workflows here; the goal is to give field investigators, case officers, and forensic specialists enough context to recognise the attack class, judge whether it applies to the device in front of them, and know where to look for more details. For a much deeper rabbit hole, the single best starting point is Rairii’s curated catalogue at github.com/Wack0/bitlocker-attacks, which tracks the boot-manager bug pipeline more thoroughly than any vendor write-up.

One framing point that affects roughly half the attacks below: most of the boot-manager bugs Microsoft has patched since 2022 are technically fixed in current Windows builds, but the patches can be bypassed by booting an older, still-validly-signed bootloader. The fix for this – revoking the Microsoft Windows Production PCA 2011 certificate via DBX (Microsoft’s KB5025885 mitigation 3) – has not yet been mass-enforced as of May 2026, with the certificate itself only expiring in October 2026. Until that revocation lands on a given device, “patched” should be read as “patched on this image, but still reachable via downgrade.”

We have grouped the attacks by what the investigator has to bring to the table: pure software, specialised hardware on the TPM bus, a DMA-capable port, a powered-on or recently-powered machine, or compromised credentials. Each group answers a different question for an investigator.

The newest entry in this catalogue, and the reason we are writing the overview, is YellowKey. It belongs in the software and boot-chain family alongside bitpixie and BitUnlocker: pure software, no special hardware, and TPM-agnostic – the bug sits inside the Windows Recovery Environment rather than in the boot manager or the TPM stack, so dTPM, fTPM, and Pluton platforms are equally exposed because none of them are in the loop. The operational bar is unusually low even by the standards of that family: a USB flash drive carrying a handful of files plus a specific key sequence at the right boot prompt is the entire toolkit, with no PXE server, WinPE rig, or boot manager swap involved. In our view that makes YellowKey the most accessible currently-active BitLocker bypass on the public record. The structural mitigation, Microsoft’s Trusted WIM Boot – which hashes WinRE.wim against a known-trusted value and refuses to auto-unlock the OS volume on mismatch – is enforced on some recent OEM images but is not the default across most of the fielded install base, which is why YellowKey fails on a some laptops and works on the others. Notably, as the attack lives inside WinRE rather than requiring a downgrade to an older signed bootloader, the eventual PCA 2011 DBX enforcement we discuss below will not retire YellowKey – only broader Trusted WIM Boot rollout will.

1. Software and boot-chain attacks

These attacks need only physical access to the device and a USB stick (or a PXE server). No soldering, no oscilloscopes, no chip-off. They are by far the easiest and the most relevant class against default Windows 11 “Device Encryption” because that default is TPM-only – the TPM releases the Volume Master Key (VMK) to whatever bootloader the firmware will accept, and these attacks abuse exactly that handover.

bitpixie and BitUnlocker (the downgrade family)

• What it targets and why it works: Both attacks exploit Windows boot manager and recovery flows that leak or release the VMK before the OS finishes locking it down. bitpixie abuses a bootmgr code path that hands the key to a network-boot-style flow; BitUnlocker abuses the Windows Recovery Environment’s handling of WIM/SDI ramdisk offsets. Both require the attacker to load an older, still-signed bootloader (which Secure Boot currently still accepts) to reach the vulnerable code paths.
• Date: bitpixie disclosed February 2023 (full chain demoed at 38C3, December 2024); BitUnlocker disclosed at Black Hat USA, July 2025.
• Links: github.com/martanne/bitpixie; github.com/Mr1Stark/bitunlocker; SySS analysis
• Difficulty: Low to medium – public PoCs exist with documentation.
• Requirements: Physical access plus a USB or PXE boot, around five minutes per device. No special hardware. Works on fully patched Windows 11 TPM-only as long as the firmware’s Secure Boot DB still trusts the PCA 2011 certificate, which on most fielded machines it does.
• Still active? Yes – this is an active attack against default Windows 11 in 2026.

CVEs: CVE-2023-21563 (bitpixie), CVE-2025-48804 and adjacent (BitUnlocker). Once Microsoft enforces the PCA 2011 DBX revocation and the firmware no longer accepts old bootloaders, this entire family dies. Investigators encountering a recent Win11 machine should treat these as the default-applicable attack and check the boot manager certificate (sigcheck bootmgfw.efi) only to confirm.

RAM Leak

This is the freshest of them, published days after YellowKey was released.

• What it targets and why it works: The Windows boot manager can build a ramdisk from a file named in the BCD, and it never checks which device that file comes from — so a BitLocker-encrypted partition is fair game, provided the keys get derived during the boot sequence. Rairii’s trick reuses the bitpixie setup (a crafted default entry plus a recovery sequence) to force key derivation for the OS volume, then aims the ramdisk at a file on that now-readable partition. The file contents stay resident in RAM even after the derived keys are wiped, so they can be dumped afterward; as a side effect, the same mechanism reveals whether a given file exists on the encrypted volume.
• Date: Published May 2026; discovered March 2025. The underlying flaw is far older – the vulnerable ramdisk code traces back to pre-BCD boot manager builds from 2005, meaning it has existed for essentially the entire lifetime of BitLocker.
• Links: github.com/Wack0/bitlocker-attacks#ram-leak (proof-of-concept ramleak.zip included in the repository).
• Difficulty: Low to medium – comparable to bitpixie, with public PoC and documentation.
• Requirements: Physical access plus a USB boot; bcdeditmod to craft the BCD entries. The author’s preferred memory-dump method loads an older signed winload and so currently rides the PCA 2011 downgrade path, but alternative dump routes (PXE soft-reboot into another OS, WinPE bugcheck) do not all depend on it. Defeated by PIN+TPM, since the keys cannot be derived without the PIN and there is nothing to leak.
• Still active? Yes – and notably, MSRC closed the report as low priority (the author attributes this to a misunderstanding around Secure Boot) and is not fixing it. Unlike the rest of the boot-chain family, this one will not be retired by a patch.

RAM Leak does not hand over the VMK directly (it hands over a file) but the files it can reach are exactly the ones that matter: hiberfil.sys (which carries derived BitLocker keys, is compressed enough to fit in RAM, and is freshly written when a user “shuts down” from the logon screen, since that is really logoff-then-hibernate), the pagefile, and the SYSTEM and SAM hives. In practice it is a cleaner, more reliable route to the same outcome CrashXTS pursues, and the author credits Maxim Suhanov’s CrashXTS write-up as the inspiration. Its real significance for this overview is durability: because the PCA 2011 DBX revocation will eventually neutralise bitpixie, BitUnlocker, and the rest of section 1, RAM Leak – unpatched by Microsoft’s own decision – stands out as the boot-chain attack most likely to still be working after that cutoff. One caveat on framing: Rairii explicitly declines to call this a “backdoor,” and in the same breath pushes back on the label being applied to YellowKey, on the grounds that loading a ramdisk from an encrypted partition is a deliberate boot-environment feature rather than a flaw.

Other boot-manager and WinRE bugs (Rairii catalogue)

• What it targets and why it works: A series of distinct bugs in the Windows boot manager and Recovery Environment that let an attacker either skip BitLocker validation entirely or coerce the system into a state where the VMK is exposed. Names in this family include dubious disk, dangerous association, break-out-in-hives, and the WinRE “push-button decrypt” issue. The mechanism varies (legacy integrity checks, hive parsing, systemdatadevice handling) but the outcome is the same: BitLocker is bypassed without cryptography.
• Date: 2022 through 2025; rolling disclosures.
• Links: wack0.github.io/dubiousdisk; SCRT push-button decrypt write-up; full list in the Wack0 repo.
• Difficulty: Low to medium per bug.
• Requirements: Physical access; in some cases an unpatched WinRE image is enough, in others an attacker-supplied older signed bootloader.
• Still active? Patched on current builds, but reachable on machines with un-replaced WinRE images or via the same PCA 2011 downgrade trick described above.

CVEs span CVE-2022-29127, CVE-2022-30203, CVE-2022-41099, CVE-2023-21560, CVE-2024-20666, CVE-2024-38065, CVE-2025-21213, and others. Microsoft’s own patches do not always update WinRE on the existing recovery partition, so reagentc /info output matters here. For a forensic angle, expect to find machines in the field still vulnerable years after the CVE was assigned.

BlackLotus (UEFI bootkit, “Baton Drop”)

• What it targets and why it works: BlackLotus is a UEFI bootkit that exploits CVE-2022-21894 (and the related CVE-2023-24932) to run before Windows starts, giving the operator persistence below the OS and the ability to disable BitLocker. It is not a forensic tool per se but a piece of crimeware that has been sold on hacking forums since at least October 2022.
• Date: ESET disclosure, March 2023.
• Link: ESET WeLiveSecurity write-up
• Difficulty: High to deploy from scratch; low if purchased.
• Requirements: Physical or privileged remote access; a Windows install whose Secure Boot DB still trusts PCA 2011.
• Still active? Patched in current builds; same downgrade caveat applies.

From an investigator’s standpoint BlackLotus matters less as an offensive option than as a thing you might find on a seized machine. The forensic indicators (modified bootmgfw.efi, suspicious EFI binaries) are well documented by ESET and by the NSA’s mitigation guidance.

CrashXTS

• What it targets and why it works: A 2025 attack that exploits a randomisation weakness in BitLocker’s XTS-AES tweak handling combined with write access to the SYSTEM registry hive’s CrashControl values, coercing Windows to write an unencrypted hibernation file. Once the hiberfile is plaintext, the FVEK falls out of memory analysis trivially.
• Date: January 2025.
• Link: Maxim Suhanov write-up
• Difficulty: Medium-high.
• Requirements: Pre-boot write access to the system volume (so typically combined with one of the boot-manager attacks above) plus a hibernation event.
• Still active? Patched as CVE-2025-21210.

CrashXTS is a good example of a chain rather than a standalone – it gives you a plaintext hiberfile, but you still need a way in to set up the conditions. Worth knowing about because the resulting forensic artefact (a plaintext hiberfil.sys on a machine the user thought was encrypted) is distinctive.

Shift+F10 during Windows upgrade

• What it targets and why it works: A trick disclosed by Sami Laiho in November 2016: pressing Shift+F10 during a Windows feature-update brought up a command prompt running as SYSTEM, with the BitLocker-protected volume temporarily unlocked. It was not a code bug so much as a workflow oversight.
• Date: November 2016.
• Link: BleepingComputer coverage
• Difficulty: Trivially low.
• Requirements: Physical access during a feature update.
• Still active? No – mitigated via DisableCMDRequest.tag and changes to the modern in-place upgrade path.

Included here for historical reasons and as a reminder that some of the worst BitLocker bypasses have been operational rather than cryptographic. The same logic underlies the next entry.

Suspended BitLocker / Clear Key state

• What it targets and why it works: When BitLocker is suspended – for example by manage-bde -disable or automatically during a feature update – Windows writes a plaintext “Clear Key” protector into the volume metadata so the machine can boot without prompting. Reading the volume header during that window is enough to decrypt the disk; no cryptography or exploit required.
• Date: Long-standing; documented behaviour, not a bug.
• Link: Microsoft Learn documentation on manage-bde.
• Difficulty: Low.
• Requirements: Physical access while the volume is suspended; the window closes after the next successful boot.
• Still active? Yes – this is by design and there is no plan to change it.

For investigators this is a state to actively look for: a powered-off laptop whose owner suspended BitLocker before shutting down (intentionally or not) is decryptable directly from the on-disk metadata. Several of the boot-manager exploits above ultimately end in this state. Where the device is mid-upgrade or has an interrupted servicing operation, check first.

2. Hardware attacks on the TPM

These attacks bypass the software entirely and go after the TPM itself – either by listening to the bus it talks on (discrete TPMs), glitching the silicon that hosts it (firmware TPMs), or attacking the protocol stack around it. They need bench equipment and varying amounts of soldering or fixture work, but they are unpatchable on already-shipped hardware, which is what makes them durable.

TPM bus sniffing (LPC and SPI); discrete TPM only

• What it targets and why it works: On a discrete TPM, the chip releases the VMK across the bus to the CPU in cleartext during normal boot. An attacker who clips onto the bus (LPC on older systems, SPI on most current ones) captures the bytes and reconstructs the VMK. The TPM is doing exactly what it was designed to do; the weakness is the unauthenticated bus.
• Date: Andzakovic / Pulse Security, January 2019 (LPC); Henri Nurmi / WithSecure, December 2020 (SPI); stacksmashing’s Pi-Pico variant, February 2024; Compass Security’s Lenovo T470 demo, February 2024.
• Links: Pulse Security; WithSecure Labs; pico-tpmsniffer; Compass Security.
• Difficulty: Medium – the soldering or pogo-pin work is the bulk of the effort; the decoding is now well-supported by open tools.
• Requirements: A discrete TPM (this excludes Pluton and most fTPM platforms); a logic analyser, Saleae/DSLogic, or a sub-$10 Raspberry Pi Pico; bench time for fixturing. The stacksmashing demo on a Lenovo ThinkPad recovered the VMK in 43 seconds once the fixture was in place.
• Still active? Yes, and unpatchable on shipped silicon. Affects the majority of enterprise laptops sold between roughly 2016 and 2023.

This is the canonical hardware attack on BitLocker and the one any forensic lab serious about Windows decryption should have on the bench. TPM+PIN defeats it (the TPM does not release the key without the PIN), as do Pluton and most fTPM platforms – but currently a significant fraction of fielded enterprise hardware uses discrete TPMs in default configuration. Note that I²C variants (and Jeremy Boone’s TPM Genie interposer concept from CanSecWest 2018, github.com/nccgroup/TPMGenie) extend the same idea to other buses.

faulTPM (AMD firmware TPM / fTPM)

• What it targets and why it works: A voltage-glitching attack against AMD’s firmware TPM (the one implemented inside the Platform Security Processor on Zen 2 and Zen 3 CPUs). The TU Berlin team showed that glitching the PSP at the right moment leaks a chip-unique secret, from which the fTPM’s sealed keys – including any BitLocker VMK – can be derived offline.
• Date: April 2023 (arXiv:2304.14717).
• Link: github.com/PSPReverse/ftpm_attack
• Difficulty: High – reverse-engineering plus glitching expertise.
• Requirements: ChipWhisperer-class equipment plus an SPI programmer; the paper quotes total hardware cost under USD 200, with most of that going to test probes. Affects AMD Zen 2 and Zen 3 fTPMs specifically.
• Still active? Yes and unpatchable on the affected silicon. Intel’s CSME/PTT received its equivalent CC2021-era mitigations and is not in scope.

faulTPM is the answer to “what do we do once everyone moves to firmware TPMs?”, at least on the AMD side. The hardware cost is low enough that a moderately funded lab can build the rig; the skill cost is the real barrier. TPM+PIN raises the post-extraction work to “hours of GPU brute force on the PIN” rather than blocking the attack outright, because once the chip-unique secret is out, the anti-hammering protection is also out.

BitLeaker (S3 TPM reset)

• What it targets and why it works: Seunghun Han’s 2018 work showed that on vulnerable firmware, putting the machine into S3 sleep and resetting the TPM’s Platform Configuration Registers across resume let an attacker re-derive the VMK from a custom Linux environment. The flaw was in how firmware handled the TPM state across the sleep transition.
• Date: USENIX 2018 / Black Hat EU 2019.
• Links: github.com/kkamagui/bitleaker; napper-for-tpm to check exposure.
• Difficulty: Medium.
• Requirements: A vulnerable UEFI on a discrete TPM (CVE-2018-6622) or Intel PTT (CVE-2020-0526); a Linux USB boot.
• Still active? Largely fixed by 2021–2022 firmware updates; check residual exposure with napper before assuming.

Worth mentioning because firmware patch coverage is genuinely uneven across OEMs and older devices in the field may still be exposed. The Napper tool is the easy way to triage. Modern hardware on shipping firmware is generally not affected.

TPM-Fail

• What it targets and why it works: A cryptographic timing side-channel in certain TPM ECDSA implementations – Intel’s fTPM and STMicroelectronics’ Common Criteria-certified discrete TPM – that allowed key recovery from observable signing-time variation. Not BitLocker-specific but it undermines the trust model BitLocker depends on.
• Date: CHES 2020.
• Link: tpm.fail
• Difficulty: High – cryptographic side-channel work.
• Requirements: The ability to request many signatures from the target TPM and measure timing precisely.
• Still active? Patched on affected vendors (CVE-2019-11090, CVE-2019-16863).

Of mostly academic interest to field investigators in 2026, but historically significant because it was the first widely-publicised demonstration that even CC EAL4+-certified TPMs could be broken cryptographically rather than physically. Worth knowing about when reading older threat models.

3. DMA and physical-port attacks

These attacks pull keys out of RAM via a port that gives direct memory access – Thunderbolt, ExpressCard, PCIe, or the CPU’s debug interface. They generally require the target machine to be logged in or at least running, and they are mitigated on modern hardware by Kernel DMA Protection (Windows 10 1803 and later with VT-d enabled).

PCILeech / MemProcFS

• What it targets and why it works: Ulf Frisk’s PCILeech turns a cheap PCIe development board into a DMA-capable peripheral that can read and write arbitrary host memory while the machine is running. MemProcFS exposes the resulting memory as a filesystem, and dedicated plugins extract the BitLocker FVEK directly from kernel pools.
• Date: 2016 onwards, actively maintained.
• Links: github.com/ufrisk/pcileech; MemProcFS; Synacktiv M.2 DMA write-up.
• Difficulty: Medium.
• Requirements: A USB3380 development board, PCIeScreamer, or similar – under USD 200; a target machine that is running and has Kernel DMA Protection off (every pre-2019 system and a meaningful chunk of newer ones with VT-d disabled in firmware); a PCIe slot, M.2 slot, or Thunderbolt port to attach to.
• Still active? Yes against unprotected machines.

PCILeech is the workhorse of DMA forensics and the reason “is the machine still running?” is usually the most important question at scene. Once VT-d and Kernel DMA Protection are both enabled, the attack surface shrinks dramatically; Synacktiv’s M.2 write-up shows that internal slots are sometimes overlooked even when external ports are protected. Microsoft’s msinfo32 reports “Kernel DMA Protection: ON” if the mitigation is active.

Thunderspy

• What it targets and why it works: Björn Ruytenberg’s 2020 research demonstrated that Thunderbolt 1, 2, and 3 controllers from 2011 to 2019 have firmware-level flaws that allow Security Level downgrade and arbitrary peripheral attachment, including in locked-state. Combined with DMA tooling, this gives memory access to a locked machine if Kernel DMA Protection is absent.
• Date: Disclosed May 2020.
• Link: thunderspy.io (includes the Spycheck tool).
• Difficulty: Medium-high – requires reflashing the Thunderbolt controller via SPI.
• Requirements: A Bus Pirate or equivalent SPI flasher, Thunderbolt host hardware, brief physical access to open the chassis.
• Still active? Yes on the affected hardware generations, which is most Thunderbolt-equipped laptops sold before 2019. Not fixable in firmware – requires silicon redesign.

Thunderspy is best treated as a precondition for PCILeech-class memory acquisition on locked targets that lack Kernel DMA Protection. Spycheck on the suspect machine confirms exposure quickly. Newer Thunderbolt 4 controllers and machines with Kernel DMA Protection on are out of scope.

DCILeech (Intel Direct Connect Interface)

• What it targets and why it works: Modern Intel CPUs (Skylake / 6th generation and later) ship with a debug interface – DCI – accessible over a modified USB 3.0 A-to-A cable. On firmware where DCI can be enabled, the resulting access yields arbitrary memory read, and from there the BitLocker keys come out of RAM. The 2023 DFRWS Europe paper from the Brazilian Federal Police demonstrated this against a 7th-generation Intel laptop running Windows 11 Pro.
• Date: DFRWS USA 2021 (original Latzo et al. work); DFRWS Europe 2023 (Bichara de Assumpção et al., BitLocker-specific demonstration).
• Links: DFRWS 2021 paper; DFRWS Europe 2023.
• Difficulty: High – vendor tooling (Intel System Debugger / OpenIPC) plus firmware know-how.
• Requirements: Skylake or newer Intel CPU; firmware that allows DCI enable; a modified USB 3.0 A-to-A cable (approximately USD 10); the PCR7 measurement must not have been extended before DCI activation.
• Still active? Yes where firmware permits DCI to be enabled and the PCR7 timing condition holds.

This is the most “law-enforcement-friendly” of the DMA attacks because it requires no soldering and no opening of the chassis once DCI is reachable from BIOS, but the OEM firmware lottery – some lock DCI down hard, some do not – determines whether any given seized device is in scope. The 2023 Brazilian Federal Police paper is the most directly applicable reference. Carsten Maartmann-Moe’s older Inception tool (github.com/carmaa/inception) is essentially historical at this point.

4. Memory and live-state attacks

These attacks need a machine that is powered on, sleeping, or recently powered off – they pull keys out of RAM or out of the hibernation/page files. The takeaway for investigators is operational: do not power down a running suspect machine until you have considered live acquisition.

Cold-boot attacks

• What it targets and why it works: The original Princeton work from 2008 (“Lest We Remember”) and F-Secure’s 2018 update both rely on DRAM retaining its contents for seconds to minutes after power-off, especially if cooled. Cold-booting the machine into an attacker-controlled OS reads the previous OS’s memory, including the BitLocker VMK.
• Date: Princeton – USENIX Security 2008; F-Secure – September 2018.
• Links: Princeton CITP; F-Secure write-up.
• Difficulty: Medium.
• Requirements: Physical access to a running or recently-running machine; some cooling spray helps on modern DRAM; ability to boot a custom OS quickly.
• Still active? Partial. Gruhn and Müller showed in 2013 that DDR3 mitigates much of the original window; Microsoft has since added warm-boot key wiping post-Windows 10. The F-Secure 2.0 variant still works against many laptops left in S3 sleep.

For field investigators, the practical implication is that a laptop seized in sleep state is a meaningfully better target than one that has been off for an hour. The Princeton attack is mostly of historical and procedural interest now, but the F-Secure 2.0 method against sleeping laptops without firmware overwrite still has operational value on many fielded systems.

Hibernation file and memory image extraction

• What it targets and why it works: If a BitLocker volume was mounted when the machine hibernated, the FVEK is sitting inside the compressed hiberfil.sys. The same is true of any captured RAM image. Volatility’s BitLocker plugins and Elcomsoft Forensic Disk Decryptor scan for the well-known FVEc and Cngb pool tags and output the FVEK plus tweak in a format that mounts directly.
• Date: Volatility plugins from 2015 onwards (Tribal Chicken, Marcin Ulikowski’s elceef/bitlocker, Romain Coltel’s Volatility-BitLocker, Lorelyai’s Volatility 3 port); EFDD commercial since the early 2010s, current build 2.21.
• Links: as above; EFDD at elcomsoft.com/efdd.html.
• Difficulty: Low to medium – tool-driven.
• Requirements: A memory image or a hiberfil.sys from a machine that had BitLocker mounted at the time of capture. Pagefile leakage applies similarly when pagefile encryption is off.
• Still active? Yes – works from Windows 7 through current Windows 11.

This is the bread-and-butter approach for any forensic team with live acquisition capability. Combined with CrashXTS (above), even a forced-unencrypted hibernation file becomes a reliable extraction path on vulnerable builds. The main operational requirement is recognising the opportunity before powering the device down.

5. Password and key recovery

This category is what people picture when they hear “cracking BitLocker”, and it is mostly a dead end against strong recovery keys but a real option against weak user passwords.

EFDD + EDPR

• What it targets and why it works: one can use Elcomsoft Forensic Disk Decryptor to extract the volume header, and Elcomsoft Distributed Password Recovery to actually attack the password. hashcat can be used for similar purposes, albeit it’s a more cumbersome product to use.
• Date: Current.
• Links: Elcomsoft Forensic Disk Decryptor, Elcomsoft Distributed Password Recovery.
• Difficulty: Low to medium.
• Requirements: A copy of the volume header; modern GPU for any serious work. Realistic rates: roughly 3,000 passwords per second on an old NVIDIA GeForce RTX 3090 board, significantly more on modern variants. Realistically, this means that dictionary plus rules is the only practical approach against user passwords.
• Still active? Yes for user-password protectors; effectively never for recovery keys via pure brute force.

Some important nuances. First, you can only recover user-selectable passwords (no TPM), not recovery keys. A BitLocker recovery key is 48 decimal digits with 128 bits of true entropy distributed via Microsoft’s multiply-by-11 encoding – brute-forcing the full key is infeasible (around 10²⁸ GPU-years). Second, the frequently-repeated GitHub claim that the last group of a BitLocker recovery key is a checksum of the others is not supported by Microsoft’s own published documentation, and tools that rely on that assumption should be treated with caution. Finally, you will likely not require a separate license for Elcomsoft Forensic Disk Decryptor as a lite version is included with Elcomsoft Distributed Password Recovery specifically for the purpose of extracting such hashes.

Microsoft Account / Entra ID escrow extraction

• What it targets and why it works: Since Windows 8.1, “Device Encryption” automatically uploads the BitLocker recovery key to the user’s Microsoft account (OneDrive) or, on Entra-joined devices, to Entra ID. An attacker who compromises the user’s MSA, or who holds a tenant Global Administrator, Cloud Device Administrator, Helpdesk Administrator, or – easily overlooked – Global Reader role, can retrieve every recovery key in scope. This bypasses BitLocker entirely and trivially.
• Date: Behaviour first documented by Micah Lee in The Intercept, December 2015; still current.
• Link: Microsoft Learn documentation on microsoft.directory/bitlockerKeys/key/read.
• Difficulty: Variable – depends entirely on the escrow target.
• Requirements: Either control of the user’s Microsoft account, or any of the four Entra roles that hold the BitLocker key-read permission by default.
• Still active? Yes – this is by design, not a bug. No CVE.

For investigators with appropriate legal authority, this is operationally the easiest path on any consumer Windows install (Device Encryption is on by default and uploads on first MSA sign-in with no opt-out before upload) and on any Entra-joined corporate fleet where the requisite role can be exercised under warrant or with cooperation. The matching defensive concern, which is the other side of the same coin, is that any tenant compromise of the right role exposes every device’s recovery key at once.

6. Configuration and protocol weaknesses

Network Unlock

• What it targets and why it works: BitLocker Network Unlock uses a Windows Deployment Services (WDS) server and DHCP to release the VMK over the wire to a TPM-equipped client, using an RSA-2048 unlock-server certificate and a 256-bit session key (MS-NKPU). Compromise of the WDS server’s unlock-server private key compromises every device that uses it; extending physical L2 connectivity to a stolen laptop reproduces a valid unlock environment.
• Date: Documented protocol behaviour, no specific CVE.
• Link: Microsoft Learn documentation on BitLocker Network Unlock; MS-NKPU specification.
• Difficulty: Variable.
• Requirements: Access to the WDS server or its key material; or the ability to reproduce L2 connectivity for a stolen target.
• Still active? Yes by design – there is no published CVE because the attack surface is the deployment, not the protocol.

Microsoft itself explicitly declines to support Network Unlock over Wi-Fi (MitM and spoofing risk) and refuses to increase retry counts (replay risk), which says something about how robust the protocol is treated as being. Published attack research is thin, but absence of CVEs here probably reflects low real-world deployment rather than security strength. Treat any environment that uses it as a high-value target for the WDS server itself.

Where this leaves things in mid-2026

Two structural shifts will reshape this landscape within the next year or so, and either of them changes which attacks above remain interesting. The first is Microsoft’s enforcement of PCA 2011 DBX revocation under KB5025885, which has been “under evaluation” for over a year and which the underlying certificate expiry in October 2026 will eventually force. When that lands at fleet scale, every downgrade-reachable attack in section 1 – bitpixie, BitUnlocker, the Rairii bootmgr family, BlackLotus – stops working. The second is the gradual migration away from discrete TPMs to Pluton and fTPM platforms, which closes the bus-sniffing attack surface but does not address faulTPM-class hardware attacks on the silicon that hosts the fTPM.

The single configuration change that defeats almost everything above is enabling TPM+PIN pre-boot authentication. It defeats bitpixie and BitUnlocker (the TPM does not release the VMK without the PIN), defeats bus sniffing for the same reason, defeats DMA-from-locked-state, defeats S3 TPM-reset, and substantially raises the bar against faulTPM (forcing GPU brute force on the PIN rather than direct key recovery). It does nothing for already-running machines or for escrow extraction. Microsoft’s own threat model assumes physical access is out of scope for default TPM-only Device Encryption, which is a useful thing for investigators to keep in mind when framing what the encryption actually promises.

We have skipped the per-attack comparison tables for this overview, since a brief listing serves the “what should I be aware of” use case better. If there is interest, a separate addendum collecting CVEs, hardware costs, and difficulty ratings into a single comparison table is straightforward to produce – let us know in the comments.

Wrap-up: who’s extractable in May 2026

TPM-only, any vendor, any generation: Effectively extractable across the board. The software boot-chain family – bitpixie, BitUnlocker, YellowKey, the rest of section 1 – does not care which TPM is fitted because the TPM has already legitimately released the VMK by the time the attack catches it. As long as the firmware still trusts the PCA 2011 certificate (which on the vast majority of fielded consumer machines it still does in May 2026), a USB stick and roughly five minutes is enough. Everything from Intel 6th gen onwards and every AMD Zen generation, from 2015-era hardware to a brand-new 2026 desktop, falls in scope. The only TPM-only configurations not extractable today are very recent OEM Windows 11 24H2 installs that happen to ship with both Trusted WIM Boot enabled in WinRE and PCA 2011 already DBX-revoked – a tiny minority of the install base.

PIN+TPM, Intel PTT, any generation: Practically a wall. The PIN defeats the entire software toolchain; PTT has no exposed bus to sniff; faulTPM is AMD-only. The residual surface is DCILeech on older firmware that still lets the DCI menu be enabled, live memory acquisition if the machine is seized powered on or sleeping, and account escrow if the user’s MSA or Entra credentials are lawfully obtainable. Outside those specific conditions, an Intel PTT machine in PIN+TPM is not realistically decryptable with publicly known techniques.

PIN+TPM, AMD Zen 2 and Zen 3 (roughly 2019 through early 2022): Still extractable, but only with serious lab capability. faulTPM pulls the chip-unique secret regardless of the PIN, after which the PIN itself is brute-forced offline with no anti-hammering left to slow it down. Hardware cost is under USD 200; the real cost is skill – reverse engineering plus voltage glitching is not bench work for a typical forensic unit. Some national labs and specialised providers can do it; most cannot.

PIN+TPM, AMD Zen 4 and later (2022 onwards): No public attack. The TU Berlin work is explicitly scoped to Zen 2 and Zen 3, and later AMD PSP generations have not been publicly demonstrated to fall to the same technique. That is not the same thing as “proven safe” – absence of a public exploit is not evidence of absence – but operationally, in May 2026, an investigator facing a Ryzen 7000 or 9000 system in PIN+TPM with a strong PIN has nothing in the public toolbox.

Does BitLocker still make sense, or is it time to leave?

The honest answer is “yes, but probably not the way it is configured on most machines.” BitLocker in TPM-only mode, which is the consumer default and what Device Encryption ships with on essentially every Home and Pro install, is close to decorative against any informed attacker in 2026. That is not a cryptographic problem; AES-XTS is fine. It is a key-release problem, and Microsoft’s own threat model has always said exactly that: physical access is explicitly out of scope for TPM-only. The user community has just never internalised the line.

BitLocker in PIN+TPM mode on modern hardware tells a very different story. On Intel PTT at any generation, or AMD Zen 4 and later, the configuration defeats the entire boot-chain family, defeats bus sniffing where applicable, defeats S3 reset, raises the bar against faulTPM-class attacks where the PIN entropy is decent, and leaves only the residual categories (live memory capture, account escrow, and the long tail of low-volume hardware attacks) for an attacker to chase. The operational cost is one extra prompt at boot. Against the same threat model there is no realistic alternative scheme that does materially better.

VeraCrypt and similar are the obvious flight options and they are credible: pre-boot password authentication, no TPM dependency, no Microsoft escrow path. But they trade one set of problems for another: no clean integration with Windows update or reset flows, manual recovery key management, no Pluton support on machines that have it, and the same physical-access weaknesses (cold boot, DMA, hibernation file leaks) that hit BitLocker hit them just as hard. For users with a serious nation-state threat model and the discipline to manage the operational overhead, the swap can be the right call. For everyone else, which is most of the install base, the rational move is not to flee BitLocker but to configure it the way it was always meant to be configured: PIN+TPM, hibernation off or to an encrypted volume, Kernel DMA Protection on, and a sober understanding that the recovery key sitting in the user’s Microsoft account is the soft underbelly nobody likes to discuss.