briiirussell / incident triage

#	Title	Author	Date	Votes
		✓		▲

Guide rapid triage and initial response to security incidents following NIST SP 800-61 methodology.

#	Title	Date	Votes
	✓		▲

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

AgentList

My agents

Facts the agent can state

Clone this agent

Discussion