If you extract data from iPhones for a living, Stolen Device Protection is the change you can no longer afford to ignore. It does something deceptively simple: it puts Face ID or Touch ID in front of the “Trust This Computer” prompt. The practical result is that an examiner who knows the device passcode still cannot pair an unfamiliar iPhone to a forensic workstation. That is the most disruptive change Apple has made to iPhone pairing behavior in roughly a decade, and as of spring 2026 it is switched on out of the box.

This article walks through what the feature is, how it has changed over time, what it is designed to stop, and – the part that matters most for a lab – exactly which steps of a data extraction it gets in the way of. We are also in the process of finalizing our own solution for circumventing Stolen Device Protection that will allow sideloading and using the extraction agent with protection still engaged.

What Stolen Device Protection actually is

Stolen Device Protection (SDP) is a per-device security feature for iPhone. When it is on, iOS imposes extra authentication on a defined set of sensitive actions, but only when the phone is away from a familiar location. “Familiar” here means a Significant Location the phone has learned on its own, typically home and work. Sit the phone on the suspect’s kitchen table and most of SDP relaxes; bring it into your lab and it does not.

Two separate mechanisms do the work, and it is worth keeping them apart:

• Biometric-only authentication, with no passcode fallback. For one group of actions, iOS will accept Face ID or Touch ID and nothing else. The passcode is not an option. Apple’s own wording is that these actions need biometrics “with no passcode alternative or fallback.”
• The Security Delay. For a second group – mostly account and security settings – iOS asks for a biometric, then makes you wait one hour, then asks for a second biometric. At a familiar location during that hour the wait can end early; the optional Require Security Delay > Always setting won’t shorten the delay even at home and work.

To enable SDP (or to have it enabled by iOS in recent builds; see below for details), the user needs two-factor authentication on their Apple Account, a passcode, Face ID or Touch ID enrolled, Significant Locations switched on, and Find My enabled. Once SDP is on, Find My can’t be turned off.

Importantly, SDP is iPhone-only. As of iPadOS 26.4 Apple has not extended it to iPad, even though an iPad is just as exposed to the same passcode-theft scenario. If the device on your bench is an iPad, you can set SDP aside entirely.

As for whether the feature is opt-in or opt-out – that has changed, and the change is recent. Today, on current iOS, treat SDP as on by default. More on that in the next section.

A short history and why it matters for your backlog

SDP is a moving target, and an examiner has to be precise about which version is on the bench. Here is the timeline:

The headline is the bottom of the table. From iOS 17.3 through 26.3, SDP was opt-in: the user had to find it in Settings and switch it on, and most people never did. With iOS 26.4, Apple flipped that. Per Apple’s enterprise documentation, SDP is now automatically enabled on devices set up new with iOS 26.4 or later, on devices restored on 26.4 or later, and on devices that update from 26.4 to a later build. One honest caveat worth carrying: on a brand-new setup the user does see an SDP screen, and Apple’s consumer-facing article hedges with “might be turned on by default.” The cleaner read is that updates and restores enable it without asking, while a fresh out-of-box setup presents it prominently. Either way, the examiner can no longer assume it is off.

Why does a version history belong in a forensic article? Because a lab backlog is never one version of iOS. It is a drawer of devices spanning years of releases, and the same physical iPhone behaves differently depending on the build it is running. That gives you a triage rule you can apply the moment a device is logged in:

• Pre-iOS 17.3 – SDP does not exist. Standard pairing applies: passcode plus the Trust prompt is enough to create a new pairing record.
• iOS 17.3 through 18.x – SDP exists but is opt-in. Most devices won’t have it on, but some will, especially those belonging to security-conscious owners. Check Settings → Face ID & Passcode before you plan anything.
• iOS 26.4 and later – assume SDP is on until you have proof otherwise.

Document the exact build (Settings → General → About) and the SDP state in your case notes before the first extraction step.

What SDP is meant to stop

SDP was built for one very specific threat model, and knowing that helps you reason about where it does and doesn’t get in your way.

The feature is Apple’s answer to a theft pattern that The Wall Street Journal documented in early 2023: thieves were watching iPhone owners type their passcodes in bars and other public places, then stealing the phone. The passcode alone was the whole heist. With it, a thief could change the Apple Account password from Settings, lock the real owner out of iCloud, disable Find My, harvest every credential in iCloud Keychain, move money through Apple Cash, and walk into banking apps whose logins were saved in Keychain. We had a whole article on the issue back when SDP was still in beta; check out the “What could happen if someone stole an iPhone and knows its passcode?” section in iOS 17.3 Developer Preview: Stolen Device Protection. A later WSJ follow-up profiled one Minneapolis thief who described taking roughly $300,000 from victims this way. Apple announced SDP the same week.

So the threat model is explicit and narrow: an attacker who has both the physical device and the passcode. Everything SDP does is aimed at making that combination far less useful than it used to be.

The flip side is just as important for an examiner. SDP changes nothing for an attacker who has only one of the two factors, and it changes nothing for extraction methods that never touch on-device flows in the first place – for instance, bootrom-level acquisition on legacy hardware, which is a function of the chip, not of iOS policy. SDP is an iOS-level lock on iOS-level actions. Where your method sits below that layer, SDP is simply not part of the conversation.

What SDP blocks during extraction

Apple’s documentation is written for end users, and it does not enumerate every system-level interaction an examiner cares about – so some of what follows rests on independent testing rather than Apple’s published list. Where that is the case, we flag it plainly.

Pairing the device to a new computer

This is the major roadblock. With SDP on and the device away from a familiar location, the “Trust This Computer” handshake requires Face ID or Touch ID. The passcode is no longer a sufficient credential to confirm trust. Independent forensic testing has confirmed this behavior, and it is the single most consequential effect of SDP, because creating a fresh pairing (lockdown) record is the first step of advanced logical acquisition. Notably, Apple does not list pairing among the SDP-protected actions in its support documentation, yet the behavior is real and reproducible. In a consent-absent case – suspect in custody and not cooperating, or owner unavailable – an examiner who knows the passcode still cannot establish a new pairing on a workstation. The owner’s biometrics are required, full stop.

Using a pairing record you already have

This is the realistic way around the gate, with one caveat: pairing records have a limited lifetime, and they still require unlocking the iPhone (because of USB Restricted Mode blocking USB data communications). Now, if you have a valid, non-expired lockdown/pairing record and you can unlock the phone with a passcode, you can connect it to your workstation without requiring biometric authentication (per SDP).

In other words, SDP raises the bar for creating a new pairing; there is no public testing showing it invalidates a valid, pre-existing one. The device itself must be in AFU (After-First-Unlock) state, that is, it has been unlocked at least once since its last reboot. The device must not be allowed to reboot into BFU (Before-First-Unlock) state.

Sideloading and signing an extraction agent

The code-signing itself happens on the host, and SDP does not touch host-side operations. But the agent still has to be installed onto the iPhone over USB, and that requires a working pairing and trust relationship. So SDP sits upstream of agent-based extraction: block the pairing, and the agent never reaches the device.

Account-side actions: Apple Account password and sign-out

Both are behind the Security Delay. If your plan involves iCloud-side acquisition and you need to reset the account password, you cannot do it from the seized device without the owner’s biometrics – twice, an hour apart. And while SDP is on, the same changes are blocked on the web at account.apple.com too, so there is no browser shortcut. Where cloud acquisition is the goal, plan to obtain credentials and any second factor through lawful process, not through an on-device password reset.

Turning off SDP itself (and turning off Find My)

This sits behind the Security Delay. An examiner cannot simply switch SDP off, even with the passcode, when the device is away from a familiar location. The owner has to start the change, authenticate biometrically, wait the hour, and authenticate again – and if they have chosen the “Always” setting, going to their home or workplace won’t shorten that wait.

Reset All Settings (removes unknown local backup password, of one is enabled)

This also sits behind the Security Delay. As stated, the forensic value of this function is that, among other things (such as removing the device’s passcode) it also clears the password for encrypting local iTunes/Finder style backups.

The rest of the list

Several other actions are biometric-only with no passcode fallback when SDP is on and the device is away from home: turning off “Lost Mode”, viewing or using passwords and passkeys in the Keychain, payment methods saved in Safari AutoFill, “Erase All Content and Settings,” opening Locked or Hidden apps (iOS 18 and later), Quick Start to set up another device, and setting up or transferring an eSIM. Some of these show up in real cases: Keychain access matters because the non-consensual on-device path to bulk password harvesting is now closed; Quick Start matters because it blocks a clone-device technique; eSIM transfer matters for SIM-related seizures. Worth knowing they exist so nothing surprises you mid-extraction.

The bottom line is this: without the owner’s biometrics, advanced logical extraction is effectively blocked on an SDP-enabled iPhone that is not at a familiar location – even when you know the passcode and even when the device is sitting in AFU state. A known passcode used to be the key. Under SDP, away from frequent locations, it no longer works the way it used to.

What this means in practice

A short, practical checklist for the lab:

• Triage every iPhone by iOS version on receipt. Pre-17.3 has no SDP exposure; 17.3 through 18.x needs a settings check; 26.4 and later should be assumed SDP-on. Record the exact build and the SDP state before touching the device.
• Seize host computers in parallel. Image the suspect’s Mac or PC at the same time as the iPhone and preserve the lockdown directory. A valid pre-existing pairing record is the most reliable way past the SDP pairing gate – and with a short record lifetime, you’ll have to act fast.
• Protect AFU state. Don’t let a seized phone reboot or power down. Faraday containment with pass-through power, and a documented chain of custody for the power state.
• For consensual cases, arrange the SDP toggle in advance. Ask a cooperating owner to either switch SDP off or to bring the device to its “known” location so the Security Delay is suppressed. Document the change and the location context as it happens. Note that if the protection is set to “Always”, you will still have to budget for a one-hour delay.
• Plan around the one-hour delay when there is no other path. If the only route is turning SDP off at the lab with a cooperating user, budget for it: biometric, one-hour wait, second biometric, then the extraction itself.

A note on the documentation gap

The most consequential thing SDP does to a forensic workflow (gating computer pairing behind biometrics) is the one thing Apple has not written down. That gap is not a reason to doubt the behavior; it is reproducible and well attested. It is a reason to be careful about how you describe it. Cite the empirical record, keep your own test notes current on a device matching the build under examination, and don’t lean on Apple’s support article to carry a point it doesn’t actually make. Treat all of this as accurate for a moment in time. Apple revises SDP quietly, and the relevant support pages have already been edited more than once. Validate the behavior on a representative test device before you rely on any of it in a specific case.

Pulling a backup out of iCloud is one of the more technically demanding jobs in cloud forensics. An iCloud backup is not a single, ready-to-download file; instead, it is assembled from a large number of separate fragments that have to be collected and stitched back together into a coherent backup. Recent changes to Apple’s communication protocols broke things for everyone except Apple themselves, meaning that we had to rework the underlying extraction logic. This is documented in Elcomsoft Phone Breaker 11 Restores iCloud Access.

Recent changes to Apple’s communication protocols and to the format of certain server responses meant that logic had to be substantially reworked. The first pass in version 11.0 had teething issues: backups could stop partway through, often after only the first few gigabytes. Version 11.1 applies the final fixes. Backups that previously stalled now download completely, and the reconstruction step produces a consistent backup you can actually work with – but only if the backup was made by a device running iOS or iPadOS 18 or lower. Cloud backups produced by iOS or iPadOS 26 are not supported just yet. Support for them is coming in a follow-up release.

Background: what EPB 11 changed

Apple’s sweeping changes to authentication and encryption had blocked the methods Elcomsoft Phone Breaker previously relied on. EPB 11.0 rebuilt iCloud extraction from the ground up in response. That release restored downloads of iCloud Drive files and synchronized data, but it also flagged unresolved issues that could interrupt backup extraction partway through. Version 11.1 is the follow-up that addresses those issues directly – the cloud extraction overhaul is now complete.

Why forensic specialists need iCloud backups at all

Cloud backups are often the only realistic route to critical evidence. When a suspect’s device is missing, locked, wiped, stolen or physically broken – and there is no hardware unlock on the table – the iCloud account may be the only thing left to work with. A backup sitting in the cloud does not care about the state of the phone.

There is usually more there than a single backup, too. One Apple ID often holds backups for several devices – an old iPhone, a current iPhone, an iPad – and all of them are reachable from the same account. It is worth checking what the account actually contains before assuming there is just one target.

For each device, iCloud typically keeps two backups: the most recent one and the one before it. The older backup is easy to overlook, but it can be the more useful of the two. It may predate an app uninstall or a deliberate cleanup, which means it can still hold data the latest backup no longer does. Treating the most recent backup as the only one that matters is a common way to miss evidence.

Finally, the cloud route stays open even when the device is locked down hard. If a phone is sitting behind Stolen Device Protection and cannot be unlocked in hardware, the iCloud account is still a way in: with the account credentials, you can pull the backup from the cloud. It will not be as complete as a full device extraction – synced and end-to-end encrypted categories stay out of it – but a partial backup is still a great deal better than no evidence at all.

Local vs. iCloud backups: what’s actually inside

It helps to be clear about what each backup type does and does not contain, because they are not interchangeable. The table below compares the four cases an examiner runs into. ✓ means the category is present and usable; ✗ means it is not in that backup; conditional notes are spelled out inline. Local backups with and without a password are somewhat different in both their content and accessibility of different content types. The content of iCloud backups, on the other hand, depends on whether the user has Advanced Data Protection for iCloud enabled; the table below has it under “iCloud backup with ADP”.

The short version: an encrypted local backup with a known password is the richest single source after low-level extraction, an iCloud backup is the fallback when the device is out of reach, and an iCloud account under Advanced Data Protection puts the backup itself end-to-end encrypted. Worth noting too that an iCloud backup is a complement to iCloud sync, not a copy of the whole device – anything actively syncing (Photos, Drive, Messages in iCloud and so on) usually lives in its own container and has to be acquired separately from the backup. For local backups, developers control whether their apps are allowed to back up with isExcludedFromBackup, while users can additionally exclude select apps specifically from iCloud backups.

A note on location data. The table is a starting point, not a guarantee – the photo-related rows in particular deserve a closer look. Even when iCloud Photos is switched on, so the photo library itself lives in its own container rather than in the backup, an iCloud backup can still carry photo metadata. In one of our test accounts, a small iCloud backup of around 500 MB held only about 80 actual photos, yet close to 20,000 location records – virtually all of them tied to photos, and stamped with timestamps. The metadata syncs even when the images largely do not. So treat an iCloud backup as something that may contain geolocation data rather than something that definitely does or definitely doesn’t: even where the full-resolution photos are absent, image previews or thumbnails can survive in the backup. It is worth checking on every case rather than assuming either way.

Working with the downloaded backup

Once the backup is on your machine, its origin barely matters. A local backup, encrypted or not (provided that you do know the password), and an iCloud backup land in the same format and call for the same approach, so nothing below changes depending on where the data came from.

The quickest route is the Decrypt backup feature in Elcomsoft Phone Breaker. Point it at the backup, tick the option that converts file names into readable form, and run it. Within minutes you get the actual media files plus all the databases (most of them SQLite) from both system and third-party apps: contacts, call logs, SMS, WhatsApp chats and so on. It’s fast enough to treat as triage: a quick look at what’s there before you commit to a deeper pass.

For a proper analysis you’ll want a dedicated forensic tool. Magnet AXIOM is a solid choice; it combines fast processing, reasonably deep parsing and a workable interface in one package. That stage is measured in hours rather than minutes, but it’s where the full picture comes together.

Bottom line

Backup extraction is fixed for all versions of iOS/iPadOS before 26. The interruptions that could cut a download short are gone, the reconstruction step produces a consistent result, and iCloud backups again come down in full for supported versions of iOS. If a stalled backup was holding up your work, update to Elcomsoft Phone Breaker 11.1 and download it again.

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.

On May 12, 2026, a researcher operating under the handles Chaotic Eclipse and Nightmare-Eclipse dropped a working proof-of-concept on GitHub for a Windows zero-day called YellowKey. In short, it lets anyone with brief physical access to a BitLocker-protected Windows 11, Windows Server 2022, or Windows Server 2025 machine pop a command prompt with full read access to the encrypted volume. No password. No recovery key. No TPM sniffing rig. A USB stick and a key combination during reboot.

The security press picked it up immediately. The hacking community ran with it. The forensic community, oddly, has barely shrugged. That is a mistake. If you have a seized BitLocker-protected laptop sitting in the evidence room that has so far been written off as cold evidence, this disclosure should be on your desk this week, not next quarter. As of writing, Microsoft has not shipped a patch, and the researcher is openly promising more disclosures around the next Patch Tuesday. The window of opportunity is wide open right now.

This article walks through what BitLocker actually protects, how YellowKey breaks that model, how forensic examiners can take advantage of the bug, and what the researcher’s additional claim about TPM+PIN configurations might really mean.

A Quick Refresher: BitLocker and Device Encryption

BitLocker is Microsoft’s full-volume encryption feature. It uses AES (XTS by default on modern installs) to encrypt the contents of the drive with a Full Volume Encryption Key, which is itself wrapped by a Volume Master Key (VMK). The VMK is what every protector ultimately unlocks: a password, a recovery key, a smart card, a USB key file, or the TPM (alone, or combined with a PIN, a startup key, or both).

What changes the forensic calculus on modern Windows is not the classic, manually configured BitLocker that admins enable on enterprise laptops. It is Device Encryption, the silent, automatic variant Microsoft enables on any reasonably modern hardware that meets the requirements, on any Windows edition including Home. The user does not have to ask for it. They do not have to know it exists. If the device shipped with Windows 11 and the user signed in with a Microsoft Account, the system drive is almost certainly encrypted.

The recovery key, in that scenario, is uploaded to the first admin-level Microsoft Account that signs in on that device. If the user knows nothing about encryption, they certainly know nothing about the recovery key. If they later switch to a local account, change their Microsoft Account, or simply have no idea which Outlook/Hotmail address was used during setup, the key is for practical purposes gone, from their perspective.

This silent rollout has been a long-standing thorn in the side of the data recovery community. Customers walk in with a laptop with a dead motherboard, no idea their drive was encrypted, and no recovery key. Recovery is impossible. YellowKey does not solve every variant of that problem, but for any case where the original encrypted drive can be returned to working hardware running an affected Windows version, the equation has fundamentally shifted.

How TPM Protection Was Supposed to Work

To appreciate what YellowKey actually breaks, it is worth recapping the trust model. For a deeper insight, our 2021 article Understanding BitLocker TPM Protection remains accurate on the fundamentals. The short version follows.

In the default TPM-only configuration (which is what Device Encryption uses out of the box), the Volume Master Key (VMK) is sealed inside the TPM against a set of Platform Configuration Registers (PCRs). During boot, each stage measures the next and extends those PCRs: firmware measures the bootloader, the bootloader measures the OS loader, and so on, building a chain of trust. If the chain matches the values present when BitLocker was provisioned, the TPM releases the VMK to the boot manager. If anything in the chain has been tampered with, the TPM refuses, and the user gets a Recovery Key prompt.

This is the part that matters for YellowKey: when the chain of trust passes, the VMK is released automatically, with no user interaction. The whole point of Device Encryption is that the legitimate owner never sees a prompt. The TPM hands over the key, Windows mounts the encrypted volume, and life goes on. The implicit assumption is that nothing inside the trusted boot chain itself can be subverted to expose the volume to an unauthorized party.

TPM+PIN, which we will come back to later, changes one thing: the TPM additionally requires a correct PIN to be entered before it will release the VMK. The chain of trust still matters, but the user must also authenticate. It is the standard recommendation for any device that handles sensitive data, and it is what most threat models assume defenders to be using when they take BitLocker seriously.

The YellowKey Exploit

What It Is

YellowKey is a bug in the Windows Recovery Environment (WinRE) that allows an attacker to drop into an unrestricted command prompt with the BitLocker-protected system volume already unlocked and accessible. The flaw lives in a component present only inside the WinRE image; the researcher notes that the same component, by name, also exists in a normal Windows installation, but without the specific functionality that triggers the bypass. That asymmetry is what makes the discovery feel less like an accident and more like something that was put there on purpose. Whether that framing is correct is something we will speculate on at the end.

The affected platforms are Windows 11 and Windows Server 2022/2025. Windows 10 is currently unaffected. Multiple independent researchers, including Will Dormann (Tharros Labs) and Kevin Beaumont, have publicly confirmed that the published PoC works as advertised against the default TPM-only configuration.

How It Works, Without the Gory Bits

The exploit abuses a code path inside WinRE that scans attached storage for NTFS transaction log data under a specific folder, System Volume Information\FsTx, and replays whatever it finds. The interesting part, flagged by Will Dormann, is that the replay can modify content on a different volume than the one the logs came from. By preparing the right log content, an attacker can use a USB stick (or, alternatively, files written directly to the device’s EFI System Partition) to make WinRE rewrite parts of its own recovery image during early boot.

The net effect of the documented PoC is that winpeshl.ini inside the WinRE image is removed. winpeshl.ini is what normally tells WinRE to launch the recovery UI; without it, WinRE falls back to spawning cmd.exe directly. A specific key sequence held during boot triggers the path. The shell that lands on screen has access to the BitLocker-protected system volume because, by the time WinRE is entered through the legitimate recovery path, the TPM has already released the VMK to the boot chain in the normal way. Nothing about the chain of trust has been violated from the TPM’s point of view. The recovery environment is supposed to have legitimate access to the volume for repair tasks. The bug is in how trivially that access can be redirected into a free-for-all shell.

We have intentionally kept it conceptual. The published repository contains everything needed to weaponize the bug, and several independent confirmations exist. We are not going to recap the byte-level details here; this is a forensics blog, not a tutorial for the other side.

Using YellowKey in a Forensic Workflow

Translated for an examiner with a seized device on the bench, the procedure breaks into three phases: rebooting into the Windows Recovery Environment, dropping into an unrestricted shell, and extracting the BitLocker recovery key. A few pre-flight notes first.

First, the procedure modifies the device. The FsTx replay changes content inside the WinRE image, and once winpeshl.ini has been deleted on the recovery partition, the device is no longer in its original state. Image the drive first with a hardware write blocker or with a tool such as Elcomsoft System Recovery, and document hash values before and after. The exploit operates on the running hardware, but having a clean forensic image in hand means any later challenge to the chain of custody can be answered with the pre-exploit image as a reference.

Second, confirm the target is in scope. Windows 10 is currently not affected. Verify the operating system version on the seized device before planning around YellowKey. Server 2022 and Server 2025 are in scope alongside Windows 11.

Third, the procedure is finicky. The key-press timing in particular is unforgiving, and independent testers have noted that it often takes several attempts to land cleanly. Beyond timing, the exploit also does not work on every in-scope device – see the caveat at the end of this section about Trusted WIM Boot. Plan for retries and for a non-trivial false-negative rate.

Phase 1: Rebooting into the Windows Recovery Environment

Prepare a USB stick with the published FsTx folder placed at the correct path inside System Volume Information, and connect it to the seized machine before initiating reboot. How you get to WinRE then depends on the state of the device.

If the device is locked but already authenticated – for example, it was seized while powered on, asleep, or hibernated, and the lock screen is displayed – the fastest path is the Shift-plus-Restart trick. From the lock screen, click the power button in the bottom-right corner, hold Shift, and click Restart. The device reboots directly into WinRE. This is enabled on most consumer Windows installations by default. It can be blocked in enterprise environments where Group Policy hides the power options from the lock screen (most commonly via the “Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands” policy), in Assigned Access or kiosk configurations, on devices managed via Intune or another MDM where the administrator has disabled the on-screen power button, or anywhere a local policy has hidden it manually. If the power button is missing from the lock screen, or if Shift-plus-Restart still goes through a normal reboot rather than into Recovery, fall back to the cold method below.

If the device is fully powered off – the default state for anything that has been sitting in the evidence room for any length of time – force WinRE entry by triggering Windows’s automatic repair flow. Microsoft documents the procedure in its Windows recovery environment article: power the device on, then hold the power button to force a hard shutdown before Windows finishes loading. Do this twice. On the third power-on, Windows recognizes the previous failed boot attempts and brings up the Recovery Environment automatically. This path is reliable but not forensically neutral – the forced shutdowns alter the boot counter in BCD, write unclean-shutdown entries to the event log, and on rare occasions can cause filesystem inconsistencies. Hash before and after and document the procedure exactly as performed.

Phase 2: Getting into the Shell

The moment WinRE entry is triggered by either method, release any other keys and immediately press and hold the Ctrl key. Do not release it. Keep Ctrl held down until a command prompt window appears. If the timing lands correctly, the shell that spawns has direct read access to the BitLocker-protected system volume.

The key-press window is narrow. Multiple testers have reported that landing cleanly takes several attempts, so do not give up after a single failed try. Each retry means going back through Phase 1, which on a cold device involves another sequence of interrupted boots – slow, but the process works.

One important caveat: the exploit does not succeed on every device in the affected version range. Microsoft has had a mechanism called Trusted WIM Boot in place since BitLocker recovery support was added to WinRE. The mechanism stores a hash of the WinRE.wim image inside the BitLocker FVE metadata block, which is itself integrity-protected via AES-CCM, and verifies the hash during recovery boot. When YellowKey’s FsTx replay modifies content within the WinRE image, that hash check is supposed to fail, in which case the OS volume remains locked and the dropped shell has no access to encrypted data. Whether Trusted WIM Boot actually triggers depends on whether the device’s BitLocker metadata contains the expected WIM hash entry in the first place. According to a community researcher’s analysis posted in discussion of the exploit, the metadata on a substantial share of laptops in the wild – roughly half, by their estimate – does not include the WIM hash, meaning YellowKey works against those devices but fails against the rest. That estimate has not been independently validated, but the underlying mechanism is real and documented by Microsoft. Treat this as a hit-rate problem rather than a hard gate: attempt the procedure on every in-scope seized device, but expect that on a meaningful fraction of them the shell will land without access to the encrypted volume, and plan accordingly.

Phase 3: Extracting the Recovery Key with manage-bde

Once the shell is live and the BitLocker volume is accessible, the practical move is not to simply read files off the volume, but to extract material that lets you decrypt the original forensic image offline. Use manage-bde from the cmd prompt to enumerate the protectors on the volume and to read out the recovery information.

Note that in WinRE, drive letters get reassigned because WinRE itself runs on X:. The OS volume is often C: but may land as D: or another letter depending on partition layout. So the sequence is:

manage-bde -status

Review the output and identify which volume shows Protection Status: Protection On and BitLocker Version: 2.0. That is your target drive letter. Then:

manage-bde -protectors -get C:

(substituting whatever letter was identified). Look for the Numerical Password protector in the output. It will appear as a 48-digit key in eight groups of six digits separated by hyphens – that is the BitLocker Recovery Key. Copy it down verbatim; it is usable both as a manual unlock password and as input for Elcomsoft Forensic Disk Decryptor when decrypting the offline image.

One thing to note: the Numerical Password protector is generated and stored when BitLocker is first provisioned, regardless of which primary protector (TPM-only, TPM+PIN, password, etc.) the volume uses. So even on a TPM-only Device Encryption setup where the user never saw a recovery key prompt, the protector is there – it was just silently backed up to their Microsoft Account. Extracting it here gives you a persistent key that survives any subsequent patch or hardware change, which is useful for long-running investigations.

This numeric password is what your workflow downstream actually wants. With that in hand, Elcomsoft Forensic Disk Decryptor can decrypt the original forensic image you captured earlier, or mount it as a virtual drive for live analysis, without ever having to touch the seized hardware again. That is the soundest path: use YellowKey only as the keying primitive, do the actual analysis on the offline image.

The variant that works without any external storage, by writing the same payload to the EFI System Partition on the device’s own drive, is convenient when the device’s USB ports are inconvenient or disabled but generally requires brief removal of the drive, which has its own evidence-handling implications.

Why This Is a Bigger Deal Than the Forensic Community Has Acknowledged

The reason this disclosure deserves more attention than it has been getting is that it dissolves a category of cases that examiners have been writing off for years.

Consider a typical scenario. A laptop is seized as evidence in an investigation. It runs Windows 11. The user account was local, or the Microsoft Account credentials are unknown, or the recovery key was never synced. The BitLocker-protected drive is, on paper, unrecoverable without the user’s cooperation. Until now, the realistic options were: try to coerce or negotiate the recovery key out of the user, hope memory forensics on a still-running device yielded the VMK (impossible on a powered-off seizure), or shelve the device. With YellowKey, the same device, in the same powered-off state, can be processed today.

Device Encryption widens the impact dramatically. The number of consumer laptops out there with BitLocker silently enabled, whose owners do not know it is enabled and whose recovery keys are tied to forgotten Microsoft Accounts, is enormous. Cases involving such devices were a recurring pain point. They are not, for the duration of this vulnerability’s life, anymore.

One more dimension worth flagging: the affected versions. Windows 10 stays untouched, at least for now. Anything Windows 11 or Server 2022/2025 is in play. A quick inventory pass through your evidence room, sorted by OS, is probably a worthwhile afternoon. Seized devices are, by definition, cold – they will not receive any patches while they sit in storage, so an affected device in evidence today will still be affected next year, regardless of what Microsoft ships in the meantime. The window of opportunity applies to future seizures: once a patched build is in widespread deployment, devices acquired from that point onward may no longer be exploitable. For everything already on the shelves, this is not a race against the clock so much as a backlog that has quietly become workable.

A Note on the TPM+PIN Claim

The researcher has stated, in their follow-up blog post, that the bug is also exploitable on devices configured with TPM+PIN, and that they have a working PoC but are withholding it. Their words: “Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I’m just not publishing the PoC, I think what’s out there is already bad enough.”

This claim deserves caution. By design, TPM+PIN requires the user PIN to be entered before the TPM releases the VMK. A stolen laptop, powered off and then booted, should not have the encrypted volume mounted by the time WinRE is reached, because the TPM has nothing to release. The mechanism that makes YellowKey work in the TPM-only case – the volume already being unlocked when WinRE inherits the system – does not obviously apply.

That said, it is worth taking the claim seriously rather than waving it away. The published TPM-only bypass already implies a code path inside WinRE that does not behave the way the public documentation would suggest. If, as the researcher believes, this is a deliberately introduced channel rather than an accidental flaw, there is nothing to stop that channel from including its own access path to the encrypted volume, independent of the user PIN. WinRE legitimately needs to be able to talk to the protected volume for some repair operations, and the exact mechanism by which it does so is not well documented publicly. JaGoTu, who tested the published PoC, noted that TPM+PIN behaviour appeared to depend on the specific WinRE implementation, suggesting that something more is going on than a simple “PIN gates everything.” Until Microsoft reverses the component and explains it, or the researcher releases the second PoC, the honest position is: it is plausible, but not independently confirmed.

So What the Hell Was That, Microsoft?

Stepping back from the procedural stuff, this whole thing deserves a moment of genuine bewilderment.

The researcher’s framing is that YellowKey looks like a backdoor. Not in the conspiratorial sense, necessarily, but in the structural one: the vulnerable component lives only inside the WinRE image. The same component, with the same name, exists inside a normal Windows install, but without the specific functionality that produces the bypass. That is not the shape of a normal bug. Normal bugs are uniform; they exist in code that ships everywhere the code is needed. Functionality that exists in one image and not another, where the difference is precisely the part that produces unauthorized access to encrypted data, is the kind of asymmetry that gets people asking questions.

There are basically two ways to read it. The charitable reading is that this is a legacy maintenance or debug pathway that someone inside Microsoft built years ago for some legitimate repair scenario, never properly gated, and forgot about. The recovery environment is a strange corner of Windows, full of historical accretion, and “we needed to be able to fix things in the field” is a real engineering pressure. That reading lands you at gross negligence: a feature that effectively defeats the entire promise of BitLocker on a default install, sitting in production code for years, undocumented, undetected by internal review.

The less charitable reading is that someone meant it to be there. Whether for internal Microsoft tooling, for cooperation with specific partners, or for reasons that nobody outside the room ever needs to know, an access path was built and quietly kept. Nothing in the public evidence forces this reading over the negligence one, and accusations of intentional backdoors should not be made lightly. But the structural oddity is real, the researcher is not the only one who has noticed it, and Microsoft so far has not offered an explanation.

Either reading is bad news for the BitLocker brand. The whole pitch of TPM-bound encryption is that the user can stop worrying. Drive gets stolen, drive stays scrambled, full stop. That promise underpins a lot of policy: governments standardising on BitLocker for sensitive endpoints, enterprises ticking the compliance box, consumers assuming that the laptop they lost in a taxi will not become a data breach. YellowKey punches a clean hole through that. Not a “with enough specialised equipment and a soldering iron” hole, which sophisticated readers always knew existed for TPM-only setups. A USB-stick-and-a-keyboard-shortcut hole, accessible to anyone who can read a README.

None of this should have happened. A vulnerability of this severity, sitting inside a component whose entire job is to be invoked by an untrusted user during an unauthenticated state, should have been caught by internal review long before it shipped. The fact that it was not – and the further fact that Microsoft’s response to this researcher’s previous disclosures has, by their own account, included silent patches without advisories – is going to do real damage to the assumption that “encrypted by Microsoft” means “safely encrypted.”

For the forensic community, this is a gift, and a temporary one. For Microsoft customers, it is a wake-up call to think harder about whether TPM-only Device Encryption is actually enough for the threat model. For the rest of us, it is yet another reminder that the most consequential vulnerabilities are not usually the clever ones. They are the ones nobody noticed because nobody thought to look.

Over the years, we have published several articles about the extraction agent. However, the underlying technology changes quickly, and incremental changes often have significant cumulative effects. As a result, many of our older posts are no longer relevant and can be misleading if followed to the letter today. While last year’s recap, Installing and Troubleshooting the Extraction Agent (2025), remains a solid foundation for general setup, it does not account for the most recent hardware and software developments. This article serves as the definitive point of reference, providing an up-to-date recap of everything you need to know about the extraction agent as of May 2026.

What is it?

Alongside extended logical extraction, Elcomsoft iOS Forensic Toolkit (EIFT) implements several low-level extraction techniques because low-level extraction remains the gold standard for mobile forensics. Standard logical backups only pull what the operating system explicitly allows, meaning some critical evidence might be left behind. Low-level extraction largely bypasses those restrictions, making it the only reliable method to retrieve sandboxed app data, private chats, deleted records, full messaging histories, and the raw files and databases.

To achieve this on modern Apple hardware, EIFT utilizes the extraction agent. The agent is an in-house app that gets sideloaded directly onto the target device. Once installed, it unlocks low-level system access. It applies OS-level exploits to elevate privileges, escape the iOS sandbox, and ultimately grant direct access to both the root of the file system and the encryption keys required for keychain decryption.

Data Scope and Acquisition Benefits

The primary function of the extraction agent is to facilitate a level of system access that standard protocols such as the Apple File Conduit (AFC) or the backup service are designed to restrict. By operating at a low level, the agent overcomes the inherent data filtering of the iOS environment.

What is Extracted?

Once running with elevated privileges, the agent can acquire raw files and databases that are unavailable through standard logical or advanced logical procedures. In addition, the agent retrieves the encryption keys necessary to decrypt the keychain. The resulting dataset is significantly more comprehensive than a standard backup and includes both the full file system image and a copy of all keychain records, fully decrypted. Examples of extracted data include:

• Sandboxed App Data & Caches: Full databases for both native and third-party applications (including secure messengers), along with their attachments, logs, and configuration files. This also encompasses extensive application and WebKit caches, which frequently expose user activity from embedded in-app browsers.
• Passwords, Tokens, and Encryption Keys: By retrieving the keys necessary to fully decrypt the keychain, the extraction secures stored passwords, authentication tokens, and the specific keys required to decrypt protected application data.
• System & User Activity (KnowledgeC & Biomes): Access to deeply integrated system databases, such as the KnowledgeC and Biome frameworks. These record granular “pattern of life” data, tracking app usage, user interactions, and contextual states (such as Focus Modes) to help construct highly accurate behavioral timelines.
• System Service Logs & Diagnostics: Massive volumes of system-level data, including PowerLog statistics, Spotlight indexes, Health data, and detailed system service activities. This includes Wi-Fi and Bluetooth connection histories, lock/unlock methods, screen orientation changes, power-saving mode triggers, power-saving mode triggers, various notifications, copies of some messages and and a lot of other user and system activities, which collectively often enable the tracing of precise location data.
• Deleted Records & Thumbnails: Access to SQLite WAL (Write-Ahead Log) files, which frequently allows for the recovery of deleted messages and records. Furthermore, the extraction pulls system-level thumbnails that often persist long after the original media files have been deleted by the user.
• Instant Messenger Chats: Complete, un-scrubbed communication histories from secure messaging platforms. This includes full access to Telegram (including Secret Chats), Signal, Apple’s own iMessages, and a host of other messaging apps. While Signal databases are encrypted by design, the extraction agent retrieves the necessary decryption key directly from the keychain, allowing for the complete decryption and analysis of the message database.
• Detailed geolocation history, including significant locations and connections to 5G/LTE/3G cell towers, which allows to build much more detailed and comprehensive timeline with geo data.

Core Benefits

The extraction agent addresses several critical shortcomings of alternative forensic methods. It bypasses logical restrictions, as standard acquisitions are governed by the operating system’s permission model, which intentionally omits sensitive system files and third-party app data. Unlike checkm8, which only covers older chipsets, the agent-based approach works on modern SoCs (with a few notable exceptions that we will detail below). Finally, since our extraction agent implements our own proprietary communication protocol, it’s highly optimized for modern hardware interfaces. By utilizing a direct USB-C connection, it can achieve real-world transfer speeds of up to 200 MB/s, which is especially important when imaging high-capacity devices (512 GB to 2 TB) which would otherwise take hours via slower “stock” protocols.

May 2026: At a Glance

Technical information:

• Supported Devices and OS Versions: The extraction agent supports iPhones with A12 through A18-series chips, as well as iPads with A12 or newer A-series chips and M1 through M4 processors. Firmware support covers iOS and iPadOS 12.0 through 18.7.1, as well as iOS/iPadOS 26.0 and 26.0.1 on compatible devices.
• Major Exceptions: Devices based on A19, A19 Pro, and M5 chips running iOS or iPadOS 26.x are not currently supported due to Apple’s hardware-level Memory Integrity Enforcement.
• Signing Requirements: The extraction agent must be signed with an investigator-controlled Apple ID. The signing account must have a trusted Apple device linked to it to complete the mandatory two-factor authentication prompt.
• Firewall Requirement: Because Apple requires online signature validation when the agent is launched for the first time and our past workaround for non-developer Apple IDs is no longer working, a strictly configured software or hardware firewall is required. This allows the signature check while isolating the evidentiary device from iCloud synchronization, remote wipe commands, and other network activity.

Supported Devices and OS Versions

The compatibility of the extraction agent is defined by the intersection of the device’s SoC and the specific version of the operating system. Currently, the agent supports a broad range of hardware, including iPhones equipped with A12 through A18 series chips and iPads utilizing A-series (A12 and newer) or M-series (M1 through M4) processors. Regarding firmware, support generally spans from iOS 14.0 through 18.7.1. Furthermore, the agent maintains compatibility with iOS 26 and 26.0.1 for devices based on the A13 through A18 Pro chipsets, with the notable exception of the iPhone 17 series. Similarly, iPadOS 26 and 26.0.1 are supported across compatible iPad models, excluding those powered by the M5 chip.

The extraction agent supports the following iPhone models:

Forensic examiners should be aware of a specific operational quirk affecting high-end iPad Pro models, specifically the 1TB and 2TB variants equipped with 16GB of RAM. These devices may exhibit instability when applying the exploit due to significant variations in the active memory layout compared to lower-capacity models. This instability is not a failure of the agent itself but a side effect of the memory architecture. In such cases, if the agent fails to initialize or triggers an unexpected reboot, the recommended procedure is to simply re-attempt the extraction. In practice, the exploit typically succeeds after one or two additional attempts.

A more significant technical challenge is the introduction of hardware-backed Memory Integrity Enforcement (MIE), which debuted with iOS 26 on devices featuring A19, A19 Pro, and M5 processors. This security feature utilizes a mathematically generated 4-bit secret tag assigned to every memory allocation, designed to neutralize exploits such as buffer overflows or use-after-free conditions. On these specific devices (primarily the iPhone 17 series and M5-based iPads) the processor requires a matching tag to access memory. Apple’s implementation of MIE mandates strict synchronous enforcement; any tag mismatch during an exploit attempt triggers an immediate, uninterruptible CPU exception that terminates before privilege escalation can complete.

As of May 2026, MIE represents a roadblock for low-level agent-based extraction on A19 and M5 devices running iOS 26.x. While this hardware-level security effectively prevents current privilege escalation techniques, research into potential bypasses is ongoing. Preliminary laboratory results regarding a potential solution are encouraging, though these developments are currently in the early stages and are not yet ready for shared implementation.

Installation, Signing, and Network Isolation

Deploying the extraction agent requires precise configuration of both the forensic workstation and the network environment. Because Apple mandates that all sideloaded applications be signed to verify code origin, the agent must undergo a strict signing process before execution.

Furthermore, Apple’s security model now requires the operating system to perform an online signature validation check during the app’s first launch. This requirement presents a significant risk in a forensic setting, as an active internet connection could trigger iCloud synchronization or a remote wipe command. To mitigate this risk, the device must be isolated using a strictly configured firewall that whitelists only Apple’s Provisioning Profile Queue and blocks all other traffic.

The Firewall

Isolating the target device during the mandatory online signature validation is a critical step in the extraction process. To achieve this safely, we provide two options: a software-based script designed for macOS, and a hardware-based approach utilizing a Raspberry Pi microcomputer. The following articles are still relevant today:

• Extraction Agent and Firewall: Software vs. Hardware
• Sideloading the Extraction Agent using a Firewall
• Open-Sourcing Raspberry Pi Software for Firewall Functionality: Secure Sideloading of Extraction Agent

The software firewall is a script that requires a macOS computer. Its primary advantage is convenience and cost, as it requires no additional hardware beyond your existing Mac and cables. However, deploying it requires strict attention to detail. You must follow the provided setup instructions exactly as written; a single misstep in configuration can easily compromise the environment. A mistake here can result in failed signature validation or, more critically, unrestricted internet access for the evidentiary device, putting the data at risk.

The hardware firewall, on the other hand, requires an initial investment to purchase a Raspberry Pi microcomputer and necessary network adapters. While we support several single-board computers, we generally advise against using Orange Pi models, as our testing has shown them to perform unreliably in this role. The main benefit of the hardware route is its consistency. Once the initial configuration is complete, the device essentially becomes plug-and-play, allowing you to use it repeatedly without worrying about active network configurations.

For users deploying the hardware firewall on older Raspberry Pi 3 or 4 models, the custom firmware is open-source and available on our GitHub repository.

If you plan to use the newer Raspberry Pi 5, the setup differs slightly. We have a dedicated, pre-configured SD card image specifically for the Pi 5. Unlike the older versions, this image is closed-source but provided free of charge. Since it is not hosted on our public repository, you simply need to contact our support team directly, and they will provide you with the necessary image file.

Workstation and Connection Prerequisites

Before attempting to sign or install the agent, the following workstation conditions must be met:

• Internet Access: The host computer performing the signing process must be online.
• Direct USB-C Connection: Always use a direct USB-C connection from the workstation to the device (whether the device has a Lightning or USB-C port). Avoid using hubs or adapters, as they can cause connection drops or throttle extraction speeds.
• Time Synchronization: The date and time must be accurate and synchronized on both the host computer and the target mobile device.
• Antivirus Exclusions: Host antivirus software (such as Windows Defender) must be temporarily disabled. The OS-level exploits contained within the agent will frequently trigger false positives and be quarantined by security software, causing the installation to fail.

Apple ID and Signing Requirements

A common misconception is that the extraction agent must be signed using the Apple ID linked to the target device. This is incorrect; the target device’s logged-in account is irrelevant to the signing process. An investigator-controlled Apple ID must be used, subject to the following rules:

• Mandatory Trusted Device: The signing Apple ID must have a trusted Apple device linked to it to handle Two-Factor Authentication (2FA) prompts. Relying on SMS for 2FA is highly unreliable for this process; Apple may temporarily ban the account after as few as two or three SMS verification requests.
• Paid Developer Apple IDs: This is the recommended tier. It allows signing for up to 100 iPhones and 100 iPads per year.
  • Cooling-off Period: Certificates for the first 10 devices are generated instantly. For the 11th device and beyond, Apple imposes a “cooling-off” period of up to 72 hours (the status will show as ‘pending’ in the developer portal).
  • Offline vs. Online Validation: Only paid accounts registered before June 6, 2021, can perform a fully offline first launch. For all accounts created after this date, our previous offline workaround has been patched by Apple, making online validation (via a restrictive firewall) mandatory.
• Standard (Free) Apple IDs: Free developer accounts lack signing privileges and cannot be used. Regular consumer Apple IDs can be used but carry strict limitations:
  • They are limited to signing 3 devices per week.
  • The account must have a prior history of logging into iCloud from an Apple device.
  • Standard accounts require manually trusting the developer profile in the device settings, which strictly necessitates an online connection through the firewall.

Device Preparation and Troubleshooting

Several iOS security features require manual intervention during setup to establish a connection and allow the agent to run.

• Establishing Trust: A trusted connection between the device and the workstation is mandatory. If EIFT throws a handshake with lockdownd failed error, the trust pairing is corrupted. Resolve this by running the eift_cmd normal unpair command, reconnecting the cable, and accepting the trust prompt again.
• Stolen Device Protection (SDP): If SDP is active on iOS 17.3 or newer, establishing the initial trust relationship requires biometric authentication (Face ID).
• Developer Mode (iOS 16+): Developer Mode must be enabled to run the agent. The toggle for this setting only appears in the iOS settings menu after the signed app has been sideloaded. Enabling it requires entering the device passcode and performing a reboot.

Running the Extraction

Once the agent is running, follow these technical guidelines to ensure a stable extraction:

• Extraction Order: Always extract the Keychain first. It is very fast and secures critical decryption keys immediately.
• Kernel Panics: It is normal for the device to occasionally kernel panic and reboot when applying the exploit. If this occurs, wait a few minutes after the reboot and retry the process. It may take three or four attempts to achieve a stable sandbox escape.
• Physical Stability: File system extractions operate at speeds between 35 MB/s and 200 MB/s. Do not touch the device, cable, or the EIFT license dongle during this process. Ensure the host computer is configured to never enter sleep mode. Remember: extractions cannot be resumed. Any interruption will require restarting the entire extraction from the beginning.
• APFS File Sizes: The resulting .tar file may be larger than the logically used space on the device, or even larger than the device’s total storage capacity. This is normal behavior caused by how the Apple File System (APFS) handles snapshots, clones, compression, sparse files etc., as well as symlinks.
• Storage Destination: Unless you are using a fast external SSD drive with consistent write speeds, we discourage extracting directly to an external hard drive, USB flash drive, or network share (especially on Windows hosts). Instead, we recommend extracting the data to the host computer’s internal storage first, and copying it to external media only after the extraction is completely finished.

Extracting cloud data becomes increasingly valuable – and increasingly complex at the same time. In scenarios where a target device is physically unavailable cloud extraction is often the only real way to access evidence. This is particularly relevant when devices are secured by an unknown passcode or locked under Apple’s Stolen Device Protection framework without available biometric authentication, rendering traditional extraction techniques ineffective.

Apple’s cloud ecosystem aggregates synchronized data from all devices tied to a specific Apple ID, providing forensic specialists with a comprehensive, cross-device dataset rather than a fragmented, single-device view. Accessing this data, however, requires more and more efforts. Beginning with the rollout of iOS 18, Apple initiated substantial modifications to its cloud infrastructure and access mechanisms. While backward compatibility with legacy access protocols was temporarily maintained to support devices running older versions of iOS, Apple executed a definitive cut-off in January and February of 2026. During this window, the old protocols were permanently blocked, and cloud authentication procedures were entirely overhauled, rendering prior extraction methods obsolete.

What Works Now: iCloud Drive and Synchronized Data

Elcomsoft Phone Breaker 11 restores extraction capabilities for most data categories including synchronized data, iCloud Drive, and iCloud backups.

Let’s start with iCloud Drive. This service frequently acts as a catch-all repository for user data beyond standard iOS backups. It routinely contains synchronized macOS Desktop and Downloads folders, alongside application data and third-party backups from various iOS and iPadOS apps, such as encrypted WhatsApp backups. Accessing this unstructured storage often yields evidence that is not categorized by Apple’s standard synchronization services.

The updated engine also successfully extracts regular, non-end-to-end encrypted (E2EE) synchronized data, providing a consolidated view of user activity across the account. The following data types are currently supported:

• Account Info & Devices: Yields a full list of linked devices to guide further hardware acquisition. It also extracts the FileVault token, which can decrypt Intel-based (non-T2) Mac disk images without a password. Support for APFS decryption utilizing this token will be arriving soon in Elcomsoft Forensic Disk Decryptor.
• Photos & Notes: These high-value targets are extracted with metadata intact. Photos retain EXIF data, including geolocation and timestamps, while Notes maintain folder structures and attachments. Based on our observations, data manually cleared from the “Recently Deleted” folder can sometimes still be recovered for up to two weeks before Apple permanently purges it from their servers.
• Other Usable Data: Extracts Screen Time metrics (installed apps per device and Family Sharing members), Voice Memos, Wallet items (loyalty cards and boarding passes), Contacts, Calendars, iBooks (which frequently hold PDF tickets), Apple Maps (Favorites only), and Safari records (Bookmarks, Open Tabs, and Reading List).

No End-to-End Encrypted Data: The main limitation of the current release involves data protected by Apple’s end-to-end encryption. As we are still working on the overhauled E2EE authentication mechanisms, these categories remain inaccessible. Currently, we cannot extract Apple Maps (Searches and Explored places), Safari browsing history, Health data, iCloud Keychain, or Messages.

End-to-end encrypted data is only available (according to https://support.apple.com/en-us/102651) to trusted devices. Previously, one could enroll into the trusted circle by simply providing a passcode or system password of an already trusted device. Now, however, Apple additionally engages Secure Enclave, which currently eliminates software-based access.

iCloud Backups: Known Issues and Workarounds

Currently, iCloud backups kind of work. They do download, but stability remains an issue when handling large data sets. While small backups typically download without error, the extraction of larger backups may unexpectedly interrupt or fail after downloading several gigabytes. These interruptions appear to be the result of new, undocumented security measures Apple recently implemented for backup data. The exact reason causing the downloads to drop is currently unknown; we are actively investigating into these new protocols to identify the root cause and develop a permanent fix.

In the meantime, investigators can use a workaround to bypass this issue and still download the data. When setting up the extraction or a large cloud backup, first check the box for “Restore original file names,” and then “Download only specific data.” Once the subsequent list loads, select all available categories. Our testing confirms that this selective download method extracts nearly the entire backup without triggering an interruption.

Conclusion

We released Elcomsoft Phone Breaker 11 mainly to restore access to the highest-yield, most reliable evidence such as synchronized data and iCloud Drive as quickly as possible, rather than delaying the release for an all-inclusive and permanently-fixed solution. The primary missing piece in this build remains the extraction of end-to-end encrypted categories. We are currently working on investigating Apple’s new E2EE authentication mechanisms, and support for these protected data types will be addressed in a future update. Another point to address will be the permanent fix to the backup downloading problem; we are actively working on a solution.

We updated iOS Forensic Toolkit, adding low-level extraction support for iOS 26 and 26.0.1 via the extraction agent. This support is available for most iPhones and iPads compatible with the iOS 26 branch with a notable exception of the iPhone 17 range and M5-based iPads. Why exactly are these devices exempt, and what else did Apple do to make iOS 26 tougher and more resistant? Let’s find out.

Released on September 15, 2025, iOS 26 represents an important shift in mobile security. Apple made an attempt to transition the operating system’s defenses away from reactive software patching, anchoring it instead in hardware-enforced trust based on hardware-level memory safety and post-quantum encryption. This shift establishes a framework designed to operate in highly sensitive environments. The underlying architecture is robust enough that devices running the iOS 26 branch are formally approved to process and store information classified up to the NATO Restricted level. Germany’s Federal Office for Information Security (BSI) evaluated and confirmed this certification.

Under-the-Hood Security Features

The most important architectural changes introduced in iOS 26 happened under the hood. In this chapter, we’ll list everything we know about those newly introduced security features, blending Apple’s official documentation with the findings discovered by independent security researchers. The most significant advancements move beyond traditional software patching, embedding security directly into the physical hardware and cloud infrastructure – which explains why our extraction agent works just fine with pre-A19/M5 devices but fails on the current generations of Apple chips.

Memory Integrity Enforcement (MIE)

The most important change is the newly introduced Memory Integrity Enforcement (MIE). Available exclusively on devices equipped with A19, A19 Pro, or M5 processors, MIE provides hardware-backed memory safety to neutralize common exploits like buffer overflows and use-after-free conditions. The system assigns a mathematically generated 4-bit secret tag to every memory allocation. To access that memory, the processor must present a matching tag. Apple’s implementation mandates strict synchronous enforcement; if a tag mismatch occurs during an exploit attempt, the hardware triggers an immediate, un-interruptible CPU exception that instantly terminates the compromised process before the payload can execute.

Memory Integrity Enforcement is incredibly effective, and serves as a hard roadblock to device exploitation. Let’s pause for a moment and talk about how iOS Forensic Toolkit operates. For low-level extraction of modern Apple hardware, iOS Forensic Toolkit relies on a lightweight, in-house developed app we call the extraction agent. The agent packages all known OS-level exploits into a single app. Once sideloaded onto a compatible device, the agent:

1. Applies an exploit chain to elevate privileges, escape the sandbox, and gain access to both the root file system and the encryption keys required for keychain decryption.
2. Establishes a communication channel between the tablet and the examiner’s workstation.
3. Facilitates the full extraction of the file system and keychain records.

Memory Integrity Enforcement cuts this workflow early during the very first step. The moment we try to apply the exploit – the same exploit that works on other devices running the same version of the OS – MIE triggers an exception, force closing the agent app. No exploit > no sandbox escape > no low-level access to the file system, end of story.

However, there is more to iOS 26 than Memory Integrity Enforcement. Let’s talk about other changes in the OS that tightens its security even further.

Background Security Improvements (BSI)

To reduce the latency between vulnerability discovery and patch deployment, iOS 26.1 formalized the Background Security Improvements (BSI) architecture. This system allows Apple to deploy lightweight, targeted security releases for critical components such as the Safari browser and the WebKit framework without requiring users to download a massive, multi-gigabyte operating system update.

The “Jailbreak Drought” and Testing Ambiguity

Apple’s aggressive kernel hardening has significantly restricted the ability to execute full jailbreaks on modern iOS devices, but it has not entirely eliminated deep system access. The reality is more nuanced: while full jailbreaks have become exceedingly difficult, breaking iOS 26 on older devices just enough to extract the root file system is still possible. For example, Elcomsoft iOS Forensic Toolkit delivers full file system extraction on older Apple TV 4K units running tvOS 26, and the low-level extraction agent has been tested with support for iOS and iPadOS 26.0 and 26.0.1.

These nuances introduce a clear ambiguity regarding the actual security baseline of the ecosystem. The ambiguity lies in a distinct hardware divide: older devices remain vulnerable to low-level extraction, while the newest silicon locks down root access and blocks standard defensive testing. It is currently unknown how independent auditors are supposed to handle live runtime security validation on the newest iOS 26 devices, or who is ultimately responsible for bridging this testing gap.

Rapid Patching Lifecycles

The iOS 26 release cycle demonstrated a highly aggressive patching strategy against zero-day vulnerabilities. With the release of iOS 26.2, Apple addressed actively exploited WebKit vulnerabilities by implementing a mandatory reboot that effectively flushed the device’s volatile memory, clearing out resident mercenary spyware that operates exclusively in RAM. Subsequent rapid updates continued this cadence; iOS 26.3 quickly closed critical memory corruption vulnerabilities within the dynamic link editor (dyld), while iOS 26.4 hardened state management and secured 802.1X networking protocols against privileged network interception.

Private Cloud Compute (PCC)

Apple Intelligence relies on server-based generative models to execute tasks such as text summarization, image generation, and Writing Tools requests. When these machine learning operations exceed the processing capabilities of the local device, iOS 26 securely offloads the workload to Private Cloud Compute (PCC) servers. Built using custom Apple Silicon, this infrastructure is engineered to prevent data exfiltration. The architectural design ensures that the personal data transmitted to the cloud is utilized exclusively for the immediate computational request and is cryptographically inaccessible to everyone, including Apple administrators, server technicians, and law enforcement.

User-Facing Security Features

Historically, security analyses tend to prioritize kernel mitigations and cryptographic frameworks. We begin by examining the user-facing features of iOS 26, however, because the most persistent threat vector remains physical compromise. By overhauling how users interact with system functions like wired accessory handshakes, device recovery states, and location-based authentication delays, Apple attempts to bridge the gap between theoretical software security and practical, everyday deployment. These features matter because they act as the immediate friction points that actively neutralize local exploitation before a device’s deeper architecture is ever tested.

Some newly implemented policies introduce visible friction points. For example, mandatory biometric delays and default lockout protections can disrupt enterprise support workflows. In these cases, the responsibility for adjusting policies and managing device access falls to internal mobile device management (MDM) administrators rather than the end-users.

The following sections detail the tangible security tools that users now directly interact with.

Stolen Device Protection (SDP)

Stolen Device Protection (SDP) intercepts critical system modifications when the iPhone is away from familiar locations, such as the user’s home or workplace. Apple shifted the implementation dramatically throughout the lifecycle, transitioning the feature to be enabled by default for all standard consumer iPhones starting in iOS 26.4. In the subsequent iOS 26.4.1 update, Apple forcefully enabled SDP by default for all enterprise devices managed under Mobile Device Management (MDM) profiles. When a device is away from familiar locations, SDP neutralizes physical theft by requiring mandatory biometric authentication without offering a passcode fallback option. If the biometric check fails, the action is hard-blocked.

Wired Accessories Permission

The new Wired Accessories Permission completely replaces older USB restricted modes by blocking any unauthorized data connection via the physical port while the device is locked. Located within the Privacy & Security settings, it forces a prompt requiring explicit user consent and device unlock before external hardware can interface with the internal data buses. If an unvetted accessory fails a complex cryptographic handshake or the user denies permission, the iOS 26 kernel strictly limits the connection to just power delivery and a microscopic subset of serial audio controls. This feature is designed to neutralize automated hardware brute-forcing and render forensic extraction tools that rely on physical port access functionally obsolete.

Recovery Assistant

Maintaining strict operational security during critical system failures represents a unique architectural challenge. To address this, the new Recovery Assistant feature – built directly into the system’s lowest-level immutable firmware – allows an iPhone or iPad to perform a complete system restoration securely over a Wi-Fi connection. This completely eliminates the need to tether the device via cable to a Mac or PC during a critical boot failure. The system utilizes the device’s hardware root of trust to authenticate a connection to Apple’s centralized servers, safely downloading and verifying the cryptographically signed iOS 26 image locally.

Enhanced Safety Alerts

While the vast majority of security features operate invisibly, several user-facing modifications were introduced to manage stability and physical safety. For example, Enhanced Safety Alerts provide highly reliable push notifications for imminent physical threats and geographic emergencies. These alerts are architecturally structured to bypass standard focus modes and Do Not Disturb settings under all conditions, delivering actionable safety guidance directly to the Lock Screen.

Developer-Facing Security Features

A secure operating system must empower third-party developers to build secure applications easily. While kernel-level mitigations provide the foundation, the practical security of a device heavily depends on the software ecosystem running on top of it. To that end, iOS 26 introduces several new APIs, framework deprecations, and capability requirements designed to shift the burden of security from the user to the underlying application architecture.

The following sections explore the new tools and frameworks Apple requires app creators to utilize to ensure software integrity, ranging from cryptographic modernization to hardware-backed memory protections.

Post-Quantum Cryptography APIs

As the theoretical viability of large-scale quantum computers advances, the threat model known as “harvest now, decrypt later” has become a pressing concern for intelligence agencies and enterprise security teams. In this scenario, adversaries intercept encrypted communications today with the intent of decrypting them years later. Apple addressed this threat by updating the CryptoKit framework to provide native developer support for post-quantum algorithms alongside classical elliptic curve cryptography. Specifically, developers can utilize ML-KEM to securely encapsulate shared secrets and ML-DSA for quantum-secure authentication. Recognizing that nascent cryptographic standards must be integrated cautiously, Apple mandates a Hybrid Public Key Encryption (HPKE) workflow. This approach combines classical and post-quantum algorithms, ensuring that if a future cryptographic breakthrough compromises the newer lattice-based mathematics, the system remains protected by the classical layer.

Memory Tagging Entitlements

To leverage the hardware-backed Memory Integrity Enforcement (MIE) features on the A19 processor, developers must explicitly opt their applications into the protection via Xcode 26. After enabling “Hardware Memory Tagging” in the capabilities tab, Xcode injects specific entitlements into the compiled application binary. Developers can compile their binaries in two distinct modes. “Hard Mode” is the default setting for production applications, enforcing immediate application termination upon any tag mismatch to ensure maximum security against buffer overflows. Conversely, for debugging purposes, a “Soft Mode” exists. Soft Mode merely logs the tag mismatch to the console without crashing the application, allowing developers to identify subtle memory leaks before broad deployment.

Credential Management

The newly introduced dedicated Passwords app significantly enhances the underlying credential APIs available to developers. The Automatic Passkey Upgrades framework enables applications to seamlessly migrate users away from legacy passwords. When a user successfully authenticates using an existing password, the iOS 26 credential manager can automatically negotiate the generation of a secure passkey in the background, permanently replacing the outdated credential in the iCloud Keychain.

Child Privacy Frameworks

iOS 26 introduces the Declared Age Range API and PermissionKit to manage child privacy. Instead of requesting a precise date of birth, the Declared Age Range API allows developers to request a generic age bracket, verifying compliance internally against the user’s Apple Account.

PermissionKit complements this by controlling communication requests to child accounts. For native Apple apps like Messages, Phone, and FaceTime, this operates out-of-the-box at the system level: attempts to contact unvetted numbers are automatically intercepted and routed to a parent’s device for cryptographic approval.

For third-party communication apps, these frameworks are opt-in rather than acting as a universal firewall. Developers must actively integrate PermissionKit to route unknown sender requests through Apple’s parental approval workflow. If developers choose to bypass these APIs, iOS does not break their app’s internal communication features. Instead, Apple enforces compliance via the App Store. Non-compliant apps are assigned stricter age ratings (such as 13+, 16+, or 18+). Standard Screen Time and “Ask to Buy” settings then automatically hide or block these restricted apps from a minor’s device.

For decades, the forensic “gold standard” was straightforward: isolate the machine, pull the plug, and image the drive. In that era, what you saw on the screen was exactly what you would extract, bit by bit, from the magnetic platters. Today, that assumption is outdated, and is actively detrimental to an investigation. The digital forensics landscape is shifting too fast, and traditional “dead-box” methods cannot keep up with modern realities. As investigations face a crisis of scale, with terabytes of data spread across dozens of seized devices, the old “image everything, analyze later” approach has created massive backlogs that let critical leads go cold.

Enter digital triage. Far from being just an industry buzzword, triage has emerged as a practical necessity for modern investigations. It serves as the bridge between the initial seizure of a device and the final lab report. Instead of acquiring raw sectors and waiting for parsing, digital triage zeroes in on high-value artifacts – communications, web activity, system usage, and active sessions, – allowing investigators to bypass the imaging bottleneck and make immediate, actionable decisions in the field.

The primary advantage of this methodology is its operational efficiency: the ability to cut through hundreds of gigabytes of irrelevant system files to quickly extract just the data that matters. By prioritizing high-value evidence, investigators can make actionable decisions on the spot. Whether that involves securing cloud authentication tokens, tracing recent communications, or identifying connected peripherals, this targeted extraction keeps the investigation moving forward long before the physical hardware reaches the forensic lab.

Extracting DPAPI-protected data is a critical phase of the triage process, unlocking a diverse array of sensitive system and user artifacts. Once decrypted, investigators can retrieve native Windows service data such as Credential Manager entries, RDP logins, and specific certificates or private keys tied to the Windows certificate store. This extraction also exposes valuable network and web credentials, yielding Windows-configured VPN passwords, Wi-Fi profile keys, and saved browser passwords, though the availability of the latter depends heavily on the specific browser and version. Furthermore, decrypting DPAPI provides direct access to critical application tokens, uncovering OAuth and refresh tokens, developer-implemented API keys, and active session or login cookies from various supported applications.

The Toolkit: Elcomsoft Quick Triage and Elcomsoft System Recovery

We have two different tools that cover two distinct digital triage scenarios: Elcomsoft Quick Triage (EQT) and Elcomsoft System Recovery (ESR). Both tools are ultimately built to handle data extraction with basic features for quick on the spot analysis. The choice depends entirely on the system’s current power state and your level of access. EQT is optimized specifically for live evidence collection and subsequent on-the-spot or lab analysis. It is designed to be executed on a running, authenticated machine to rapidly pull volatile data, active communications, and cloud-bound files. If you encounter an edge case where the best approach is unclear – for instance, a machine that is powered on but locked, – we cannot give a universal advise; the investigator on the scene must evaluate the environment and make the operational call.

Elcomsoft System Recovery (ESR), on the other hand, is built for the exact opposite scenario: when the target system is offline or powered off. Instead of operating within the live Windows environment, ESR provides a clean, self-contained bootable workspace that runs independently of the host system. This makes it the ideal tool for cold boot scenarios, allowing you to safely perform disk imaging, extract password hashes from dormant system files, reset local user passwords, and assign administrative privileges to regain access. In short, while EQT is your primary instrument for capturing the live state of an active OS, ESR perfectly complements it as the essential fallback for bypassing locks and securing data on a dormant machine.

The Masterclass of Digital Triage

Welcome to the Masterclass of Digital Triage. In this series of articles, we tackle the distinct roadblocks investigators face in modern environments, guiding you from initial system access to granular artifact analysis.

The trajectory of an investigation hinges on choosing between cold boot and live analysis. If locked out, we explore how bootable recovery environments serve as an essential fallback to reset credentials and bypass lock screens. Once inside, we detail how to mitigate active antivirus software to ensure live extraction utilities run cleanly without triggering quarantine protocols.

This series explains why modern security hurdles, such as web browser App-Bound Encryption, strictly demand live triage. Offline imaging frequently yields encrypted, useless data because decryption keys rely on an active, authenticated user session.

Finally, we break down the technical core: extracting insight from the Windows Registry, EVTX logs, USB connection histories, and hidden artifacts in C:\Windows and C:\ProgramData. We demonstrate how to parse these interconnected data structures to establish definitive operational histories, track external drive usage, and expose anti-forensic tampering.

The Evolution of Digital Forensics

• Introducing Elcomsoft Quick Triage
• The Shift from Disk Imaging to Digital Triage

Strategy, Access, and Overcoming Roadblocks

• Choosing the Right Strategy: Cold Boot Forensics vs Live System Analysis
• Recovering Windows Credentials with Elcomsoft System Recovery
• Live System Analysis: Mitigating Interference from Antivirus Tools
• Browser Forensics in 2026: App-Bound Encryption and Live Triage
• Web Browser Forensics in Digital Triage

Deep Dive: Windows System Artifacts

• Investigating Windows Registry
• Forensic Analysis of Windows 10 and 11 Event Logs
• USB Device Forensics on Windows 10 and 11
• Investigating Windows File System Artifacts Under C:\Windows
• Windows File System Artefacts Under C:\ProgramData
• The C:\User Data in Windows Forensics

In traditional forensic workflows, gaining access to a Windows system was a straightforward exercise: extract the NT hashes from a local database and run a fast (very fast!) offline attack. Today, Windows authentication is moving away from those essentially insecure NTLM hashes toward more resilient mechanisms. Microsoft is actively steering users away from local Windows accounts, pushing them toward cloud-integrated identities (such as the Microsoft Account) and hardware-backed security models (like Windows Hello).

In this article, we will examine the four primary sign-on options used in modern versions of Windows: legacy local Windows accounts, consumer Microsoft Accounts, traditional Active Directory environments, and Entra ID cloud configurations. We will detail what credential extraction actually entails in each specific scenario with Elcomsoft System Recovery. Because the definition of a recoverable credential now varies depending on the account type, we will discuss exactly which data can be targeted, what can be recovered with an offline attack, and where traditional password recovery is no longer applicable.

Local Windows Accounts (NTLM)

Local Windows accounts represent the legacy standard for system authentication. While Microsoft actively buries this option during the Windows 11 setup process to push users toward cloud-connected profiles, these accounts remain common in the field. Examiners frequently encounter them on older systems, offline workstations, or machines where users deliberately bypassed Microsoft’s default setup prompts.

Under the hood, the architecture for these accounts is entirely self-contained. User credentials are natively stored on the local disk rather than synchronizing with an external server. The operating system calculates and saves these passwords as NTLM hashes directly within the Security Account Manager (SAM) registry hive.

For the forensic examiner, this remains the most straightforward password recovery scenario. The process simply requires acquiring the SAM and SYSTEM registry hives from the target drive offline. Once the NTLM hashes are extracted from the registry, they can be rapidly broken using high-speed dictionary or brute-force attacks on standard GPU hardware.

Microsoft Accounts (MSA), Passwordless Sign-In and Windows Hello Ambiguity

The Microsoft Account (MSA) is the current consumer default, bridging local device access with Microsoft’s broader cloud ecosystem. A compromised account yields a high reward: access to local files, synchronized OneDrive data, and potentially BitLocker recovery keys. Under the hood, authentication branches into two distinct paths: traditional passwords and modern passwordless sign-ins.

It is a common misconception that Windows simply caches a traditional NTLM hash of the online password for offline logins. In reality, the password hash is not stored on the PC. Instead, the system forms a “protector.” These protector details are stored locally and are encrypted with the user’s Microsoft Account password and/or with hardware-backed credentials depending on how exactly the account is configured. The encryption is significantly stronger and slower to break than the old NTLM. For an examiner, credential extraction means targeting this locally stored protector, not a raw hash.

Conversely, Microsoft is aggressively pushing toward passwordless logins via Windows Hello. This method relies on a PIN or biometrics (such as an IR camera or fingerprint reader). In this scenario, the local protector is encrypted by a hardware-backed mechanism tied to the system’s Trusted Platform Module (TPM), effectively blocking offline brute-forcing.

This introduces a hardware-level ambiguity, specifically in older Windows installations. In Windows 10, if a system has a disabled or unsupported TPM, the Windows Hello PIN might fall back to a locally cached software state. It is not visually obvious from the login screen whether a device relies on hardware protection or has fallen back to a vulnerable software cache. We must admit this ambiguity clearly: you cannot tell from the Windows version or the hardware config alone. The forensic examiner is responsible for handling this by parsing the local credential database to determine exactly how the protector is encrypted. If the protector is encrypted by the MS Account password or a software-cached PIN, an offline attack may proceed. If the protector is confirmed to be strictly hardware-backed, offline recovery is a dead end.

How Elcomsoft System Recovery Can Help

This is exactly where Elcomsoft System Recovery (ESR) comes into service. When an examiner boots the target machine using ESR, the software handles the ambiguity by automatically parsing the system’s database to identify the exact type of protector in use.

If ESR identifies that the protector is encrypted with an MS Account password, it can launch an immediate offline attack. However, examiners must be aware of current technical constraints regarding this specific attack vector. Because of the specific encryption used by the protector, the attack relies entirely on the CPU. There is currently no GPU acceleration available for this process. As a result, examiners are strongly advised to use targeted dictionary attacks rather than attempting a full brute-force recovery.

Currently no other Elcomsoft tool supports the recovery of these passwords. Elcomsoft Distributed Password Recovery (EDPR) is not compatible with this specific protector format in its current version (compatibility is planned for a future update). For the time being, this attack can only be executed using the latest release of ESR and the upcoming release of Elcomsoft Quick Triage (EQT).

Active Directory Accounts

Traditional Active Directory environments represent the classic corporate network setup. In this architecture, the master authentication database (NTDS.dit) resides centrally on the Domain Controller. However, for the sake of mobility, Windows workstations cache domain credentials locally so users can still log in when disconnected from the corporate LAN. For an examiner analyzing an isolated machine, the central server is out of reach, making this localized cache the primary target.

At the workstation level, forensic extraction focuses on pulling Local Security Authority (LSA) secrets and DPAPI data from the system. If successfully extracted, the examiner can run a fast offline attack against these cached domain credentials.

Entra ID (Corporate Cloud) Accounts

Entra ID (formerly Azure AD) is the modern corporate standard, engineered specifically for zero-trust environments and remote workforces. Authentication in this architecture is fundamentally cloud-based, heavily utilizing Windows Hello for Business, Conditional Access policies, and Primary Refresh Tokens (PRTs) to validate users and manage sessions.

In these setups, traditional local password hashes are nonexistent. This raises a clear ambiguity regarding our terminology: does gaining access to an Entra ID environment actually count as “password recovery”? Technically, it does not. We must be upfront with the reality of modern corporate forensics: literal “password recovery” is effectively dead in a properly configured Entra ID environment. Instead, the forensic examiner is responsible for handling access by extracting a block of protected data and running an offline attack against it, as detailed below.

How Elcomsoft System Recovery (ESR) Can Help

While an Entra ID deployment does not store a traditional password hash on the local PC, it does store a localized block of data secured with strong encryption (distinct from legacy NTLM). Access to this encrypted block is managed by a protector. In a standard corporate rollout, this protector is usually a hardware-backed PIN or a FIDO security key. However, if the system configuration utilizes a password as the protector, localized recovery is still an option.

Elcomsoft System Recovery (ESR) can be deployed to attack this specific localized data block, but examiners must note several technical constraints. First and most importantly, we can only recover the authentication data if it is guarded by a password protector. If the data block is secured by a hardware-backed PIN or FIDO key and lacks password-based access (which is Microsoft’s recommended practice), offline recovery is not possible. Second, similar to Microsoft Accounts, Entra ID uses strong encryption to protect that data block, which means the attack will be slow compared to NTLM. The currently implemented method relies entirely on the CPU, and there is no GPU acceleration available yet. Therefore, running a targeted dictionary attack is highly recommended over attempting a full brute-force recovery.

Finally, while offloading the attack onto a more powerful tool such as Elcomsoft Distributed Password Recovery sounds tempting, that tool does not currently support this specific encryption format (an update is planned). As of now, this encrypted block can only be attacked using the current release of ESR and the upcoming release of Elcomsoft Quick Triage (EQT).

With the release of iOS Forensic Toolkit 10.01, we are extending low-level extraction capabilities to Apple tablets running up to iPadOS 18.7.1. This update brings our extraction agent to the latest hardware, supporting not just A-series but also M-series iPads. We have also implemented support for the distinct memory layout found in high-end 1TB and 2TB iPad Pro models equipped with 16GB of RAM, which required a targeted engineering approach to handle the structural differences.

iPads are frequently sidelined in digital investigations, as they generally log fewer calls and messages and gather less continuous location data than smartphones. However, their integration into the Apple ecosystem ensures that user data is routinely synchronized across all connected devices. An iPad linked to a target Apple ID will often mirror the user’s primary iPhone, providing an alternate vector for acquiring synced keychain, messaging histories, and media files, often while featuring lower operational security, such as a simpler passcode, than the primary phone.

There is also a practical advantage to examining Apple tablets: their extended hardware lifecycle. Tablets are typically kept in service much longer than smartphones, with users routinely skipping multiple hardware generations before upgrading. Because of this longer operational life, examiners have a higher probability of encountering an older device running an exploitable version of iPadOS. This directly increases the chances of successfully deploying an extraction agent to acquire the full file system and the decrypted keychain.

iPad Extraction: Agent vs. Bootloader

For those new to iOS Forensic Toolkit, the extraction agent is a lightweight, in-house developed app designed to facilitate low-level device acquisition. The agent packages all known OS-level exploits into a single utility. Once sideloaded onto a compatible iPad, the agent:

• Applies an exploit chain to elevate privileges, escape the sandbox, and gain access to both the root file system and the encryption keys required for keychain decryption.
• Establishes a communication channel between the tablet and the examiner’s workstation.
• Facilitates the full extraction of the file system and keychain records.

This method allows examiners to extract comprehensive datasets at a low level, retrieving information that remains entirely inaccessible via standard logical backups or advanced logical acquisition.

Conversely, bootloader-based extraction (leveraging the checkm8 vulnerability) offers a strictly read-only, forensically sound acquisition path that does not alter a single bit of user data. However, because checkm8 is a hardware-level exploit, compatibility is permanently capped at the Apple A11 Bionic SoC. Interestingly, Apple never released an iPad featuring the A11 chip, transitioning its tablet lineup directly from the A10/A10X to the A12-series architecture.

Consequently, the applicable extraction methodology is strictly dictated by the iPad’s chipset:

• A10 and older: Bootloader exploit. This remains the definitive choice for legacy hardware, offering a clean, forensically sound extraction regardless of the installed iPadOS version.
• A11: OS-dependent. While not applicable to iPads (there were no iPad models featuring this exact SoC), it is worth noting for broader ecosystem context that A11 devices rely on the bootloader exploit for iOS 13 and older, shifting to the extraction agent for iOS 14 through 16.
• A12 and newer (including M-series): Extraction agent only. Because these modern silicon architectures are immune to known bootrom vulnerabilities, deploying the extraction agent is the exclusive path for full file system and keychain acquisition.

M-Series iPads

Previous versions of the toolkit focused on iPads powered by A-series processors. With the release of EIFT 10.01, we have extended compatibility to Apple’s M-series silicon. While the M-series shares a similar underlying architecture with the A-series, it introduces some hardware-specific nuances. We have updated the extraction agent to account for this specific M-series behavior, ensuring the exploit chain can execute as intended.

A more notable challenge, however, involves the hardware configurations of high-tier iPad Pro models. Specifically, the 1TB and 2TB variants are equipped with 16GB of RAM. This increased capacity results in a very different memory layout for active processes compared to standard models. We have modified the agent to support this alternative structure, but we must be clear about it: support for 16GB 1TB/2TB iPad Pro configurations is implemented, but the exploit path is not yet fully stable. In practice, you should expect occasional reboots and may need multiple attempts before the agent successfully initializes.

Hardware Matrix: Ports, Protocols, and Real-World Speeds

Now for the good news: extracting data from an iPad is frequently much faster than acquiring an iPhone. The majority of iPhones rely on a standard USB 2.0 implementation, which restricts extraction speeds regardless of the method used. With iPhones, one can expect real-world transfer rates of around 40 MB/s. Even the select iPhone models equipped with USB 3.0 controllers (and a USB-C port) generally cap out around 100 MB/s during acquisition. Apple’s tablet lineup, however, benefits from a much broader implementation of advanced physical interfaces and high-speed data protocols.

The following table categorizes the iPad lineup by physical connector and underlying data protocol. Models marked with an asterisk (*) feature the older Lightning connector, while all others utilize a USB-C port.

While the hardware specifications of newer iPads are substantial (particularly the 40 Gbps Thunderbolt/USB4 bandwidth on modern iPad Pros), there is a difference between theoretical limits and real-world performance. Theoretical numbers suggest near-instantaneous transfers, but practical constraints remain. Due to the processing and protocol overhead inherent to how the extraction agent reads the encrypted storage, packages the files, and transmits the data over the connection, maximum extraction speeds currently peak at around 200 MB/s, and the average speed is about 150 MB/s due to the large number of small files and respective overhead. Although this leaves the massive bandwidth headroom of USB4 largely untapped, it still represents a substantial improvement over legacy interfaces, noticeably cutting down the time required to image high-capacity tablets.

Best Practices for Achieving a Stable Connection

To achieve a stable extraction, you’ll need to ensure a stable physical link between the tablet and the workstation. For USB-C iPads, we strongly recommend not using hubs and adapters, using a direct USB-C to USB-C cable instead. If you have a Mac equipped with a Thunderbolt 4 or Thunderbolt 5 port, use that. Their advanced host controllers handle power delivery and data protocol negotiation exceptionally.

Don’t skimp on a good cable either. Extracting a full file system is a sustained, resource-intensive operation; you don’t want it to fail midway because of a poor quality cable. Use a high-quality, properly labeled certified data cable to maintain stability throughout the transfer. A charging cable, even one with high rated wattage, might negotiate a connection, but more often than not it will simply cap at USB 2.0 speeds. You’ll need a properly labeled USB3 or better cable.