Encrypted volumes: BitLocker, FileVault and VeraCrypt

Volume and container encryption is now the default on many laptops. This lesson covers how to recognize BitLocker, FileVault, LUKS and VeraCrypt volumes in an image or a triage collection, how BitLocker's keys are layered, which lawful key sources and live-system opportunities exist, and how to report what could not be examined. Password guessing is a separate, authority-dependent process and is not covered here.

Obstacle or anti-forensics?

Encryption is usually legitimate: privacy, data protection policies, and operating systems that enable it automatically. Treat it first as an obstacle. It is an anti-forensic act only when context supports that, for example a container disguised with a misleading name, created or used around the incident, or software run and then removed. State that inference separately from the technical finding.

Recognizing encrypted volumes

BitLocker

A BitLocker volume keeps an unencrypted volume header whose OEM identifier at offset 3 is the 8-byte string -FVE-FS-, where an NTFS volume shows NTFS followed by four spaces. The volume also holds three copies of the FVE metadata block (Full Volume Encryption), each also starting with -FVE-FS-; they record the encryption method, the key protectors and the wrapped keys. Windows 10 version 1511 introduced XTS-AES; earlier versions used AES-CBC. On removable drives, BitLocker To Go volumes that were FAT-formatted can show a FAT32-style header with OEM identifier MSWIN4.1, so searching the volume for -FVE-FS- still finds the metadata blocks.

On a live system, manage-bde -status reports per volume the Conversion Status, Percentage Encrypted, Encryption Method, Protection Status, Lock Status and Key Protectors. The event log channel Microsoft-Windows-BitLocker/BitLocker Management (file Microsoft-Windows-BitLocker%4BitLocker Management.evtx) records events such as encryption starting, protectors being added or removed, and recovery information being backed up. Event IDs differ between Windows versions, so filter by channel and read the message text.

FileVault

On a Mac, FileVault protects the APFS Data volume. An APFS volume superblock without the APFS_FS_UNENCRYPTED flag (0x1 in apfs_fs_flags) is encrypted. On T2 and Apple silicon Macs this is true of every internal volume even with FileVault off, so the flag alone does not show that FileVault is on. As Lesson 1.7 explained, Macs with a T2 chip or Apple silicon always encrypt internal storage in hardware; FileVault adds the requirement that a user's credentials unlock the key. Live, fdesetup status reports "FileVault is On."

LUKS

Linux Unified Key Setup starts with the 6-byte magic LUKS\xba\xbe (4C 55 4B 53 BA BE) at offset 0, followed by a 2-byte version: 1 or 2. LUKS1 has a 592-byte binary header with eight keyslots and uses PBKDF2. LUKS2 has a 4,096-byte binary header followed by JSON metadata, a second header copy whose magic is SKUL\xba\xbe, up to 32 keyslots and Argon2id as the usual default. Each keyslot holds the volume key encrypted with one passphrase or key file.

VeraCrypt and TrueCrypt

VeraCrypt, the successor of TrueCrypt (discontinued in 2014), writes no plaintext signature. The header starts with a 64-byte random salt; the magic VERA (or TRUE) appears only after the header is decrypted with the right password. A container file or partition therefore looks like random data. Indicators are:

• Shannon entropy close to the 8 bits/byte maximum, across the whole object;
• a size that is a multiple of 512 bytes;
• no recognizable file signature, often with an extension or name that suggests something else.

These are indicators, not proof: wiped space (Lesson 7.1), random test data and other encryption tools look the same. Compressed files also have high entropy but carry headers such as PK or 7z. System encryption is easier to spot, because the VeraCrypt boot loader replaces the normal one (on UEFI systems under \EFI\VeraCrypt\ on the EFI system partition).

A VeraCrypt hidden volume sits inside the free space of an outer volume, which is filled with random data, so its presence cannot be proven or excluded from the container alone. Only other artifacts, such as LNK files pointing to paths that do not exist in the opened outer volume, can support the claim. Never assert either way without such evidence.

Software artifacts

When the container cannot be identified directly, the software use can be. Look for VERACRYPT.EXE and VERACRYPT FORMAT.EXE Prefetch files, Amcache and BAM entries (Lesson 2.3), and the driver %windir%\System32\drivers\veracrypt.sys (absent in portable mode). %APPDATA%\VeraCrypt\ (in portable mode, the folder holding VeraCrypt.exe) holds Configuration.xml (preferences, including auto-dismount settings), and, only if those features were used, Favorite Volumes.xml (saved volumes and their drive letters) and History.xml (the last 20 volume paths; "Never save history" is enabled by default). Mounted volumes can leave drive-letter traces: a \DosDevices\Z: value in MountedDevices whose data matches no known disk, and LNK files and Jump Lists (Lesson 2.4) whose target volume serial number matches no known volume.

BitLocker key architecture

BitLocker uses three layers. The sectors are encrypted with the FVEK (full volume encryption key). The FVEK is stored in the metadata, encrypted with the VMK (volume master key). The VMK is stored several times, once wrapped by each key protector. Adding or removing a protector only adds or removes a wrapped copy of the VMK; the data is not re-encrypted.

Protectors include TPM only (the Trusted Platform Module releases the VMK if the measured boot chain is unchanged), TPM + PIN, TPM + startup key, a password (typical for data and removable drives), a startup key or recovery key file (.BEK), the recovery password and auto-unlock (a data drive opened automatically once the OS volume is unlocked). Every protector has a GUID key ID; the recovery screen shows the start of it, so a recovered password can be matched to the right volume.

The recovery password has 48 digits in eight groups of six. Each group encodes 16 bits multiplied by 11, so every valid group is divisible by 11 and at most 65,535 × 11 = 720,885; eight groups give the 128-bit key. This is a format check, not proof that a value belongs to a volume.

A recovery password may legitimately be stored in:

• the user's Microsoft account, on its recovery keys page;
• Active Directory, as msFVE-RecoveryInformation objects under the computer object (attribute msFVE-RecoveryPassword), or Entra ID, on the device object;
• MBAM or Intune management databases;
• a printout, a text file or a USB drive, saved by the user.

Many Windows 11 devices turn on Device Encryption automatically and back the key up to the Microsoft account or the work account at sign-in. If BitLocker is suspended, the VMK is stored with an unencrypted "clear key": the volume remains encrypted but any compatible tool can read it.

Lawful access paths

• The running, unlocked system. Capture memory, then acquire a logical image of the unlocked volume (a physical image only copies ciphertext). Record manage-bde -status and manage-bde -protectors -get C:, which lists each protector's ID and, run as administrator, the numerical recovery password.
• Keys in memory. While a volume is unlocked or mounted, the FVEK or VeraCrypt master key is in RAM (unless VeraCrypt's optional RAM encryption, available since 1.24 and off by default, was enabled; Configuration.xml shows it). Memory analysis tools, including Volatility community plugins and commercial suites, can locate them, and open-source BitLocker libraries can then decrypt an image with the recovered key. Hibernation files and crash dumps may hold them too (Lesson 5.4), but on an encrypted C: only after C: is unlocked.
• TPM-only on the original machine. Booting the original computer unlocks the volume without a secret, although Windows sign-in still protects the session. A drive removed from that machine needs a recovery password.
• Escrowed keys. Request recovery passwords from the organization or provider through legal process, quoting the key ID.
• The owner. Asking for a password is possible; the legal framework varies by country.
• FileVault: a user password, the personal recovery key (24 characters in six groups of four), an institutional recovery key or MDM escrow, or the live, unlocked Mac.
• VeraCrypt and LUKS: the password or key file, or the key in memory while mounted; image the mapped volume while it is open.

Time matters. A mounted volume is lost at shutdown, and VeraCrypt can be configured to dismount on logoff, session lock, screen saver, power saving or a period without reads and writes. Triage decisions (Lesson 5.1) often decide whether encrypted data is ever read.

Worked example: a laptop in standby

A Windows 11 laptop is seized in standby with the screen locked. Triage shows BitLocker with a TPM-only protector on C:, and on D: a file D:\backup\photos.bin with no known header. The system has VeraCrypt Prefetch files and a LNK file pointing to Z:\clients\list.xlsx on a volume whose serial appears nowhere else.

Sequence. Connect the charger, photograph the screen and prevent hibernation. Live acquisition needs an authenticated session, so obtain credentials lawfully from the owner or organization. Then:

1. Memory first. It may hold the VeraCrypt master key and the BitLocker FVEK.
2. Z: next, if still mounted. Photograph the VeraCrypt window, which shows the mounted file path and volume type, and take a logical image of Z:. This data has no other route, and an inactivity dismount could close it while you work on C:.
3. C: last. Record manage-bde -status and the protector IDs, then take a logical image of C:. C: has fallbacks: the TPM on the original machine and any escrowed recovery password.

The file. Its size is 4,294,967,296 bytes = 4 GiB = 2^32 bytes = 8,388,608 × 512, an exact multiple of 512. Its entropy, averaged over 1 MiB blocks, is 7.9998 bits/byte, which is what random data gives at that block size (small-sample bias keeps it just under 8). With VeraCrypt execution evidence, the correct statement is: photos.bin is consistent with an encrypted container, such as a VeraCrypt file container; this is not proven. If it is later opened lawfully and its file system's volume serial matches the LNK file, that links it to Z:.

Recovery password check. A valid example built for this lesson is 403425-176198-692373-264044-664609-429165-106161-702482. First group: 403,425 ÷ 11 = 36,675 exactly (11 × 36,675 = 403,425), and 36,675 is below 65,536. A transcription error such as 403,426 leaves remainder 1 and fails.

Reporting

State that a volume is encrypted and which technology; how it was identified (signature and offset, metadata, entropy measurement and block size, software artifacts); which keys were sought, from where and with what result, including key IDs; what was acquired live and when (UTC); and what could not be examined. Keep inferences about intent apart. ISO/IEC 27037 expects each live action to be justified and documented.

Exam focus: Expect to recognize BitLocker from -FVE-FS- at offset 3, to explain the FVEK, VMK and protector layers, and to validate recovery password groups by divisibility by 11. Scenario questions are likely to test acquisition order on a running system with a mounted container, and the careful wording that a high-entropy file without a header is consistent with, not proof of, an encrypted container.

Key points

• BitLocker shows -FVE-FS- at offset 3 and in its FVE metadata blocks; LUKS starts with LUKS\xba\xbe; VeraCrypt has no plaintext signature.
• High entropy, a size divisible by 512 and no header indicate a possible container but do not prove one; hidden volumes can be neither proven nor excluded from the container alone.
• Sectors are encrypted by the FVEK, the FVEK by the VMK, and the VMK by each protector.
• A recovery password has eight six-digit groups, each divisible by 11; match it by key ID.
• Capture memory and logical images while volumes are unlocked, prioritizing what has no other key source.
• Report the encryption, how it was identified, the key sources tried and what remains unexamined.