Evidence Preservation After a Delayed PowerShell Intrusion Report
A finance team of 25 users reports that an Excel file opened 11 days ago spawned PowerShell. Harmony Endpoint raised an EDR alert, but no one reviewed it until today. Five endpoints are involved: three are online, one was reimaged two days ago, and one has been offline for eight days. Forensic backup retention is seven days. The SIEM keeps endpoint logs for 30 days, but the endpoint management console only shows seven days of client activity. There is no packet capture. The reimaged laptop was used by an executive assistant who also accessed the shared finance drive. The team wants to know whether credentials were stolen and whether the incident is contained. The management server is healthy and has no sign of compromise.
1. What evidence is still recoverable, and what is likely lost? Prioritize preservation actions.
Read the worked answer
Recoverable: SIEM endpoint logs for 30 days, including process creation, network connections, and possibly PowerShell script-block logging if enabled; management-console audit and policy events for seven days; the three online endpoints' current process tree and memory; the offline endpoint's local logs and disk when it reconnects; and email/web gateway logs if the file arrived by email. Likely lost: forensic backups older than seven days for the three online machines, anything on the reimaged laptop beyond backup or SIEM records, and network packet capture. Preservation order: export SIEM events for all five users and hosts now; capture volatile data from the online machines before reboot; image or export forensic data from the offline machine before it connects and receives new policy; and place a legal hold on the reimaged laptop's backup and ticketing records. Do not reimage or clean the three online hosts until evidence is captured.
2. How would you scope credential theft and lateral movement with this telemetry? Give concrete indicators and data sources.
Read the worked answer
Start with the PowerShell command line and parent process on each host, then look for credential-access indicators: LSASS access, sekurlsa, Invoke-Mimikatz, procdump on LSASS, suspicious net use, whoami /priv, and new service creation. Pivot on the user accounts that logged into the five hosts and the executive assistant's account, then search SIEM for those accounts across all endpoints and the file server. Check for SMB connections from the five hosts to other finance systems, unusual admin shares, and new scheduled tasks. Review email gateway logs for the original attachment and outbound mail from the affected users. Check the file server for files created or modified around the alert time. If PowerShell script-block logging was not enabled, the SIEM may still have process-creation events; use EDR threat hunting to query the same indicators on all 25 finance endpoints.
3. What remediation and retention changes do you recommend, and how do you avoid destroying evidence while containing?
Read the worked answer
Contain accounts and network paths first: reset passwords for the five users and any shared finance accounts, revoke active sessions, and block known command-and-control indicators. Isolate the three online hosts for forensic capture, then reimage them after evidence export. Treat the reimaged laptop as potentially compromised until SIEM and backup review show no credential use after the incident. Reimage rather than clean. Hunt the same indicators across the finance team and then the estate. For retention, extend endpoint forensic backup and SIEM retention to at least 30–90 days, enable PowerShell script-block and command-line logging, and forward endpoint logs centrally so console retention is not the only copy. Preserve evidence in a separate case folder with hashes before remediation. Finally, test the detection path so an EDR alert is triaged within hours, not 11 days.