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:

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