Incident Responder

• Outcome: Review
• Latest audit: Jul 4, 2026 · 9:01 PM UTC
• Version: 1.0.0

Overview

This incident-response skill is mostly purpose-aligned, but it includes powerful live containment and evidence-collection commands without enough enforced safeguards.

Install only if you are using it in an authorized incident-response environment. Treat its command blocks as operator playbooks, not safe automation: review every sudo command, confirm targets manually, capture hashes yourself, store evidence securely, and prepare rollback steps before firewall or account-containment actions.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (18)

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The skill claims that all evidence is SHA-256 hashed on collection to preserve chain of custody, but the provided collection workflows do not actually compute or record hashes for the acquired artifacts. This creates a dangerous mismatch between operator expectations and actual forensic rigor, potentially undermining evidence integrity, incident decisions, and legal defensibility.

Intent-Code Divergence

Low

• Confidence: 94% confidence
• Finding: The 'read-only by default' claim is inaccurate because normal evidence collection writes case files, creates directories, and stores outputs on the target filesystem. While this is expected operationally, the misleading claim can cause responders to underestimate system modification and forensic contamination risks.

Intent-Code Divergence

Medium

• Confidence: 99% confidence
• Finding: The skill states that containment requires confirmation, but the provided functions execute disruptive actions immediately once called, including firewall changes, session termination, account locking, and full network quarantine. This discrepancy increases the chance of accidental self-inflicted outages or irreversible incident-response mistakes under pressure.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The ransomware playbook includes raw memory and disk acquisition with dd near operational guidance but without a strong local warning about performance impact, storage overwrite risk, legal/privacy implications, and the possibility of destabilizing a live system. In incident conditions, responders may run these commands hastily and damage evidence quality or business operations.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The packet capture command can collect sensitive traffic contents, credentials, and personal data, but the playbook does not pair it with an explicit privacy, scope, or authorization warning. In regulated environments this can create compliance exposure and unnecessary overcollection during active response.

External Transmission

Medium

• Category: Data Exfiltration

Content

echo ""
echo "--- Known-Bad IP Check ---"
while IFS= read -r ip; do
  result=$(curl -s -X POST "http://localhost:8765/aynops/reputation" \
    -H "Content-Type: application/json" \
    -d "{\"ip\": \"$ip\"}" 2>/dev/null)
  score=$(echo "$result" | jq -r '.abuse_score // 0')

• Confidence: 87% confidence
• Finding: The PCAP analysis workflow transmits destination IPs derived from captured traffic to a local HTTP service for reputation checks. Even though the endpoint is localhost, this is still external disclosure to another component and may leak sensitive investigation data to a service boundary with separate logging, retention, or compromise risk.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# Capture memory
echo "--- Memory Dump ---"
if [ -f /dev/fmem ]; then
  sudo dd if=/dev/fmem of="$MEMDUMP" bs=1M 2>&1
  echo "Memory dump: $MEMDUMP"
else
  echo "  /dev/fmem not available — install fmem kernel module"

• Confidence: 92% confidence
• Finding: The memory forensics workflow uses sudo dd against /dev/fmem to acquire memory, which is highly privileged and potentially disruptive on a live system. In the context of an incident-response skill this is operationally relevant, but it remains dangerous because misuse can expose all resident secrets or destabilize the host.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

echo "Memory dump: $MEMDUMP"
else
  echo "  /dev/fmem not available — install fmem kernel module"
  echo "  Alternative: sudo dd if=/dev/mem of=$MEMDUMP bs=1M"
fi

# If volatility is available, analyze

• Confidence: 89% confidence
• Finding: The alternative suggestion to read /dev/mem with sudo dd is also a highly privileged and risky acquisition method. It can expose sensitive memory contents and may not be safe or supported on modern systems, making it hazardous if followed uncritically.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

block_ip() {
  IP="$1"
  echo "Blocking $IP at iptables..."
  sudo iptables -A INPUT -s "$IP" -j DROP
  sudo iptables -A OUTPUT -d "$IP" -j DROP
  echo "$IP blocked: $(date)" >> "$CASEDIR/blocked-ips.txt"
}

• Confidence: 97% confidence
• Finding: The block_ip function performs immediate privileged firewall modifications with sudo iptables. In an incident-response context this may be legitimate, but without validation, rollback, or confirmation it can block critical traffic or be abused to cause denial of service.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

IP="$1"
  echo "Blocking $IP at iptables..."
  sudo iptables -A INPUT -s "$IP" -j DROP
  sudo iptables -A OUTPUT -d "$IP" -j DROP
  echo "$IP blocked: $(date)" >> "$CASEDIR/blocked-ips.txt"
}

• Confidence: 97% confidence
• Finding: This second iptables command extends the same risk by immediately altering outbound policy for a supplied IP. A mistaken or maliciously supplied value could interrupt business communications or response workflows.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

kill_connections_to_ip() {
  IP="$1"
  echo "Killing connections to $IP..."
  sudo ss -K dst "$IP"
  echo "Connections to $IP terminated: $(date)" >> "$CASEDIR/terminated-connections.txt"
}

• Confidence: 96% confidence
• Finding: The function kills connections to a provided destination using sudo ss -K, which is a disruptive privileged action. Used incorrectly, it can sever responder access, terminate legitimate business sessions, or interfere with evidence preservation.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

revoke_user() {
  USER="$1"
  echo "Revoking sessions for $USER..."
  sudo pkill -KILL -u "$USER"
  sudo passwd -l "$USER"
  echo "User $USER locked: $(date)" >> "$CASEDIR/locked-accounts.txt"
}

• Confidence: 97% confidence
• Finding: The revoke_user function uses sudo pkill -KILL -u to terminate all processes for a user, which is an immediate disruptive privileged action. This can destroy volatile evidence, interrupt services running under service accounts, or lock out legitimate users during a chaotic incident.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

USER="$1"
  echo "Revoking sessions for $USER..."
  sudo pkill -KILL -u "$USER"
  sudo passwd -l "$USER"
  echo "User $USER locked: $(date)" >> "$CASEDIR/locked-accounts.txt"
}

• Confidence: 97% confidence
• Finding: Locking an account with sudo passwd -l is a privileged state-changing action that can disrupt authentication dependencies and service continuity. In incident response this may be necessary, but without safeguards it creates outage and recovery risks.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# Quarantine system
quarantine_system() {
  echo "Quarantining system — dropping all non-loopback traffic..."
  sudo iptables -P INPUT DROP
  sudo iptables -P FORWARD DROP
  sudo iptables -P OUTPUT DROP
  sudo iptables -A INPUT -i lo -j ACCEPT

• Confidence: 98% confidence
• Finding: The quarantine_system function changes the default INPUT policy to DROP via sudo iptables, a powerful privileged action that can immediately cut off access. In the skill context this is intentionally destructive containment, so the danger is elevated by its lack of enforced confirmation or safety checks.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

quarantine_system() {
  echo "Quarantining system — dropping all non-loopback traffic..."
  sudo iptables -P INPUT DROP
  sudo iptables -P FORWARD DROP
  sudo iptables -P OUTPUT DROP
  sudo iptables -A INPUT -i lo -j ACCEPT
  sudo iptables -A OUTPUT -o lo -j ACCEPT

• Confidence: 98% confidence
• Finding: Dropping FORWARD traffic by default can isolate segments or break routing functions unexpectedly. Without context checks, executing this on the wrong host may cause wider network disruption than intended.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

echo "Quarantining system — dropping all non-loopback traffic..."
  sudo iptables -P INPUT DROP
  sudo iptables -P FORWARD DROP
  sudo iptables -P OUTPUT DROP
  sudo iptables -A INPUT -i lo -j ACCEPT
  sudo iptables -A OUTPUT -o lo -j ACCEPT
  echo "System quarantined: $(date)" >> "$CASEDIR/quarantine.txt"

• Confidence: 98% confidence
• Finding: Changing default OUTPUT policy to DROP can sever telemetry, remote management, and business traffic instantly. This is especially risky during response because it can interrupt evidence export and coordination.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo iptables -P INPUT DROP
  sudo iptables -P FORWARD DROP
  sudo iptables -P OUTPUT DROP
  sudo iptables -A INPUT -i lo -j ACCEPT
  sudo iptables -A OUTPUT -o lo -j ACCEPT
  echo "System quarantined: $(date)" >> "$CASEDIR/quarantine.txt"
}

• Confidence: 95% confidence
• Finding: Adding a loopback ACCEPT rule is itself less dangerous than the default DROP changes around it, but it is part of a privileged quarantine sequence that materially alters host firewall state. The risk is contextual rather than standalone.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

sudo iptables -P FORWARD DROP
  sudo iptables -P OUTPUT DROP
  sudo iptables -A INPUT -i lo -j ACCEPT
  sudo iptables -A OUTPUT -o lo -j ACCEPT
  echo "System quarantined: $(date)" >> "$CASEDIR/quarantine.txt"
}

• Confidence: 95% confidence
• Finding: This loopback OUTPUT ACCEPT rule participates in the same privileged quarantine sequence. While operationally sensible, it still alters firewall state and should not execute without safeguards in an incident workflow.

Static analysis

No suspicious patterns detected.