12. Analysis, acquisition
Encryption examination and recovery
In short: identify the encryption, look for keys you already hold, pursue legitimate sources, attack only copies, and never assume a rejected key is wrong.
An encrypted disk image is complete, verified evidence that cannot yet be read. Work through it in order:
- Identify what the encryption is.
- Look for key material you already have, starting with memory.
- Pursue legitimate recovery sources.
- Attack passwords last, and only against copies.
This section gives the method common to every platform. Sections 13 to 15 give the Windows, Linux and macOS specifics, including the components of each product that must not be confused with one another.
Identify the encryption technology
Work on a working copy of the physical image. Examine the partition table and the first sectors of each volume.
| Technology | How you spot it | Worth knowing |
|---|---|---|
| BitLocker | A recognisable signature in the volume header, and a metadata structure identifying the volume, the protectors in use (TPM, PIN, password, recovery password, key file, domain escrow) and the recovery key identifier. | Three copies of the metadata are stored on the volume, which matters when one is corrupt. The metadata can be read without a key, with tools such as the libbde utilities or the commercial suites. |
| LUKS | Begins with a magic value and a header describing the cipher, the key derivation function and the key slots in use. | The header can be dumped without a passphrase. LUKS2 keeps a second copy of the header. |
| VeraCrypt and TrueCrypt | No signature, by design. The usual indicator is a partition or file of high-entropy data from the first byte with no recognisable header, together with the software, its configuration and its drive-letter history on the system volume. | VeraCrypt keeps a backup of the volume header at the end of the volume. |
| FileVault (macOS) | Encrypts an APFS container; the container's structures identify it as encrypted. | See section 15. |
| Self-encrypting drives | Encrypt in the drive's own controller and present plaintext when unlocked. | A physical image taken through a locked drive is ciphertext; through an unlocked drive it is plaintext. Record which. |
| Other full-disk or container products | Enterprise endpoint encryption, third-party containers, encrypted archives and databases: identified by their signatures, the installed software, and configuration and log files on the system volume. |
Measure entropy
- Uniformly high entropy with no structure means encrypted, compressed or random.
- Regions with structure are not.
- Plot entropy against offset. It often reveals an encrypted container inside an otherwise ordinary volume, or the boundary of a hidden volume.
Search memory for key material
If memory was captured while a volume was unlocked, the memory image may contain the key.
- Tools search for key schedules, not keys. They look for the characteristic structure of cipher key schedules; the expanded AES round keys are the usual target.
- Open-source utilities exist for this. The commercial forensic decryption products (for example those from Passware and Elcomsoft) combine the search with the logic to apply a found key to a BitLocker, VeraCrypt or LUKS image.
- Look beyond keys. The memory image may also hold the encryption software's own structures (mounted volumes, their paths and their state) and cached passwords or recovery keys in plaintext.
Record every candidate key: its offset in the memory image, and the tool and version that found it.
- A key that works is verified by the result: the decrypted volume presents a valid filesystem whose structures can be parsed.
- A key that does not work is kept and noted. It may be for a different volume, or the volume may be damaged (below).
Work the legitimate recovery sources
If memory gives you nothing usable, or was not captured, work through the sources the organisation legitimately holds. In each case act with authority and record the request and the response.
- Active Directory. BitLocker recovery passwords are commonly escrowed against the computer object. Search by the recovery key identifier recorded from the volume metadata.
- Microsoft Entra ID. Devices joined to Entra ID escrow BitLocker recovery keys against the device record.
- Enterprise key escrow maintained by the encryption product itself, and the administrative consoles of endpoint encryption products.
- Mobile device management systems, which frequently hold recovery keys for the devices they manage.
- Authorised corporate password vaults, with the vault administrator retrieving and recording the entry.
- Recovery keys printed, saved to a file, saved to a USB device or stored in a user's cloud account. Any of these may turn up on other seized media.
- Administrator-held credentials, including local administrator accounts and break-glass accounts.
- Keyfiles for products that support them, which may be on removable media or elsewhere on the system.
- Backups. A backup of the same data taken before encryption, or an unencrypted backup of an encrypted volume, may make decryption unnecessary for the material that matters.
Crack passwords last
Only after the sources above are exhausted, and only with authority:
- Extract the authentication material (the BitLocker metadata, the LUKS header, the VeraCrypt volume header) from a working copy.
- Attack that extract on separate hardware, with dictionaries, rules and any candidate words obtained lawfully from the investigation (other recovered passwords, names, dates).
- Record the tool, version, attack configuration, duration and outcome.
Stop and think
Never attack the original evidence, and never attack the working image in place.
- "Not recovered" is a finding in its own right. Report it as carefully as a success.
- Be realistic. A strong passphrase with a modern key derivation function is not recoverable by brute force in any useful time. A report that implies otherwise misleads the reader, so state the limitation.
Treat a rejected key as a hypothesis, not a verdict
When a key, password or recovery key is rejected, do not conclude that it is wrong. Consider, and test for, each of these:
| Possible cause | Test |
|---|---|
| Volume header or metadata corrupted | Try the backup metadata: BitLocker's additional copies, the LUKS2 secondary header, VeraCrypt's backup header at the end of the volume. |
| Volume offset wrong | The partition table is damaged and the tool is looking at the wrong sector for the header (section 18). |
| Image incomplete in the header region | Check the ddrescue map. |
| Key belongs elsewhere | It may be for a different volume, container or hidden volume. |
| Wrong assumptions | Check the tool version, key derivation parameters and cipher. |
Record each hypothesis tested and its result. A decryption that succeeds only after the header is reconstructed from a backup copy has produced a derived artefact (the decrypted volume) by a method that must be described. The header reconstruction is itself a finding to report.
Work with the decrypted volume
- Decrypt to a new file, never in place.
- Treat it as a derived artefact: hash it, record the tool, version, key source and command, and use it as a new working copy.
- The encrypted image remains the master.
- Make it reproducible. Another examiner given the encrypted image and the key must be able to produce a byte-identical decrypted volume, and the hash proves it.
Example
A workstation image contains a BitLocker system volume and a second partition of uniform high entropy with no signature. The memory image yields an AES key schedule at a recorded offset, which decrypts the BitLocker volume; the hash of the decrypted volume is recorded and a colleague reproduces the decryption from the same inputs. No key found in memory decrypts the second partition. The system volume shows VeraCrypt installed and a drive letter history for a mounted volume. The report states, as observed facts, the entropy measurement, the VeraCrypt installation and the drive letter history; as interpretation, that the partition is probably a VeraCrypt volume; and, as a limitation, that it was not decrypted and its contents are unknown.
Before you move on
- Encryption technology identified from the image, and entropy measured.
- Memory searched; every candidate key recorded with its offset, tool and version.
- Legitimate recovery sources worked with authority, requests and responses recorded.
- Any cracking done on an extract, on separate hardware, with the outcome reported either way.
- Decrypted volume written to a new file, hashed and reproducible from the same inputs.