briiirussell / incident triage
Guide rapid triage and initial response to security incidents following NIST SP 800-61 methodology.
Category: skill Author: npub1carj2jw…h8c9 Date: 12 May 2026 Votes: 0
---
name: incident-triage
description: "Guide rapid triage and initial response to security incidents following NIST SP 800-61 methodology. Use when the user mentions 'incident response,' 'security incident,' 'triage,' 'we've been hacked,' 'breach,' 'compromised,' 'malware detected,' 'suspicious activity,' 'IOC,' 'indicators of compromise,' or needs help handling a security event."
allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch
---
# Incident Triage — Security Incident Response
Guide rapid triage and initial response to security incidents. Follow NIST SP 800-61 methodology.
## Priorities (in order)
1. Preserve human safety
2. Contain the incident to prevent further damage
3. Preserve evidence for investigation
4. Identify root cause and scope
5. Document everything
## Step 1: Classification
Determine incident type:
- **Malware:** ransomware, trojan, worm, cryptominer
- **Unauthorized access:** compromised credentials, exploitation
- **Data exfiltration:** data theft, insider threat
- **Denial of service**
- **Web compromise:** defacement, skimming, backdoor
- **Phishing / social engineering**
Determine severity:
- **Critical:** active data exfiltration, ransomware spreading, critical system compromise
- **High:** confirmed compromise, malware detected, unauthorized access
- **Medium:** suspicious activity, potential indicators, failed attacks
- **Low:** policy violation, reconnaissance detected, likely false positive
## Step 2: Initial Containment
Based on type and severity:
- **Network:** block suspicious IPs/domains at firewall
- **Host:** isolate affected system (network disconnect, NOT power off — volatile memory is evidence)
- **Account:** disable compromised accounts, force password resets
- **Application:** disable affected service if safe to do so
**Critical: Do NOT power off systems.** Volatile memory contains evidence.
## Step 3: Evidence Preservation
Capture in order of volatility (most volatile first):
```bash
# 1. Running processes
ps auxf # Linux
tasklist /v # Windows
# 2. Network connections
ss -tupn # Linux
netstat -anob # Windows
# 3. Logged-in users
who -a # Linux
query user # Windows
# 4. Open files
lsof -nP # Linux
# 5. System logs
journalctl --since "1 hour ago" # Linux/systemd
```
If memory forensics tools are available (LiME, WinPmem), capture a memory dump before anything else.
## Step 4: Initial Analysis
For each suspicious indicator, document:
- **What:** describe the artifact
- **When:** timestamps in UTC
- **Where:** affected system(s)
- **How:** how it was detected
Common analysis:
- **Process tree:** look for unusual process names, paths, or parent-child relationships
- **Network indicators:** unusual outbound connections, DNS queries to suspicious domains, beaconing patterns (regular intervals)
- **File indicators:** recently modified files in unusual locations, hidden files, new executables
- **Log analysis:** authentication failures, privilege escalation, service changes, cleared logs
- **Persistence:** crontab, systemd units, registry Run keys, scheduled tasks, startup items
## Step 5: IOC Extraction
Extract and document all indicators of compromise:
| Type | Examples |
|------|---------|
| IP addresses | Source and destination IPs |
| Domains | C2 domains, phishing domains |
| File hashes | MD5 and SHA256 of suspicious files |
| File paths | Malware locations, dropped files |
| Email addresses | Phishing sender addresses |
| URLs | Malicious URLs, C2 endpoints |
| User agents | Unusual or known-malicious user agents |
## Output Format
```markdown
# Incident Triage Report
## Incident ID: [ID]
## Date/Time: [UTC]
## Severity: [Critical/High/Medium/Low]
## Classification: [incident type]
## Status: [Triage/Contained/Analyzing/Resolved]
### Summary
[2-3 sentence overview]
### Affected Systems
| Hostname | IP | Role | Status |
|----------|-----|------|--------|
### Timeline
| Time (UTC) | Event | Source | Notes |
|------------|-------|--------|-------|
### Indicators of Compromise
| Type | Value | Context | Confidence |
|------|-------|---------|------------|
### Containment Actions Taken
- [ ] [Action and result]
### Evidence Preserved
| Type | Location | Hash | Notes |
|------|----------|------|-------|
### Recommended Next Steps
1. [Immediate priority]
2. [Short-term action]
3. [Follow-up investigation]
### Escalation Checklist
- [ ] Management notified
- [ ] Legal notified (if data breach)
- [ ] Law enforcement (if applicable)
- [ ] Affected parties notified (if data breach)
```
## Boundaries
- Focus on defense and containment, not counter-attack
- Preserve evidence — never modify logs or timestamps
- Recommend legal/management escalation for confirmed breaches
- If unsure about a containment action's impact, advise caution and ask
- Never recommend "hacking back" or retaliatory actions
- Refuse requests to cover up incidents or tamper with evidence
## References
- NIST SP 800-61r2: Computer Security Incident Handling Guide
- SANS Incident Handler's Handbook
- MITRE ATT&CK Framework
Discussion