Security Incident Response Cheat Sheet
Covers the standard incident response lifecycle, containment strategies, and evidence handling for effectively managing security incidents.
Incident Response Lifecycle (NIST SP 800-61)
The standard phases of handling a security incident.
- 1. Preparation- Build IR plan, playbooks, tooling, and trained team before an incident occurs
- 2. Detection & analysis- Identify indicators, confirm the incident, determine scope and severity
- 3. Containment- Limit damage: short-term (isolate host) and long-term (patch, rotate creds)
- 4. Eradication- Remove the root cause: malware, backdoors, compromised accounts
- 5. Recovery- Restore systems to normal operation, monitor closely for recurrence
- 6. Post-incident (lessons learned)- Document timeline, root cause, and improvements to prevent recurrence
Quick Triage Commands (Linux Host)
Commands to gather volatile evidence early in an investigation.
# Active network connections and listening portsss -tulnp# Running processes with full command linesps auxww# Recently modified files (last 24 hours)find / -mtime -1 -type f 2>/dev/null# Logged-in users and login historywlast -20# Scheduled tasks (common persistence mechanism)crontab -lls -la /etc/cron.d/
Containment Strategies
Common approaches to stop an incident from spreading.
- Network isolation- Move affected host to a quarantine VLAN instead of full power-off, to preserve volatile evidence
- Disable compromised accounts- Force password reset and revoke active sessions/tokens
- Block indicators of compromise- Deny known malicious IPs/domains/hashes at firewall, proxy, and EDR
- Preserve evidence first- Capture memory/disk images before remediation actions overwrite evidence
Key IR Team Roles
Typical responsibilities during an active incident.
- Incident commander- Coordinates the response, makes final decisions, manages communication
- Security analyst- Performs technical investigation, log analysis, and containment actions
- Legal/compliance- Advises on breach notification obligations and regulatory requirements
- Communications/PR- Manages internal and external messaging about the incident
Volatile Memory Capture Before Shutdown
Order of volatility guides what to capture first on a live compromised host.
# Order of volatility (RFC 3227): registers/cache > routing table/ARP cache ># process table > kernel stats/memory > temp file systems > disk > logs > archived# Dump full RAM with LiME (Linux Memory Extractor) kernel moduleinsmod lime.ko "path=/mnt/evidence/host1.mem format=lime"# Capture volatile network/process state before it rotates outip -s neigh show > arp-cache.txtnetstat -antup > netstat-connections.txtlsof -nP > open-files.txt# Hash the memory image immediately for chain-of-custodysha256sum /mnt/evidence/host1.mem > host1.mem.sha256# Analyze the image offline with Volatility3 (never analyze on the live host)vol3 -f host1.mem windows.pslistvol3 -f host1.mem windows.netscanvol3 -f host1.mem windows.malfind
Chain of Custody & Evidence Handling
Requirements for evidence to remain admissible and trustworthy.
- Document every transfer- Log who accessed evidence, when, and why on a signed custody form
- Hash at collection and after every copy- SHA-256 the original image; verify the hash matches before and after each transfer
- Write-blockers for disk acquisition- Use hardware or software write-blockers so imaging never modifies the source media
- Original vs working copy- Analyze only forensic copies; the original goes into secure, access-logged storage
- Timestamps in UTC- Normalize all timeline evidence to UTC to avoid timezone confusion across systems
- Two-person integrity- Have a second analyst witness and co-sign critical evidence handling steps
Windows Live Triage Collection Script
PowerShell commands to pull key IR artifacts before containment actions destroy them.
# Running processes with parent PID and command line (spot masquerading)Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,CommandLine# Active network connections mapped to owning processGet-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess,State# Persistence: scheduled tasks, run keys, and servicesGet-ScheduledTask | Where-Object {$_.State -ne 'Disabled'}Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'Get-CimInstance Win32_Service | Where-Object {$_.StartMode -eq 'Auto'}# Recently created/modified files (last 24h) - common dropper indicatorGet-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -gt (Get-Date).AddHours(-24) }# Export Windows Event Log security events for offline reviewwevtutil epl Security C:\evidence\security.evtx
Incident Severity & Escalation Tiers
How organizations typically classify incident severity to drive response urgency and staffing.
- SEV1 / Critical- Active data exfiltration, ransomware detonation, or full domain compromise; page IC immediately, 24/7 response
- SEV2 / High- Confirmed unauthorized access with limited blast radius; response within 1 hour, IC engaged
- SEV3 / Medium- Suspicious activity requiring investigation but no confirmed compromise; response within business hours
- SEV4 / Low- Policy violations or low-confidence alerts; tracked and triaged in normal queue
- Escalation triggers- Regulated data involved, executive/privileged account compromised, or public-facing impact — always escalate a tier
IOC Sweep with YARA and Sigma
Turning findings from one compromised host into org-wide detection during containment.
# Sigma rule to hunt for a discovered persistence technique across all hoststitle: Suspicious Scheduled Task Creation via schtasksstatus: experimentallogsource: category: process_creation product: windowsdetection: selection: Image|endswith: '\\schtasks.exe' CommandLine|contains: - '/create' - '/ru SYSTEM' condition: selectionlevel: highfalsepositives: - Legitimate admin task scheduling (rare with /ru SYSTEM outside change windows)# Convert with sigmac/pySigma to your SIEM's query language, e.g. Splunk:# sigma convert -t splunk suspicious_schtasks.yml
Never power off a compromised machine as your first action — it destroys volatile evidence in memory (running processes, network connections, encryption keys); isolate it from the network first, then image memory before shutdown.