Ransomware on a Powered-Off BitLocker Laptop
A finance employee reports that her Windows 10 laptop will not open documents and shows a note named READ_ME.txt demanding payment in Monero. Files now have the extension .locked, and the user powered the laptop off before calling the help desk. The laptop has a 1 TB NVMe SSD with about 200 GB used and BitLocker is enabled. The device is in the office, and the recovery key is escrowed in Intune. The backup team says nightly file backups exist, but the backup server is on the same domain and the backup service account has write access to the file share. The SOC has a write blocker, a forensic workstation, and 4 hours before the incident call with leadership. No memory capture was taken.
1. How do you acquire and preserve the laptop evidence?
Read the worked answer
Do not boot the laptop. Because the device is powered off, volatile memory is already lost; booting would change disk state and may trigger further encryption or logging. Retrieve the BitLocker recovery key from Intune and verify the device identity by asset tag and serial number. Remove the NVMe drive or use a hardware write blocker, then create a forensic image with a tool that records a hash before and after acquisition. If the drive remains in the laptop, boot from a trusted forensic environment, never from the installed OS. Image the full disk, not just the .locked files, and preserve the original drive in a tamper-evident bag with chain-of-custody documentation. Photograph the READ_ME.txt screen and note the exact wording before shutdown if it is still displayed. Because BitLocker is enabled, the image may be encrypted; unlock the image copy with the escrowed recovery key in the forensic suite, not by booting the original. Record the limitation that no memory was captured.
2. How do you determine the ransomware family and likely initial access from disk evidence alone?
Read the worked answer
Start with the ransom note, file extension, and any embedded contact or onion address. Hash the note and search local malware intelligence sources, but verify independently because ransom-note text is often copied. Build a timeline from filesystem metadata: MFT and USN journal for file rename and deletion activity, prefetch for executable execution, Amcache and Shimcache for program presence, and event logs for service installation and log clearing. Check browser history and downloads, email attachments, USB device history, and recent LNK files. Review PowerShell operational logs and Office document recent files for macro or script execution. Look for shadow-copy deletion commands, backup service tampering, and newly created accounts. Identify the encryption start time and the first encrypted file to approximate patient zero. Disk evidence can identify the family and likely delivery vector, but without memory you cannot confirm the running process or recover keys; state that limitation explicitly.
3. What do you tell leadership about recovery and backup risk within the 4-hour window?
Read the worked answer
Lead with business risk, not technical detail. State that the laptop is contained and will not be booted, evidence is being preserved, and the scope is not yet confirmed. The critical finding is that the backup server is domain-joined and the backup service account has write access to the file share, so the backups may be encrypted or deleted. Do not restore from those backups until they are validated on an isolated network. Recommend checking immutable or offline copies, verifying backup integrity, and rotating the backup service account credentials. Advise against paying the ransom and against promising decryption. Provide a timeline for forensic triage, a list of decisions needed from leadership, and clear owners. Note that no memory was captured, so attribution and key recovery are limited. Keep the update concise, mark confidence levels, and avoid speculation about the family until the note and disk artifacts are analyzed.