iblai-vibe-security-incident-triage

/iblai-vibe-security-incident-triage

Drive rapid triage and initial response to a security incident. Follow NIST SP 800-61 methodology.

Do NOT power off affected hosts — volatile memory is evidence. Do NOT recommend retaliation or "hacking back."

Priorities

In this order, no exceptions:

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

Pin the 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

Pin the 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

Match the action to type and severity:

• Network: block suspicious IPs/domains at the firewall
• Host: isolate the affected system (network-disconnect — NOT power off; volatile memory is evidence)
• Account: disable compromised accounts, force password resets
• Application: disable the 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):

# 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 paths:

• Process tree: unusual names, paths, or parent-child relationships
• Network indicators: unusual outbound connections, DNS to suspicious domains, beaconing patterns (regular intervals)
• File indicators: recently modified files in unusual locations, hidden files, new executables
• Log analysis: auth failures, privilege escalation, service changes, cleared logs
• Persistence: crontab, systemd units, registry Run keys, scheduled tasks, startup items

Step 5: IOC Extraction

Document every indicator 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

# 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

• Defense and containment, not counter-attack.
• Preserve evidence — never modify logs or timestamps.
• Recommend legal/management escalation for confirmed breaches.
• If a containment action's blast radius is unclear, ask before running it.
• 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