1. Record the Situation Before You Change It
Capture the hostname, logged-on users, IP addresses, current time, alert source, analyst name, and the reason the system is suspicious. Take screenshots of the alert or visible behavior. If the host is business-critical, note the owner and operational impact before containment.
2. Decide Whether Immediate Isolation Is Required
If you have evidence of active command-and-control, ransomware, destructive activity, credential theft, or lateral movement, containment may outrank perfect evidence preservation. Prefer network isolation through EDR or network controls when available rather than powering the host off. A hard shutdown destroys volatile evidence.
3. Capture Volatile State
Document running processes, active network connections, listening ports, logged-on sessions, scheduled tasks, services, and recently launched commands. If your environment has an approved memory-acquisition procedure, volatile memory can provide evidence that never reaches disk.
Get-Process | Sort-Object StartTime -ErrorAction SilentlyContinue
Get-NetTCPConnection | Sort-Object State,RemoteAddress
Get-CimInstance Win32_Process | Select Name,ProcessId,ParentProcessId,CommandLine
Get-ScheduledTask | Where-Object State -ne "Disabled"
Get-CimInstance Win32_Service | Select Name,State,StartMode,PathName4. Preserve the Event Logs That Build the Timeline
Security, System, PowerShell, Windows Defender, Task Scheduler, and relevant EDR logs can reveal authentication, process creation, persistence, service installation, script execution, and security-control changes. Export logs rather than relying only on the live Event Viewer display.
Useful Windows artifacts often include Security events for logon activity, PowerShell operational logs, Defender operational logs, service-control events, and task-scheduler history. Which event IDs are available depends on audit policy and product configuration, so avoid assuming an event will exist merely because Windows supports it.
5. Build a Fast Persistence Sweep
Check startup locations, services, scheduled tasks, Run/RunOnce keys, WMI persistence where applicable, newly created local users, unusual browser extensions, and recently installed software. The goal is not to enumerate every persistence mechanism in existence; it is to find changes that align with the alert timeline.
6. Hash and Preserve Suspicious Files
Get-FileHash "C:\Path\Suspicious.exe" -Algorithm SHA256Record the full path, timestamps, file size, signer information, hash, how the file was discovered, and who collected it. If evidence will be used in a formal investigation, follow your organization’s chain-of-custody procedure instead of improvising one.
7. Pivot From the Host to the Environment
Once you have usernames, hashes, domains, IP addresses, process names, and timestamps, search centralized telemetry. One suspicious workstation may be the first visible node of a broader incident. Look for the same account authenticating elsewhere, the same executable hash on other endpoints, or the same destination contacted by multiple hosts.
The 30-Minute Deliverable
By the end of initial triage, you should have a concise incident note containing the initial alert, containment status, volatile observations, relevant exported logs, suspicious artifacts and hashes, known indicators, likely timeframe, and the next pivots to run across the environment.
Bottom Line
Good Windows incident response is timeline-driven. Preserve context first, contain according to risk, and collect evidence in a way that lets you correlate the endpoint with identity, network, and security telemetry.
← Back to the Blog