8. Windows

13. Preservation, acquisition, analysis

Windows workstations: BitLocker and protected startup

This section applies the general method to a Windows system with full-disk encryption (BitLocker, or a third-party product behaving similarly) and password- or PIN-protected startup. The order of steps matters more here than anywhere else, because a single wrong action can convert an unlocked volume into one that cannot be opened.

BitLocker's components are distinct

BitLocker uses layered keys, and reports that treat them as interchangeable are wrong in ways an opposing examiner will notice:

• The full volume encryption key (FVEK) encrypts the data on the volume. It is what the disk cannot be read without.
• The volume master key (VMK) encrypts the FVEK. It is what the protectors protect.
• Protectors are the ways the VMK can be unlocked: the TPM alone; the TPM with a startup PIN; the TPM with a startup key on USB; a password (on volumes without a TPM); a 48-digit recovery password; and a recovery key file (a .BEK file). A volume commonly has several protectors at once, and the recovery password unlocks it regardless of the state of the TPM or the PIN.
• The TPM releases its share of the VMK only when the measured boot state (firmware, Secure Boot configuration, boot loader, boot order and related measurements) matches what it sealed against. Any change to those measurements makes the TPM refuse, and the system asks for the recovery password.

The user's Windows password is not a BitLocker protector on a TPM system: it unlocks the session, not the volume. The volume is unlocked at boot by the TPM (and PIN, if set), before the user signs in. Consequently a powered-on Windows machine at the sign-in screen normally has its system volume already unlocked and its FVEK in memory.

Powered on and unlocked

1. Do not shut down, restart or sleep the machine. Connect mains power if it is a laptop. Everything below assumes the session stays alive.
2. Photograph and document the screen state, the signed-in user (visible in the start menu or a locked-screen name), connected devices, visible applications, network state (tray icons, link lights) and the displayed date and time against your reference clock (section 3).
3. Isolate from the network by the physical methods in section 4. Disconnecting a cable or removing an adaptor does not end the session or lock the screen; the screen-saver timer might, so work promptly. If the screen does lock, the volume stays unlocked and the keys stay in memory, but you will need a credential to continue (section 2).
4. Acquire memory before anything else (section 7): WinPmem or Magnet RAM Capture from write-protected media, output to your own drive, tool hash and command recorded. Memory may contain the FVEK and VMK, VeraCrypt or other container keys, Windows credentials and hashes, Kerberos tickets, browser session tokens, cached passwords and the plaintext of open documents.
5. Record encryption and system state with the fewest commands that give it. On an elevated prompt, manage-bde -status reports each volume's encryption state, method and protector types, and manage-bde -protectors -get C: lists the protectors and, where a recovery password protector exists, prints the 48-digit recovery password itself together with its identifier. That output is key material: record it to your own media, hash the record and keep it under evidence custody, because it is the most direct route back into the volume after power-off. Then, as needed: tasklist /v for processes, quser for sessions, netstat -ano for connections with owning processes, mountvol and Get-Volume for mounted volumes, and Get-Tpm to record that a TPM is present and ready. Reading state is safe; every command is still an interaction and is recorded with its time and output (photograph the window or redirect to your media).
6. Take a logical acquisition of the decrypted filesystem where the volume cannot be decrypted later with confidence, or where speed matters: an acquisition tool run from your media that copies the live volume's files with their metadata to your drive, or a logical image in a container format. This is a derived artefact taken from a running system: files open for writing may be inconsistent, and the tool's reads may update last-access times, depending on the volume's last-access setting, which varies with the Windows version and volume size and is recorded rather than assumed. Alternatively, and often better, image the decrypted volume as a block device from the live system with a forensic imager that can read a logical volume; it yields a filesystem image including unallocated space, in plaintext.
7. Shut down and acquire the physical storage (section 8). Removing power is usually preferred; record the method. The physical image contains the BitLocker volume as ciphertext together with its metadata, and can be decrypted later with any key recovered.
8. Hash and verify the memory image, the logical acquisition and the physical image (section 9), and record which of them are plaintext and which are ciphertext.

Actions that can remove access permanently

Do not do any of the following on the original machine unless a documented decision, with authority, requires it:

• Rebooting. Clears memory, ends the session and, if any measured component has changed, drops the machine into recovery mode at the next boot.
• Changing BIOS or UEFI configuration, including boot order to boot a forensic USB. This changes the measurements the TPM sealed against. A machine that was unlocking itself at boot will ask for a recovery password you may not have.
• Changing Secure Boot settings, for the same reason.
• Disturbing TPM state: clearing the TPM, updating its firmware, or physically moving the drive to another machine. A cleared TPM destroys its share of the VMK; only a recovery password or key can open the volume afterwards.
• Suspending, disabling or modifying encryption (manage-bde -protectors -disable, manage-bde -off, or the control panel equivalents). Suspending writes the VMK to the disk in the clear and changes the volume's state; turning encryption off rewrites the whole volume. Both alter the evidence and neither is needed to acquire it.
• Adding or changing protectors "to make sure we can get back in". It changes BitLocker metadata on the evidence. Recover keys through the routes below instead.

Powered off

• Leave it off. Do not attempt to boot it, and do not try passwords or PINs at a pre-boot prompt; the TPM's anti-hammering logic and the recovery-mode trigger both count against you.
• Image the storage first (section 8), through a write blocker. The image is complete evidence whether or not it is ever decrypted.
• Identify the mechanism from the image: BitLocker's volume signature and metadata (readable with the libbde tools or a forensic suite) give the encryption method, the protector types and the recovery password identifier. A third-party product is identified by its boot loader, driver files and configuration on the system volume.
• Work the lawful recovery sources in section 12 in the order they are likely to succeed for a Windows machine: BitLocker recovery passwords escrowed in Active Directory (against the computer object) or in Microsoft Entra ID (against the device record, for joined or registered devices); the enterprise key management or endpoint encryption console; the user's Microsoft account, which stores recovery keys for devices encrypted under a personal account and can be accessed by the account holder or under lawful process; authorised password managers; and recovery keys found on other seized media, as .BEK files on USB devices, as printed 48-digit passwords, or as text files.
• With a recovery password or key, decrypt a working copy to a new image (section 12), for example with the dislocker or libbde tools, which present a read-only decrypted view that is then imaged and hashed. The FVEK, if recovered from a memory image, is applied the same way. Record which component was used.

Windows-specific examination notes

Beyond the filesystem work in sections 18 and 19, the artefacts that most often matter on Windows are the registry hives (system, software, security, and each user's), event logs, prefetch, shimcache and amcache for execution, link files and jump lists for file access, the USB device and mounted-device keys, the change journal and log file on NTFS (section 18), volume shadow copies (earlier versions of files and of the hives), the hibernation file and page file (section 7), and per-user application data. NTFS alternate data streams are covered in section 17.

Example. A laptop at the sign-in screen, powered on, with a BitLocker padlock shown in the tray of a second user's session in the switch-user list. The system volume is unlocked; the sign-in screen is not a pre-boot prompt. The examiner isolates the machine, obtains the local administrator credential from IT with authority, signs in (recorded), captures memory, records the BitLocker status showing a TPM-and-PIN protector with no escrowed recovery password, images the unlocked system volume logically, then removes power and images the drive. Later, the FVEK found in the memory image decrypts the physical image to the same file hashes as the logical acquisition, which is recorded as corroboration of both.