Live Windows Host With a Failed Outbound Transfer
At 09:12, a helpdesk analyst escalates a Windows 11 laptop used by a payroll administrator. EDR flagged a PowerShell process that archived Documents and attempted an outbound connection to 198.51.100.77 on TCP 443; the connection failed. The user is still logged in, Outlook and Excel are open, and a USB drive is mounted. The laptop is on corporate Wi-Fi; BitLocker is enabled with a TPM-only protector. The incident commander asks you to preserve evidence and determine whether data left the host. The service desk wants to reboot to clear the alert, and HR wants the user interviewed immediately. You have one 1 TB write blocker, two blank 2 TB drives, and a forensic laptop. The device must be returned to operations within four hours if possible.
1. What acquisition sequence should you use, and why does the order matter in this scenario?
Read the worked answer
Capture volatile state first: RAM, running processes, network connections, logged-on sessions, mounted USB volume identity, and any accessible BitLocker recovery material. Then image the USB and the internal disk, using the write blocker for the USB and a documented live or offline method for the disk. The order matters because the PowerShell process, archive path, and failed connection may exist only in memory or EDR telemetry; a reboot destroys RAM and can change encryption state. Because BitLocker uses a TPM-only protector and the host is running, an offline disk image may later require a recovery key, so obtain or verify escrow access before shutdown. Document every action, hash acquired images, and keep the user interview from altering the host until volatile data is captured.
2. How should you handle the mounted USB drive and the BitLocker state without weakening the evidence?
Read the worked answer
Treat the USB as a separate evidence item. Record its make, model, serial number, and volume identifier from the live system, then power down or isolate as policy permits and image it through the write blocker. Do not open files directly on the forensic workstation. For BitLocker, record protector type and volume state, and obtain the recovery key from enterprise escrow or the live system if authorized. If the disk must be imaged live, use a trusted tool that documents the method and hash; if offline, verify the image decrypts only through controlled procedures. The reasoning is that opening the USB alters access metadata, while mishandling BitLocker can make the disk unreadable or change the evidentiary state.
3. What can you conclude about data exfiltration from the EDR alert alone, and what corroboration would you seek?
Read the worked answer
The alert supports an attempt, not successful exfiltration: it states the outbound connection failed. You can say PowerShell staged an archive and tried to contact 198.51.100.77, but you cannot say data left the host without corroboration. Seek firewall and proxy logs for the destination, DNS resolution records, EDR process and network telemetry, PowerShell history and memory artifacts, the archive itself or its path, USB file listings, and cloud or email logs. If the four-hour return deadline is firm, prioritize volatile capture and imaging, document the shortened window, and return the device only after evidence is secured. The report should separate observed events from inferences and state the failed-connection limitation.