8. Windows

13. Preservation, acquisition, analysis

Windows workstations: BitLocker and protected startup

In short: keep a live machine alive and capture memory before anything else; leave a dead one off and image it; never change anything the TPM measures.

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. A single wrong action here can convert an unlocked volume into one that cannot be opened.

Know BitLocker's components apart

BitLocker uses layered keys. Reports that treat them as interchangeable are wrong in ways an opposing examiner will notice.

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, but 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 (details below).
6. Take a logical or live volume acquisition of the decrypted filesystem where the volume cannot be decrypted later with confidence, or where speed matters (details below).
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.

Record encryption and system state (step 5)

From an elevated prompt:

• manage-bde -status reports each volume's encryption state, method and protector types.
• manage-bde -protectors -get C: lists the protectors and, where a recovery password protector exists, prints the 48-digit recovery password itself with its identifier.

Then, as needed:

• tasklist /v for processes.
• quser for sessions.
• netstat -ano for connections with owning processes.
• mountvol and Get-Volume for mounted volumes.
• Get-Tpm to record that a TPM is present and ready.

Reading state is safe, but every command is still an interaction. Record each with its time and output (photograph the window or redirect to your media).

Take the live acquisition (step 6)

Avoid the actions that 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

1. 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.
2. Image the storage first (section 8), through a write blocker. The image is complete evidence whether or not it is ever decrypted.
3. 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.
4. Work the lawful recovery sources in section 12, in the order they are likely to succeed for a Windows machine (list below).
5. Decrypt a working copy to a new image with a recovery password or key (section 12), for example with the dislocker or libbde tools, which present a read-only decrypted view that is then imaged and hashed. An FVEK recovered from a memory image is applied the same way. Record which component was used.

Recovery sources for Windows, most likely first:

1. Active Directory: BitLocker recovery passwords escrowed against the computer object.
2. Microsoft Entra ID: escrowed against the device record, for joined or registered devices.
3. The enterprise key management or endpoint encryption console.
4. 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.
5. Authorised password managers.
6. Recovery keys on other seized media: .BEK files on USB devices, printed 48-digit passwords, or text files.

Know where to look in the examination

Beyond the filesystem work in sections 18 and 19, these artefacts most often matter on Windows:

• Registry hives: system, software, security, and each user's.
• Event logs.
• Execution: prefetch, shimcache and amcache.
• File access: link files and jump lists.
• Devices: the USB device and mounted-device keys.
• NTFS history: the change journal and log file (section 18).
• Volume shadow copies: earlier versions of files and of the hives.
• Hibernation file and page file (section 7).
• Per-user application data.
• NTFS alternate data streams: covered in section 17.