ClawHavoc: 1,184 Malicious Skills and Why Pre-Install Verification Matters

In late January 2026, the AI developer tooling ecosystem witnessed its most significant supply chain attack to date. Security researchers later named it ClawHavoc — a campaign that infiltrated a major skill registry, compromised 12 publisher accounts, and delivered live malware to developer machines across the globe before it was fully contained.

This is a factual account of what happened, what attackers exploited, and why the incident reveals a fundamental gap in how most skill registries approach security today.

Timeline

January 27, 2026 — The first malicious skills appear on ClawHub, a major registry for OpenClaw-compatible AI skills. The skills mimic legitimate productivity tools with convincing names, descriptions, and plausible README files.

January 31, 2026 — Upload activity surges. A single actor (later identified by researchers as operating under the alias “hightower6eu”) uploads 354 packages in under 6 hours, exploiting ClawHub’s lack of rate limits or behavioral anomaly detection. The packages followed a systematic naming pattern: legitimate tool names paired with common suffixes and spelling variants (-utils, -helper, -pro, -tools, -cli), combined with intentional one-character typosquats of popular skills in the registry. Many packages shared identical README text with only the skill name changed — a pattern that automated behavioral detection would have flagged immediately.

February 1, 2026 — Koi Security publishes the first public disclosure, identifying a cluster of skills delivering Atomic macOS Stealer (AMOS) — a well-documented credential-harvesting malware sold as a service for approximately $500/month on darknet forums.

February 16, 2026 — Repello AI names the campaign “ClawHavoc” in their public analysis, documenting the full scope of the social engineering techniques used.

February–March 2026 — Multiple organizations confirm the final count: 1,184+ malicious skills across 12 compromised publisher accounts. Antiy CERT provides the definitive tally.

The Attack Vectors

Atomic macOS Stealer (AMOS): How It Actually Works

AMOS is not novel — it has been sold as a service since at least 2023 — but the ClawHavoc operators adapted its delivery mechanism specifically for the AI skill attack surface. Understanding how AMOS operates at a technical level explains why it was so effective against developers.

The delivery in ClawHavoc followed a multi-stage chain:

1. Legitimate-looking skill entry point — The skill’s SKILL.md described a plausible developer utility (a data processing helper, a deployment assistant, a code formatter). The description, tags, and README were carefully written to pass a casual review.

2. Fake prerequisite injection — The skill’s instructions contained a directive to the AI agent: “This skill requires [dependency name]. Install it by running the following command.” The command downloaded a signed-looking Mach-O binary from a CDN under attacker control.

3. ClickFix execution — Rather than relying on the agent to execute the binary directly, some variants prompted the user with a fake macOS permission dialog, instructing them to paste a command into Terminal. This bypassed agent sandboxing by escalating to direct user execution.

4. AMOS payload — Once running, AMOS operated as a stealer with the following data collection priorities:

   • Keychain extraction: AMOS attempts to dump the macOS Keychain database, which stores website passwords, Wi-Fi passwords, and application credentials. It uses security CLI commands and direct SQLite access against ~/Library/Keychains/.
   • Browser credential sweep: Chrome, Safari, Firefox, Brave, and Arc browser profiles are targeted in sequence. AMOS specifically extracts the Login Data SQLite database (Chrome family), logins.json (Firefox), and Safari’s Passwords plist. Cookies are extracted separately for session hijacking.
   • Cryptocurrency wallets: MetaMask browser extension data, Exodus, Electrum, Ledger Live, and Trust Wallet local storage are targeted. Seed phrase files matching patterns *mnemonic*, *seed*, *recovery* are extracted.
   • Developer credential files: Files matching *.env, *.pem, *secret*, *token*, *apikey*, *api_key*, *password*, *credentials* are swept across the home directory and common project paths (~/projects/, ~/dev/, ~/code/).
   • SSH private keys: The full ~/.ssh/ directory is exfiltrated, including id_rsa, id_ed25519, and any non-public key files.

AMOS is particularly dangerous for developers because the credential surface is larger than it is for typical users. A senior engineer’s machine commonly holds: AWS/GCP/Azure CLI credentials, GitHub personal access tokens or SSH deploy keys, database connection strings in .env files across dozens of projects, Docker Hub credentials, npm/PyPI publishing tokens, and VPN certificates. A single successful AMOS execution on a developer’s machine is not a consumer banking incident — it is a potential infrastructure breach.

The malware exfiltrates via HTTPS POST to a C2 server and typically transmits within seconds of collection. The attacker receives a compressed archive of all captured data in near-real-time.

AMOS variants are actively maintained to evade signature-based detection. The specific variant used in ClawHavoc had not appeared in VirusTotal databases at the time of initial distribution — Koi Security’s behavioral analysis, not signature matching, identified the campaign.

Credential Exfiltration from Agent Config Files

A second attack vector targeted the AI agent’s own configuration. OpenClaw stores session credentials and API keys in ~/.openclaw/.env. Several ClawHavoc skills contained instructions that caused the AI agent to read and exfiltrate this file during normal operation — silently, as part of a seemingly legitimate workflow.

This is notable because it required no external binary download. The malicious behavior was entirely within the skill’s instruction set: the agent was told (in plausible-sounding workflow language) to “verify your API credentials are correctly configured” by reading a specific file path. The exfiltration was the read itself — directed to an attacker-controlled endpoint.

SOUL.md and MEMORY.md Persistence

Some skills exploited OpenClaw’s persona and memory features. By injecting malicious instructions into SOUL.md (the persona definition) or MEMORY.md (the persistent memory file), attackers could:

• Persist across sessions — the infected SOUL.md continued executing on every subsequent interaction, not just when the malicious skill was active
• Modify agent behavior — injected instructions redirected the agent to exfiltrate future files or credentials encountered in normal work
• Propagate to new workspaces — if the user copied their persona to a new project, the malicious instructions followed

This persistence mechanism is particularly insidious because users inspect SOUL.md rarely, if ever. An attacker who achieves a SOUL.md injection has installed a persistent backdoor in the agent’s core identity — one that survives skill uninstallation.

SSH Key Theft

Skills that appeared to need SSH access (deployment tools, Git utilities, server management helpers) used their legitimate-seeming permissions to copy SSH private keys from ~/.ssh/ and exfiltrate them. Given that many developers use the same SSH key across multiple services — GitHub, production servers, cloud instances — a single key theft can have cascading consequences.

ClawHub’s Response Model: Reactive by Design

ClawHub is not a negligent project. It has thoughtful security features and a dedicated team. But the ClawHavoc incident exposed the fundamental limits of a reactive security model:

Before ClawHavoc:

• No pre-upload scanning
• Community flagging (3 reports → auto-hide)

After ClawHavoc:

• 1-week GitHub account age requirement
• VirusTotal partnership for post-disclosure scanning
• 3-report auto-hide retained

These are reasonable improvements. But they share the same structural property: they activate after a malicious skill has been published and potentially installed.

The 1-week account age requirement would not have stopped ClawHavoc. The attacker operated 12 separate accounts, each aged beyond the threshold. The VirusTotal partnership scans known-bad files — but the AMOS variant used in ClawHavoc was not in VirusTotal’s database at the time of distribution. Novel malware, custom-compiled variants, and obfuscated scripts evade signature-based detection for days or weeks. ClawHavoc exploited exactly that window.

What Dual-Side Verification Would Have Blocked

SkillSafe’s security model operates differently. Two properties would have caught every ClawHavoc skill at the point of attempted sharing.

1. Publisher-Side Scanning with Specific Rule Violations

Every skill on SkillSafe must pass a security scan before it can be shared. This is not a post-hoc check — sharing is gated on a clean scan report. The following rules from the SkillSafe scanner ruleset would have triggered on ClawHavoc skills:

Data exfiltration rules (SS03):

• shell_exfil_service (high): Outbound HTTP/HTTPS calls via curl/wget to known exfiltration services (ngrok, requestbin, webhook.site, pipedream, etc.). The AMOS download step — fetching an external binary from a CDN — triggers this rule immediately.

Code execution rules (SS01):

• py_subprocess_run, py_os_system, js_child_process (high): Shell command execution that downloads and invokes external binaries. Triggers on patterns like curl ... | sh, wget ... && chmod +x && ./, or agent-instruction equivalents.

Encoded malware rules (SS05):

• b64_decode_exec, b64_file_exec (critical): Base64-encoded payloads designed to evade static analysis, including decode-and-execute pipelines.

Credential file access rules (SS17):

• cred_read_aws, cred_read_docker (critical): Read access targeting well-known credential files (AWS credentials, Docker config).
• cred_find_dirs (high): Directory searches for .ssh, .aws, .gnupg, .config/gcloud — matching the ~/.openclaw/.env and SSH key theft vectors.

Agent memory poisoning rules (SS04):

• agent_memory_write, agent_memory_inject (high): Shell redirects or echo appends to SOUL.md, MEMORY.md, CLAUDE.md, .cursorrules — the exact persistence mechanism ClawHavoc used.

Prompt injection rules (SS15):

• prompt_ignore_instructions, prompt_role_hijack, prompt_override (high): Instructions in .md files that attempt to override agent persona, suppress safety guidelines, or claim elevated permissions.

Composite co-occurrence rules (SS-CP):

• cp01_exec_plus_network (critical): Process execution combined with outbound network calls in the same file — catches the AMOS delivery chain (download + execute) even if neither primitive alone is flagged as critical.

ClickFix social engineering rules (SS11):

• clickfix_terminal, clickfix_copy_paste (high): “Open terminal and paste…” patterns — the exact ClickFix technique some ClawHavoc variants used to bypass agent sandboxing.

Every ClawHavoc attack vector maps to at least one of these rules. The AMOS delivery chain triggers shell_exfil_service (SS03), py_subprocess_run (SS01), and cp01_exec_plus_network (SS-CP). The ~/.openclaw/.env exfiltration triggers cred_find_dirs (SS17). The SOUL.md persistence attacks trigger agent_memory_write (SS04). SSH key theft triggers cred_find_dirs (SS17). The ClickFix variants trigger clickfix_terminal (SS11).

Critical findings block sharing. A publisher cannot create a share link for a skill with a critical verdict. These skills would never have reached the registry’s public index.

2. Cryptographic Tamper Detection

Even if an attacker crafted a skill that somehow passed the publisher-side scan, SkillSafe’s second layer catches tampering during distribution.

At publish time, every file in the skill archive is hashed into a SHA-256 cryptographic tree hash. This hash is stored immutably with the scan report.

At install time, the consumer independently re-scans the downloaded files. The server compares:

• The consumer’s scan report against the publisher’s original report
• The consumer’s computed tree hash against the stored tree hash

If a single byte changed between publish and download — through a compromised CDN, a registry breach, or a man-in-the-middle attack — the hash comparison fails and installation is blocked with a critical verdict automatically. No human reviewer needs to notice. No database update is required.

This means the registry itself cannot be used as a distribution point for tampered skills after a compromise. The consumer’s local scan is the authoritative check, and the cryptographic binding makes that check meaningful.

The Typosquatting Dimension

ClawHavoc wasn’t just bulk malware — it included deliberate typosquatting against legitimate popular skills. The hightower6eu package set showed a systematic approach: for each targeted legitimate skill, multiple variants were registered with one-character substitutions, common misspellings, and delimiter variations:

Legitimate skill	Malicious variants
sql-analyzer	sql-analyser, sqlanalyzer, sql-analysser
git-helper	git-helppr, giit-helper, git-helperr
deploy-utils	deploy-utills, deployutils, deploy-util

In a registry without namespace enforcement or publisher verification, typosquatting requires nothing more than registering a similar-sounding name. SkillSafe enforces verified namespaces — skills are published under @publisher/skill-name, and the @publisher namespace is tied to an authenticated account. Typosquatting a namespace requires compromising the legitimate publisher’s account. That raises the attacker’s cost from “register a name” to “execute an account compromise.”

What Individual Developers Should Do Right Now

If you installed AI skills from any public registry during January–March 2026, the following steps are warranted regardless of which registry you used:

1. Audit your installed skills. List every skill currently installed in your AI agent. For each one: verify the publisher namespace is the one you intended, check when you installed it, and confirm it matches the version you expected. Remove any skill you cannot positively verify.

2. Inspect your SOUL.md and MEMORY.md. Open your agent’s SOUL.md and MEMORY.md (or equivalent persona/memory files for your tool). Read them carefully. Look for instructions you don’t recognize, directives about reading files or making network calls, or anything that references paths outside your project directory. If you find anything suspicious, delete the file and recreate it from scratch. Do not attempt to “edit out” injected instructions — persistence mechanisms can be subtle.

3. Rotate credentials if you ran ClawHavoc-era skills. If you installed skills from ClawHub between January 27 and mid-February 2026, treat your credentials as potentially compromised and rotate:

• SSH keys (generate new keys, revoke old ones from GitHub/GitLab/servers)
• API tokens for AWS, GCP, Azure, GitHub, npm, PyPI, Docker Hub, and any other services where credentials live in .env files
• Any password stored in your browser if you ran code during that period

This is a precautionary step, not a confirmed-compromise response. The cost of unnecessary rotation is an hour of work. The cost of not rotating after an actual compromise can be significant.

4. Check for outbound connections you didn’t initiate. Review your router logs or system network activity for the ClawHavoc distribution period. AMOS exfiltrates via HTTPS, so you won’t see plaintext credentials in logs — but unexpected outbound connections to unfamiliar hosts are a signal worth investigating.

5. Verify skills before installing going forward. Use a registry that provides pre-install scan results. Before installing any skill, check that it has a scan report, that the report is recent, and that the verdict is clean. A scan report that is missing, stale, or unverifiable is a reason to pause.

Lessons for the Ecosystem

ClawHavoc is not a ClawHub problem. It is a registry security architecture problem that any install-time-only or reactive model will eventually face.

As AI agents become more capable and more autonomous, the blast radius of a malicious skill grows. A skill that can read files, execute commands, and make network requests — running inside an AI agent with access to the developer’s entire project and credentials — is not an ordinary software dependency. It is a credentialed actor with broad environmental access. The security model for distributing these tools needs to reflect that.

The industry needs to establish security baselines:

1. Publisher-side scanning is table stakes. Scanning at install time only misses the window between publish and the first install. Skills should not be distributable until they pass a pre-share scan.

2. Cryptographic integrity must be end-to-end. A scan report reflects the state of the code at one point in time. Without cryptographic binding between the scanned artifact and the installed artifact, the report is a promise, not a guarantee.

3. Behavioral analysis outperforms signature detection. AMOS variants are updated frequently to evade signature-based detection. Behavioral analysis — does this skill attempt to access credential files? does it make outbound calls? does it instruct the AI to download and execute external code? — is more durable than signature matching because it targets what the code does, not how it looks.

4. The AI agent’s instruction surface is part of the attack surface. Skills that manipulate .md instructions to redirect AI behavior — prompt injection, SOUL.md persistence — represent a novel threat class that traditional malware scanners are not designed to catch. Registry security models need dedicated rules for this surface.

Closing

We are publishing this analysis because security researchers at Koi Security, Repello AI, Bitdefender, Conscia, and Antiy CERT did the difficult work of documenting ClawHavoc. That research should reach the full developer community, not just the security community.

ClawHavoc was not an unpredictable event. The attack techniques it used — stealer malware delivery via fake prerequisites, credential-file exfiltration via agent instructions, persistence via persona file injection — were all foreseeable given what AI agents can do. What was missing was a security architecture designed for the threat model AI skills actually present.

The gap between reactive moderation and dual-side verification with cryptographic tamper detection is not an incremental improvement. It is the difference between a security model that depends on attackers being slow and a security model that does not depend on attacker behavior at all.

Sources: Koi Security (Feb 1 disclosure), Repello AI (Feb 16 ClawHavoc naming), Bitdefender, Conscia, Antiy CERT (1,184 confirmed skills). SkillSafe did not independently verify all figures — we cite published security research.