▋
platform/workstation-compromise-scan/SKILL.md

name: workstation-compromise-scan description: >- General read-only compromise triage for macOS/Linux developer workstations, CI runners, and dev VMs: recent npm/PyPI supply-chain waves, poisoned AI-tool/MCP configs, GitHub workflow backdoors, suspicious persistence (launch agents, systemd units, cron), and CISA KEV exposure. Use for "is my machine compromised", "scan my system", IOC scans, or incident triage when no single campaign is named, or as the first pass before a campaign-specific skill. For the May 2026 TanStack/Mistral/ Guardrails wave specifically, mini-shai-hulud-scan is the deeper follow-up.

workstation-compromise-scan

Read-only workstation compromise triage for developer machines. The goal is to collect enough evidence to answer "is this machine likely compromised?" without deleting evidence, rotating secrets from a suspect host, or running untrusted project code.

When to use this

Use this when the user asks to scan a macOS or Linux workstation, CI runner, dev VM, or code workspace for compromise, especially after recent npm/PyPI supply-chain attacks, AI agent/MCP tool poisoning, suspicious GitHub workflow changes, or CISA Known Exploited Vulnerabilities.

Use the narrower mini-shai-hulud-scan skill if the request is specifically about the May 2026 TanStack/Mistral/Guardrails wave. For a general workstation review, run this skill first and use mini-shai-hulud-scan for deeper follow-up when its IOCs appear.

Safety rules

  • Start read-only. Do not delete files, kill processes, rotate tokens, revoke packages, or "clean up" before evidence is captured.
  • Do not print secret values. Report paths, package names, versions, timestamps, suspicious domains, commit IDs, and command names.
  • If high-confidence evidence appears, tell the user to stop using the machine for dev/admin work and rotate secrets only from a known-clean host.
  • Treat absence of IOCs as "no evidence found by this scan", not as a guarantee.
  • Before scanning a new campaign, browse current primary/vendor sources and CISA KEV; threat data goes stale quickly.

Quick workflow

  1. Check the Last researched date at the top of references/recent-threat-notes.md. If it is more than a month old, refresh the notes from the sources it lists before trusting its IOC set; read the rest of the file only when a campaign is named or the scanner flags a package (step 4).

  2. Run the bundled scanner:

    bash ~/.claude/skills/workstation-compromise-scan/scripts/workstation-compromise-scan.sh --network

    Add --root <path> one or more times to limit scanning to known code roots, or --deep when the user explicitly wants a slower home-directory scan.

  3. Open the generated summary.md and findings.tsv. Investigate every CRITICAL and HIGH line before treating REVIEW or INFO as suspicious.

  4. If a campaign-specific hit appears, run focused follow-up from the relevant section in references/recent-threat-notes.md.

  5. If compromise is plausible, follow the remediation order below.

What the scanner covers

  • npm/package-manager installs and lockfiles for the malicious package waves listed in references/recent-threat-notes.md (the script's pattern tables are the executable copy).
  • High-confidence filesystem IOCs: malicious payload names, known C2 domains/IPs, project persistence files, injected GitHub workflows, and suspicious VS Code / Cursor / Windsurf extension artifacts.
  • AI-tool and MCP config poisoning: suspicious MCP tool names, hidden home directories, and agent/editor config files.
  • macOS/Linux user persistence: LaunchAgents, systemd user units, cron, shell startup files, login/background-task listings where available.
  • Git history and workflow diffs since the configured date for branches, commits, and workflow files matching known supply-chain backdoor patterns.
  • Live process and network snapshots for known domains, IPs, process names, and payload markers.
  • Optional current CISA KEV snapshot via --network.

Interpreting findings

  • CRITICAL: high-confidence IOC or compromised package version. Assume the host may be compromised until disproven.
  • HIGH: likely malicious artifact or persistence marker that needs immediate manual inspection.
  • REVIEW: suspicious pattern with possible benign explanations.
  • INFO: inventory or vulnerability posture data, not evidence of compromise.

Clean report criteria:

  • No high-confidence payload files, malicious package versions, known IOC strings, suspicious persistence files, suspicious MCP/editor config entries, malicious workflow patterns, or live network/process IOC hits.
  • CISA KEV and OS/package posture do not reveal exposed software that is both installed locally and reachable in this environment.

Remediation order

  1. Preserve evidence: keep the scan report, suspicious files, package lockfiles, shell histories, Git logs, and CI logs.
  2. Stop active risk: disconnect the host or CI runner from sensitive networks and stop using it for code release, cloud admin, package publishing, or secret management.
  3. Remove persistence only after evidence capture and with user approval.
  4. Rotate secrets from a clean host: GitHub, npm, PyPI, cloud credentials, SSH keys, database credentials, agent/editor tokens, .env values, and CI/CD secrets.
  5. Rebuild CI runners/dev VMs from clean images. Do not trust dependency caches or existing node_modules, virtualenvs, package-manager caches, or Actions caches after a confirmed supply-chain compromise.

Notes

  • The helper script is intentionally conservative and should be patched as new IOCs emerge. Keep durable workflow guidance here; keep volatile IOCs in references/recent-threat-notes.md and in the script's pattern lists.
  • The report directory may contain sensitive path names and command lines. Do not paste raw reports into public systems without reviewing them.