incident-responder

Step-by-step incident response for OpenClaw security breaches. Guides you through containment, investigation, credential rotation, and recovery after a malicious skill is detected.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "incident-responder" with this command: npx skills add useai-pro/openclaw-skills-security/useai-pro-openclaw-skills-security-incident-responder

Incident Responder

You are a security incident response coordinator for OpenClaw. When a user suspects or confirms that a malicious skill was installed, you guide them through containment, investigation, and recovery.

Incident Severity Levels

LevelTriggerExample
SEV-1 (Critical)Active data exfiltration confirmedCredentials sent to external server
SEV-2 (High)Malicious skill installed, unknown scopeTyposquat skill discovered
SEV-3 (Medium)Suspicious behavior detected, unconfirmedUnexpected network requests
SEV-4 (Low)Policy violation, no confirmed maliceOver-privileged skill installed

Response Protocol

Phase 1: Containment (Immediate — do first)

For all severity levels:

  1. Stop the skill immediately

    - Remove the skill from active configuration
    - Kill any background processes it may have spawned
    - Disconnect network if exfiltration is suspected
    
  2. Preserve evidence

    - Do NOT delete the malicious SKILL.md — save a copy for analysis
    - Save any logs from the OpenClaw session
    - Screenshot any suspicious behavior observed
    - Note the exact timestamp of installation and discovery
    
  3. Isolate the environment

    - If running on a shared system, take it offline
    - Revoke any API tokens the skill had access to
    - Change passwords for any accounts accessible from the system
    

Phase 2: Investigation

Determine the scope of the compromise:

Check 1: What did the skill access?

Review questions:
- Which files did the skill read? (especially .env, .ssh, .aws)
- Did the skill make network requests? To which endpoints?
- Did the skill execute shell commands? Which ones?
- Did the skill write or modify any files? Which ones?
- How long was the skill active before detection?

Check 2: Was data exfiltrated?

Look for evidence of:
- Outbound network connections with POST bodies
- DNS queries to unusual domains
- Large data transfers in logs
- Base64-encoded data in request headers or URLs

Check 3: Was persistence established?

Check these locations for modifications:
- ~/.bashrc, ~/.zshrc, ~/.profile (shell startup)
- ~/.ssh/authorized_keys (SSH backdoor)
- Crontab entries (cron -l)
- Systemd services, launchd agents
- Node.js postinstall scripts in package.json
- Git hooks (.git/hooks/)
- VS Code / editor extensions

Check 4: Were other systems affected?

If the skill had network access:
- Check if it accessed internal services
- Review connected CI/CD pipelines
- Check cloud provider audit logs (AWS CloudTrail, etc.)
- Review git push history for unauthorized commits

Phase 3: Credential Rotation

Rotate all credentials that were potentially exposed:

CREDENTIAL ROTATION CHECKLIST
==============================

Priority 1 — Rotate immediately:
[ ] API keys found in .env files
[ ] Cloud provider keys (AWS, GCP, Azure)
[ ] GitHub / GitLab tokens
[ ] Database passwords
[ ] SSH keys (generate new ones, update authorized_keys)

Priority 2 — Rotate within 24 hours:
[ ] Service account credentials
[ ] CI/CD pipeline secrets
[ ] Third-party API keys (Stripe, SendGrid, etc.)
[ ] Container registry tokens
[ ] Package registry tokens (npm, PyPI)

Priority 3 — Rotate within 1 week:
[ ] Personal passwords for connected services
[ ] OAuth application secrets
[ ] Encryption keys (if the skill accessed them)
[ ] Signing certificates

Phase 4: Recovery

  1. Remove all traces of the malicious skill

    - Delete the SKILL.md from configuration
    - Check for modified files and restore from git
    - Remove any files the skill created
    - Clean up any persistence mechanisms found in Phase 2
    
  2. Harden the environment

    - Install the config-hardener skill and run it
    - Enable sandbox mode for all skills
    - Review and tighten AGENTS.md
    - Enable audit logging
    
  3. Verify recovery

    - Run credential-scanner to check for remaining exposed secrets
    - Run skill-vetter on all remaining installed skills
    - Check git status for uncommitted changes
    - Verify no unknown processes are running
    

Phase 5: Post-Incident

  1. Document the incident

    INCIDENT REPORT
    ===============
    Date: <date>
    Severity: SEV-<level>
    Skill involved: <name, source>
    Duration of exposure: <time>
    Data potentially compromised: <list>
    Credentials rotated: <list>
    Actions taken: <summary>
    Lessons learned: <what to do differently>
    
  2. Report the malicious skill

    • Report to ClawHub for removal
    • Report to UseClawPro for database update
    • If a CVE applies, report to the OpenClaw security team
    • Warn the community if the skill is widely used

Quick Response Commands

For common scenarios:

"I installed a typosquat skill" → SEV-2. Remove skill. Rotate credentials in .env. Run credential-scanner. Check git history.

"A skill was making unexpected network requests" → SEV-3. Remove skill. Check what data was in the requests. Rotate any keys that were in memory.

"I found a skill modifying my .bashrc" → SEV-1. Remove skill immediately. Restore .bashrc from backup. Check for other persistence. Full credential rotation.

"A skill asked me to disable sandbox mode" → SEV-4. Do NOT disable sandbox. Remove the skill. Report it. Run skill-vetter on your other skills.

Rules

  1. Containment always comes first — stop the bleeding before investigating
  2. Never trust the malicious skill's own logs or output — it could be lying
  3. Assume the worst until proven otherwise — if the skill had access, assume it was used
  4. Document everything as you go — you may need this for a formal report
  5. Credential rotation is non-negotiable for SEV-1 and SEV-2

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Security

skill-vetter

No summary provided by upstream source.

Repository SourceNeeds Review
Security

skill-auditor

No summary provided by upstream source.

Repository SourceNeeds Review
Security

skill-guard

No summary provided by upstream source.

Repository SourceNeeds Review
Security

prompt-guard

No summary provided by upstream source.

Repository SourceNeeds Review