Choosing the Right Strategy: Cold Boot Forensics vs Live System Analysis🔎

The first steps of an investigation are rarely straightforward. Do you shut down the system and image the storage media, taking the safe but slow traditional path? Do you run a triage tool on the live system to grab passwords and keys, or do you reboot into a clean forensic environment?

Traditional wisdom might suggest pulling the plug to preserve the state of the disk, but modern encryption makes this increasingly difficult📊

During the initial stage of an investigation, the choice usually falls between two primary strategies: deploying a live triage tool on the running system or booting into a clean, external environment🖥

In this article, we look at the trade-offs between Elcomsoft Quick Triage and Elcomsoft System Recovery to help you decide which tool fits the scenario.

More in our new article📎

#EQT #ESR

iOS Forensic Toolkit 9.0: full unlocking and perfect acquisition support for iPhone 6/6 Plus and other Apple A8/A8X devices🔥

The latest update to Elcomsoft iOS Forensic Toolkit introduces full unlock and perfect acquisition capabilities for iPhone 6, iPhone 6 Plus, iPad Mini 4, iPad Air 2 and other A8/A8X devices, including on-device passcode recovery.

In addition, low-level extraction is now supported for Apple TV 4 (HD), Apple TV 4K (1st gen) and HomePod devices running tvOS/audioOS 26.

More information at the link 💡

#EIFT #updating

🆕Distributed Password Recovery Goes 64-bit: Ready for RTX 5090🆕

We have just released a major update to Elcomsoft Distributed Password Recovery. While the release notes might simply say “migrated to 64-bit,” the reality under the hood is far more complex and significant⚡️

This is not a cosmetic update or a simple recompile; it is a fundamental architectural shift necessitated by the evolution of GPU hardware. Put simply: if you want to use the latest NVIDIA RTX 50-series Blackwell GPUs for password recovery, you can no longer use 32-bit code❗️

Here is why we did it, why it took so long, and why it matters for your forensic lab⌛

Let's talk about:

💡The introduction and evolution of hardware acceleration
💡Under the hood: the EDPR architecture
💡The plugin problem
💡The migration struggle
💡The result: ready for RTX 5090

More information at the link 📎

#EDPR

🆕Low-Level Extraction for iOS 17 and 18🆕

We’ve just update iOS Forensic Toolkit to version 10.0, significantly expanding its low-level extraction capabilities for both the extraction agent and bootloader-based methods🔴

⚡️ Previously, agent-based extraction was capped at iOS 16.6.1. This release finally covers the remainder of the iOS 16 branch, and adds support for the entire iOS 17 branch as well as iOS 18 through 18.7.1;
⚡️We have also expanded checkm8 support to cover all the latest OS updates pushed by Apple on devices susceptible to the exploit;
⚡️Finally, we improved extended logical acquisition support for iOS/iPadOS 26, now pulling significantly more shared data than before.

In this update we are making the following changes:

▪️For quite a while, agent-based extraction hit a hard wall at iOS 16.6.1. Newer releases required more powerful exploits, or more exactly, a chain of exploits.
With version 10.0, we finally put the pieces of the puzzle together. First, we’ve added support for the remaining iOS 16 builds, covering iOS 16.7 through 16.7.15. More importantly, the agent now supports the entire iOS 17 branch (17.0 to 17.7.8) and introduces support for a range of iOS 18 versions (18.0 to 18.7.1);

▪️Checkm8 support now includes iOS and iPadOS 15.8.7, iPadOS 16.7.15, and iPadOS 18.7.5. We also added support for iOS 16.8.8, though keep in mind the usual checkm8 limitations still apply. Finally, if you are extracting smart home or media hardware, we updated coverage for tvOS and audioOS to versions 26.3 and 26.4;

▪️We’ve added extended logical extraction support for iOS 26, including iOS 26.4, which delivers significant forensic value: this newly improved method can pull massive amounts of "shared files".

More information at the link 📎

#EIFT #update

🆕Low-Level Extraction for M-Series iPads🆕

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.

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.

More information at the link📎

#EIFT #update

Recovering Windows Credentials with Elcomsoft System Recovery❗️

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).

💡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;

💡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.

More information at the link📎

#ESR

Digital Triage Masterclass🇷🇺

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...

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.

Let's discuss:

❓️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.

❓️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.

More in our new article📎

🆕New Security Features and Low-Level Extraction of iOS 26🆕

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.

And more information at the link📎

#EIFT

🆕Elcomsoft Phone Breaker 11 Restores iCloud Access🆕

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

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.

More information at the link📎

#EPB #iCloud

Using the Extraction Agent in 2026: Compatibility, Signing, Firewall, and Extraction Tips🎓

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.

The agent is an in-house app that gets sideloaded directly onto the target device.

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.

Let's talk about:

💡What is it?
💡Data Scope and Acquisition Benefits
💡May 2026: At a Glance
💡Supported Devices and OS Versions
💡Installation, Signing, and Network Isolation

More in our new article📎

#EIFT

🆕Downloading iPhone and iPad backups from Apple iCloud🆕

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😊

More information at the link📎

#EPB #iCloud

A Decade of BitLocker Vulnerabilities: What’s Patched, What’s Not, and What Still Works💬

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. 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.

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. 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.

More in our new article📎

Forensic Implications of Apple Stolen Device Protection🧐

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.

More in our new article📎

🆕Downloading iOS 26 iCloud Backups🆕

Elcomsoft Phone Breaker 11.2 adds the ability to download iCloud backups created on devices running iOS and iPadOS 26 and, by extension, iOS/iPadOS 27 beta.

⚡️With this release, Elcomsoft Phone Breaker becomes the first and only third-party tool capable of pulling these backups from Apple’s cloud. That might read like a routine compatibility update. It isn’t. In iOS 26, Apple reworked its iCloud backup mechanism from the ground up, breaking every third-party tool that relied on the previous scheme. Restoring access meant rebuilding a large part of our cloud extraction pipeline. Below is what changed, what we did about it, and where the current build still has rough edges.

Roughly the only thing left untouched is the authentication protocol – every other layer between an authenticated session and a reconstructed backup was redesigned. For example, the chunks that make up a single backup may be spread across multiple back-end servers, with different hosts holding different parts of the same copy.

Taken together, these changes made every existing third-party forensic tool incompatible with iOS 26 backups. Adding support wasn’t a matter of patching a parser; it required reworking the entire engine.

Let's talk about what we fixed❤️

More information at the link📎

#EPB #iCloud

“Get Verification Code” Is Missing in iOS 18 and iOS 26; Here’s Where It Went🤔

If you have an Apple device running iOS 18 or iOS 26 and gone looking for the old Get Verification Code option under:

Settings → [user name] → Sign-In & Security

..you’ve probably noticed it’s no longer there. A quick search turns up forum threads, support comments, and even GitHub issues all reaching the same conclusion: Apple removed it.
Some posts go further and call it “deprecated” or “Apple’s middle finger to users of older devices.” 

😊That conclusion is wrong. The option still exists in iOS 26. It just doesn’t show up the way it used to.

We tell you how to actually get an offline code in iOS 26 and iOS 18 and why this matters.

More information at the link📎

#Tips

🆕Bypassing Stolen Device Protection: Alternative Ways of Installing the Extraction Agent🆕

Stated plainly: iOS Forensic Toolkit can now get past Stolen Device Protection.

There is a catch, and it belongs up front: this is not a magic unlock, and anyone selling it as one is selling something.

🔥What we have built is a way to install the extraction agent without ever pairing the iPhone to the workstation over a USB port.
Because the most disruptive thing SDP does to a forensic workflow is place Face ID or Touch ID in front of that pairing step, bypassing the pairing step bypasses the gate.
You still need:
🟢the device passcode;
🟢a paid Apple Developer account;
🟢a device you are authorized to examine.

With those in hand, SDP is no longer the wall it was a month ago.

This is the solution promised in Forensic Implications of Apple Stolen Device Protection. The how – every command, in order – will appear in a separate technical write-up.

This piece covers what the method does, when you would reach for it, and whether it should concern anyone who is not an examiner.

More information at the link📎

#EIFT

Sideloading the extraction agent: a Stolen Device Protection workaround👤

A new update to iOS Forensic Toolkit is out.
The headline feature is an alternative installation method for the extraction agent – that is, deploying it onto an iPhone while bypassing the mandatory pairing requirement.
The agent can now be delivered across the network, which removes a number of limitations that came with the usual cable-based installation. One requirement up front: the device must already be unlocked – in other words, the passcode must be known. This method does not work with a fully locked iPhone.

☺️Why a new installation method was needed?

The reason is a feature called Stolen Device Protection (SDP), which we discussed in the previous article. It is designed for the situation where a phone ends up in someone else’s hands and that person also knows the passcode.
In this mode, certain actions require biometric authentication – the owner’s Face ID or Touch ID — with no option to confirm the operation by entering the passcode. The checks tighten when the device is away from familiar locations such as home or work, and in settings they can be enforced at all times, regardless of location.

❗️Previously this protection could only be enabled optionally, and it was rarely encountered. Starting with iOS 26.4, that has changed: Apple turns Stolen Device Protection on automatically. As a result, examiners increasingly run into devices that simply will not allow a USB connection to a new computer.

😊The alternative agent delivery methods solve this.

More information at the link📎

#EIFT #Tips

🆕Two-Factor Authentication and iCloud: A Short History, and What We Fixed in Phone Breaker 11.03🆕

Two-factor authentication is the least glamorous security feature, and probably the most important one.

A password is “something you know”, which really means “something that can be phished, reused, leaked, or guessed”.

The second factor is “something you have”, and, while it can still be phished, it makes stolen passwords much less of a catastrophe they used to be. Everything else in account security is built on top of that. If the second factor is not there, or if it does not cover the data that actually matters, the rest is decoration.

Apple gets this right today. They did not always. The story of how they got here is worth telling, because it explains a lot about how iCloud acquisition works in 2026, and it leads directly to the two 2FA-related fixes in Elcomsoft Phone Breaker 11.03.

More information at the link📎

#EPB

The Long, Strange History of PDF (In)Security – And the Arrest That Made It Personal👁‍🗨

PDF has a reputation as the boring, dependable file format – the one you reach for when you need a document to look exactly the same on every computer, forever. What gets forgotten is that PDF’s security model has been shaky since version 1.0, and its history includes an FBI arrest, a federal jury trial that helped define how the DMCA actually works, and – twenty years later – a fake GIF that hid a tiny working computer inside an image compression stream.

This is that story, roughly in order, including the part where we were personally on the receiving end of it.

❓Where it all started: Adobe’s eBook experiment

Back in 1999–2001, Adobe was chasing the “eBook” market with the Acrobat eBook Reader (originally the GlassBook Reader) and a back-end called the Adobe Content Server. Publishers could lock a book down with any of several plug-in “security handlers” – Adobe’s own PDF Merchant and EBX, plus third-party schemes like FileOpen and SoftLock – restricting printing, copying, lending, or text-to-speech.

All of them shared the same underlying weakness, and it wasn’t really about key length…

More information at the link📎

Cracking Legacy ZIP Encryption: The Known-Plaintext Attack and Why It Still Sometimes Works 🔒

When someone hands you a password-protected ZIP archive, one’s immediate thought is:

“I need to break the password”.

For most modern archives, that is exactly the case, and the password is the whole game. But there is a family of ZIP archives where the password does not matter at all. It can be four characters or forty, random or memorable, if the archive uses the legacy ZIP encryption, the whole thing can be unlocked in minutes without ever guessing the password.

This is one of the oldest tricks in our line of work, and it is worth telling the story properly, because it is equal parts computer history and practical forensics 🔑

A word of caution before we start. The attack we are about to describe applies to the classic ZIP 2.0 encryption, the scheme Phil Katz built into PKZIP in the late eighties. Almost nobody should be creating archives with it today. Modern archivers default to AES, which is a completely different situation.

So treat most of this article as a fascinating piece of history, with a long and narrow tail of cases where it still bites in real life.

More information at the link📎

Digital Triage and the Rules of Evidence: What Holds Up, and Where👆

The scene is familiar. A couple of desktops, a laptop, two or three phones, maybe a NAS or a bunch of external drives, and a limited amount of time before you decide what you do on the spot and what can wait till the lab.

You cannot image everything on the spot, and even if you could, the lab queue would swallow it for weeks. So you triage: you look at what is in front of you and decide what matters, what is urgent, and what can wait.

The catch is that the decisions made in that first hour cast a long shadow. They determine not only what you find, but whether what you find can be used later, in a courtroom.

❤️This article is about that connection. How triage actually works, what principles govern the handling of digital evidence everywhere – not just the US, and why the very same misstep can be fatal in one country and a minor footnote in another.

Reminder: this is exactly what Elcomsoft Quick Triage is built to do on Windows systems. It captures the volatile side of a live session fast, memory, browser and account credentials, communications and user activity, along with the system artifacts that reconstruct who did what and when, and it stores everything in a single open container that keeps each artifact tied to its source.

More information at the link📎

#EQT