Malicious MoltBot skills used to push password-stealing malware

Malicious MoltBot skills used to push password-stealing malware 🔗 **Source:** [Malicious MoltBot skills used to push password-stealing malware](https://www.bleepingcomputer.com/news/security/malicious-moltbot-skills-used-to-push-password-stealing-malware/amp/) > [!note]+ Document Notes > tags: [AI, Malware, Security] > author: Bill Toulas > source: BleepingComputer > reference: [https://share.google/52aZds0N4MxBoqAxy] > date created: 2026-02-15 12:00 > > --- > > # 🏷️ Title: Malicious MoltBot skills used to push password-stealing malware >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: Attackers uploaded 230+ malicious “skills” (plugins) for the OpenClaw AI assistant (formerly MoltBot/ClawdBot) to its official registry and GitHub, distributing info-stealing malware. - Why it matters: OpenClaw can access local files, keys, and services; compromised skills become a powerful supply‑chain vector on developer and power‑user machines. - Key stakeholders: OpenClaw users, developers publishing skills, security researchers, and broader AI/open‑source ecosystems. - Risks and tradeoffs: Massive data theft (keys, wallets, SSH, cloud creds), trust erosion in community registries, and heavier review/permission burdens for AI agents. - Bottom line: Treat OpenClaw skills as untrusted code, harden deployments (VMs, least privilege, network restrictions), and verify skills independently before installation. ## 📖 Main Content - OpenClaw is a viral, open-source, local AI assistant with persistent memory and deep integration (chat, email, local file system). Misconfiguration and weak permissioning make it high‑impact if compromised. - “Skills” are plug‑ins that extend OpenClaw. Over 230 malicious skills were pushed to ClawHub and GitHub between Jan 27 and Feb 1, many impersonating crypto trading tools, financial utilities, or social/content services. - These skills added extensive, polished documentation to appear legitimate and repeatedly referenced a supposed dependency, “AuthTool,” as mandatory to make things work. - Infection flow: users follow documentation, run AuthTool (macOS: base64 shell command; Windows: password‑protected ZIP), which fetches and runs info‑stealing malware (NovaStealer variant on macOS). - Capabilities: stealing crypto API keys, wallet files and seed phrases, browser wallets, macOS Keychain data, browser passwords, SSH keys, cloud and Git credentials, and dotenv files. - OpenSourceMalware and Koi Security both investigated; Koi scanned 2,857 skills and found 341 malicious, plus 29 typosquats of the ClawHub name, likely part of a single campaign. - Koi released a free online scanner so users can paste a skill URL to get a safety report. - OpenClaw creator Peter Steinberger acknowledged that current submission volume makes central review impractical and placed responsibility on users to validate skills before use. - Recommended mitigations: isolate OpenClaw in a VM, limit file/system permissions, secure remote access (port restrictions, firewalling), and scrutinize skills/documentation like any third‑party code. ### 🗒️ Notes - OpenClaw (formerly ClawdBot → MoltBot) is a local, agentic AI assistant with persistent memory and access to chats, email, and local filesystem, making compromise extremely sensitive. - Skills are effectively executable plugins, not mere prompts; treating them like scripts/packages is essential. - Two independent sources (OpenSourceMalware, Koi Security) converge on a large malicious campaign abusing the official registry. - Malicious skills share patterns: cloned code with randomized names, fake utility branding, heavy documentation polish, and insistence on installing “AuthTool.” - Attack vector is “ClickFix”-like: users copy-paste commands from docs believing they are harmless fixes or setup steps. - On macOS, AuthTool uses a base64-encoded shell one‑liner to download payloads, strip Gatekeeper quarantine attributes via `xattr -c`, and request broad access. - On Windows, AuthTool fetches a password‑protected archive and executes malware inside, complicating static inspection. - Targeted data suggests a strong focus on developers, power users, and crypto holders (API keys, Git creds, SSH keys, cloud creds, `.env` files). - Koi Security’s full‑repo scan (2,857 skills) found ~12% malicious, highlighting significant registry contamination and the limits of trust-by-default. - The project’s maintainer candidly states he cannot review all submissions; the model is effectively “unmoderated app store,” with users bearing most risk. - Defense‑in‑depth advice aligns with standard high‑risk agentic AI practices: sandboxing, strong OS permission boundaries, and explicit network controls. ## 📚 References - OpenClaw / MoltBot project site or repo (for context on skills and architecture) - OpenSourceMalware community report on malicious OpenClaw skills - Koi Security report and OpenClaw skills scanner - Documentation on NovaStealer / information-stealing malware families - Resources on ClickFix‑style social engineering and “copy‑paste from docs” attack patterns ## 🗣️ Paraphrase - Paragraph A paraphrase: Attackers abused OpenClaw’s skill ecosystem by uploading dozens of fake plugins that appear useful but secretly install information-stealing malware via a deceptive helper tool called AuthTool. - Paragraph B paraphrase: Security firms found hundreds of malicious skills in the official registry, prompting the project maintainer to admit he can’t vet everything and urging users to isolate OpenClaw, restrict its access, and independently check skills before using them. ## 📰 Newsletter A new wave of AI‑supply‑chain attacks is targeting OpenClaw (formerly MoltBot), a local agentic assistant with deep access to files, keys, and services. Over 230 malicious “skills” were found in its official registry, some masquerading as crypto or automation helpers while quietly installing info‑stealing malware. For WordPress builders and hosts, this is a reminder that AI agents running on dev machines or servers must be sandboxed and treated like any untrusted plugin. Review any “skills” or automation scripts that can touch wp-config.php, SSH keys, or cloud credentials, and prefer containerized or VM‑based setups when experimenting with local AI tooling. Helpful resources: - Hardening guides for local AI assistants and CLIs - WordPress security best practices for secrets and environment files - Tutorials on using containers/Playground-style sandboxes for risky tooling Stay curious—just make sure your AI helpers don’t walk off with your keys. ## ✅ Action Items #### DevRel - Publish a short guide on treating AI “skills” and extensions like untrusted code, with OpenClaw as a case study. - Add security modules to workshops and docs covering local AI agents, emphasizing sandboxing and permission scoping. - Provide example hardened setups (VM/docker configs) for running agentic tools safely. - Run a content campaign (blogs, talks) on AI‑supply‑chain attacks and safe registry usage. - Collect feedback from developers using OpenClaw‑style tools to understand pain points and needed guardrails. #### OSPO - Clarify policies for accepting or endorsing third‑party AI plugins/skills in org repositories. - Ensure license and security scanning covers AI‑assistant plugin ecosystems as well as traditional packages. - Establish vulnerability intake and disclosure procedures specifically for AI agent extensions. - Track AI‑related components in SBOMs, including skills and prompt packs with executable code. - Offer consultation hours to teams planning to adopt local AI assistants in sensitive environments. - Engage with upstream AI‑assistant projects to promote security review pipelines and trust tiers. - Align executive reporting so AI‑supply‑chain risks are visible at the same level as library/package risks. #### Community - Help maintainers of AI assistants design more secure skill registries (signed, reviewed, or reputation‑based). - Offer contributors guidance for writing secure skills and clear, non‑dangerous docs. - Encourage sponsors to fund security audits, scanners, and review automation for popular open‑source AI tools. - Coordinate cross‑project incident drills around malicious extensions or registry poisoning. #### WordPress - Core: consider guidelines for interacting with local AI agents that may edit WordPress code or configs; treat them like remote code execution vectors. - Core Performance: document safe patterns for AI‑driven profiling and load‑testing tools that run near production data. - Core AI: draft responsible AI guardrails for agents that can access keys, repos, or hosting accounts. - **Core Program Team:** align cross‑team security expectations for any official AI tooling or recommended assistants. - Mobile: ensure mobile dev tooling and AI helpers do not store or expose tokens used for app distribution or WP.com accounts. - Playground: showcase sandboxed AI workflows where agents can experiment on isolated WordPress instances. - Community: include AI‑security topics in meetup kits and WordCamp content; highlight real‑world registry abuse cases. - Training: build lessons on AI tooling threat models, focusing on secrets, `.env`, and config safety. - Marketing: frame AI features with clear messaging about safe usage and boundaries. - Support: add KB entries on dangers of unvetted AI scripts/skills interacting with WordPress sites. - Design: work with security teams to design UIs that make permissions and access scope obvious. - Documentation: clearly distinguish safe copy‑paste snippets from “run this at your own risk” examples. - Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: - Emphasize secure handling of API keys and credentials in docs, tools, and examples. - Ensure plugin/theme/host security guidance calls out AI‑driven automation and local agents explicitly. #### The WPOCC - Sponsor security reviews for widely used open‑source AI assistants relevant to WordPress workflows. - Fund maintainers who add permissioning, sandboxing, and verification tools to AI ecosystems. - Experiment with grants for building open scanners and registries for AI skills. ### FAIR - Promote signed metadata and provenance tracking for AI skills and extensions. - Encourage transparent funding and governance for AI‑assistant projects to resist capture and prioritize safety. - Package governance artifacts (charters, security SLAs) that can be reused by AI‑tool communities. ## 🧪 Hypotheses - H1: Users treat AI “skills” as lower‑risk than traditional software, leading to higher infection rates via documentation‑driven attacks. - H2: A significant percentage of popular AI‑assistant skills in unmoderated registries contain unsafe or malicious behaviors. - H3: Sandboxing OpenClaw in a VM with restricted permissions reduces effective data theft impact by the majority of current malware strains. - H4: Security scanners integrated into skill registries meaningfully reduce malicious skill adoption. ### 📊 Methodology - To test H1–H2: run controlled user studies and static/dynamic analysis of skills from several AI‑assistant registries; measure risk perception and actual malicious/unsafe prevalence. - For H3: simulate compromises in varied deployment setups (bare metal vs VM/container) and quantify accessible secrets and data exfiltration. - For H4: A/B test a registry with and without integrated scanning/warnings; measure download patterns and incident reports. ### ❓ Questions - How many OpenClaw users have been compromised, and what’s the real-world damage? - Can AI‑assistant registries move to signed, reputation‑based, or curated models without killing innovation? - What OS‑level permission models best fit agentic AI tools with broad capabilities? - How should documentation platforms guard against “copy‑paste this malicious command” patterns? ### 🔮 Future Research - Designing safe-by-default execution environments for local AI agents. - Automated behavioral analysis of skills and plugins before publication. - UX research on how to present risk and permissions in AI‑assistant UIs. - Cross‑ecosystem standards for AI‑extension security metadata and provenance. ### 💡 Implications - Practice: developers must treat AI skills/docs like any untrusted executable; copy‑pasted commands are high‑risk. - Policy: orgs may need explicit rules for using AI assistants on machines with access to secrets and production data. - Security: AI‑supply‑chain attacks via skills/agents will likely grow; defensive tooling must catch up. - Education: security training should now cover AI‑tooling and documentation‑driven social engineering. - Funding: supporting open scanners, audits, and secure registries for AI ecosystems becomes a public‑good priority. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade ~10–11 (technical terms, compound sentences, security jargon). #### 👀 Visual learners - Present: article includes a few illustrative screenshots (e.g., skill lists, instructions). - Improve: add architecture diagrams of OpenClaw, data‑flow charts for the infection chain, and permission models. #### 🔊 Aural learners - Present: no audio/podcast version indicated. - Improve: provide a short audio summary and a security‑focused podcast segment on AI‑assistant threats. #### 🗣️ Verbal learners - Present: clear narrative with defined entities (OpenClaw, skills, AuthTool, NovaStealer). - Improve: add a small glossary (e.g., “ClickFix,” “info‑stealer,” “typosquatting”) and analogies for non‑experts. #### 🧩 Kinesthetic learners - Present: no direct hands‑on tasks. - Improve: include step‑by‑step lab exercises for safely analyzing a skill, or setting up OpenClaw inside a sandbox. #### 🧠 Logical learners - Present: chronological description of disclosure and a structured explanation of attack flow. - Improve: add decision trees for deployment choices and tables comparing mitigations vs threats. #### 🧑‍🤝‍🧑 Social learners - Present: references to community security efforts (OpenSourceMalware, Koi Security). - Improve: link to discussion forums, invite readers to share indicators of compromise and mitigation playbooks. #### 🧘‍♀️ Solitary learners - Present: article can be read and reflected on privately; no prompts though. - Improve: add reflection questions on one’s own AI‑tooling and key storage practices. #### 🌿 Naturalistic learners - Present: no environmental framing. - Improve: lightly relate “digital ecosystems” and invasive “species” (malicious skills) as an analogy. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: basic headings and structure are typical of news sites. - Improve: ensure clear heading hierarchy and descriptive alt text for images and charts. #### Keyboard navigation - Present: likely standard navigation (tabbable links, menus). - Improve: guarantee no keyboard traps; provide skip‑to‑content links. #### Contrast and readability - Present: mainstream tech news sites generally meet basic contrast. - Improve: verify 4.5:1 ratios, adequate line spacing, and non‑tiny body fonts. #### Text resizing and reflow - Present: responsive layout on mobile. - Improve: confirm content reflows cleanly at 200% zoom and respect prefers‑reduced‑motion. #### Media and captions - Present: static images only, with captions in some cases. - Improve: ensure alt text for all figures and avoid auto‑playing media. #### Forms and interactions - Present: simple comment or sign‑up forms if any. - Improve: label all inputs clearly, provide inline error messages, and ensure accessible click targets. #### Standards reference - Map gaps against WCAG 2.2 AA, especially for non‑text contrast, focus visibility, and error identification. ### 🌍 DEIB Assessment #### Cultural breadth - Present: global‑relevant security topic, but examples are developer‑centric. - Improve: highlight impacts on diverse user groups and regions, not only crypto/dev communities. #### Inclusive language - Present: technical, neutral tone with minimal idiom. - Improve: add short plain‑language summary for non‑experts. #### Neurodiversity support - Present: consistent structure (headline → body → related links). - Improve: more subheadings, bullet lists for mitigations, and predictable patterning of sections. #### Representation - Present: focuses on tools and organizations, not people. - Improve: when using images, ensure diverse, respectful representation and describe it in alt text. #### Psychological safety - Present: factual reporting on threats, no alarmist language. - Improve: add reassurance via practical steps readers can take and links to support/help resources. ### ✅ Logical Validity #### Strong reasoning - Inductive: article aggregates findings from OpenSourceMalware and Koi Security to infer a large, ongoing malicious campaign; multiple sources and data points support this. - Causal: shows clear cause‑and‑effect between installing malicious skills/AuthTool and compromise, with concrete technical mechanisms (base64 command, Gatekeeper bypass). #### Fallacies - None obvious; claims are grounded in named reports and concrete numbers (e.g., 341 malicious skills of 2,857 scanned). #### Tone of voice - The tone is cautious and investigative: it explains risks, cites researchers and the project maintainer, and ends with practical security recommendations rather than sensationalism. ### 🛡️ DARVO Analysis - Deny: the piece does not depict denial by attackers; the maintainer does not deny issues but acknowledges review limits. - Attack: no attacks on researchers; they are treated as credible. - Reverse victim/offender: the article does not recast offenders as victims; it emphasizes user risk and platform limitations. - Overall: minimal DARVO patterns; the narrative is security‑focused and matter‑of‑fact. ## 🎯 Conclusion The article documents a large campaign abusing OpenClaw’s skill ecosystem to deliver powerful info‑stealing malware via deceptive documentation and a fake dependency, AuthTool. Because OpenClaw has deep access to local data, compromised skills can exfiltrate highly sensitive secrets. Readers should treat skills and docs as untrusted code, isolate AI assistants with strong OS and network boundaries, and verify any plugin or command before running it. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://share.google/52aZds0N4MxBoqAxy) by [[Bill Toulas]] via [[BleepingComputer]]. Published 2026-02-02. > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight](https://share.google/52aZds0N4MxBoqAxy#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}](https://share.google/52aZds0N4MxBoqAxy) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight](https://share.google/52aZds0N4MxBoqAxy#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/https://share.google/52aZds0N4MxBoqAxy #fleeting #inbox - [F2] Short action — context/https://share.google/52aZds0N4MxBoqAxy #fleeting #inbox - [F3] Short action — context/https://share.google/52aZds0N4MxBoqAxy #fleeting #inbox ---