Quando le "competenze" diventano la catena di fornitura: il campanello d'allarme del malware del marketplace OpenClaw

/Generale/ Di

Negli ultimi due anni, "agente AI" ha smesso di essere un termine di marketing e ha iniziato a essere un vero e proprio flusso di lavoro: un assistente in grado di leggere i file, aprire il browser, eseguire comandi e unire azioni tra i servizi. Questa è la promessa.

Il problema è cheil potere ha un canale di distribuzioneE quel canale è sempre più chiamato unabilità: un piccolo pacchetto "how-to" condivisibile che insegna a un agente (e spesso all'utente) come svolgere un compito. È il momento dell'App Store per gli agenti, solo che le "app" sono spessoistruzioni di markdown.

I report di questa settimana sulle competenze OpenClaw dannose sono un segnale precoce e molto forte che stiamo per ripetere la storia della supply chain open source, ma con una svolta: invece di avvelenare una dipendenza compilata, gli aggressori possono avvelenaredocumentazionee usare la disponibilità dell'agente come lubrificante.

Di seguito una spiegazione pratica di cosa è successo, perché funziona così bene e cosa si può fare al riguardo.

Cosa sono le competenze OpenClaw (e perché sono importanti)

OpenClaw ha reso popolare un semplice modello di estensione: basta inserire una "competenza" che spiega come svolgere un compito specifico (pubblicare sui social media, pulire cartelle, riassumere un report, automatizzare un flusso di lavoro) e l'agente acquisisce una nuova capacità.

Nell'ecosistema più ampio delle "competenze degli agenti", una competenza è in genere una cartella costruita attorno a unSKILL.mdfile. Quel file contiene:

  • Metadati(nome / descrizione)
  • Istruzioni(i passaggi effettivi)
  • Facoltativamente:scripte altre risorse in bundle

Sembra una cosa innocua, perché sembra documentazione. Ma la documentazione è esattamente ciò che le persone seguono rapidamente, soprattutto quando si presenta come un elenco di prerequisiti o una guida all'installazione.

Le competenze hanno anche una dinamica del tipo "chi vince prende tutto": le persone gravitano attorno a ciò che è popolare, a ciò che è nuovo e a ciò che sembra far risparmiare tempo. Questo rende un mercato pubblico delle competenze un obiettivo di alto valore: compromettendo alcuni download frequenti, è possibile raggiungere un gruppo concentrato di utenti esperti: sviluppatori, operatori e chiunque abbia credenziali preziose sul proprio computer.

Il trucco principale: il markdown non è più un "contenuto", è un programma di installazione

Gli attacchi tradizionali alla supply chain del software spesso richiedono investimenti tecnici: confusione sulle dipendenze, typosquatting, script post-installazione dannosi, mantenimento del controllo sul nome di un pacchetto ed elusione degli scanner.

Un mercato delle competenze abbassa l'asticella.

Un'abilità dannosa può fare qualcosa di semplice come questo:

  1. Presentare uno strumento plausibile ("abilità Twitter", "tracker di criptovalute", "helper di automazione").
  2. Aggiungere una sezione "Prerequisiti" con una "dipendenza richiesta".
  3. Fornire un collegamento pratico e un comando di una sola riga.
  4. Affidarsi all'essere umano (o all'agente) per eseguirlo.

Non si tratta di una nuova idea di ingegneria sociale, è in uso da anni, ma i flussi di lavoro degli agentiamplificareEsso:

  • Gli agenti riassumono i documenti con sicurezza ("Basta eseguire questo per installare la dipendenza").
  • Gli agenti riducono l'attrito generando il comando per te.
  • In alcune configurazioni, gli agenti possono eseguire autonomamente i comandi shell.

A quel punto, la “documentazione” diventa un percorso di esecuzione remota.

Cosa dicono i report su quanto accaduto nell'ecosistema OpenClaw

Diversi articoli descrivono una campagna in cui gli aggressori hanno caricato un gran numero di competenze dannose sul marketplace ClawHub e hanno utilizzato "fasi di configurazione" per distribuire malware che ruba informazioni.

Secondo Jason Meller di 1Password, una skill scaricata dall'alto includeva istruzioni che indirizzavano gli utenti verso una catena di distribuzione graduale: un collegamento a una "dipendenza", un comando offuscato e poi un payload che alla fine installava un infostealer progettato per saccheggiare la macchina alla ricerca di segreti preziosi.

CyberInsider, citando una ricerca di Koi Security, descrive un modello simile su larga scala: competenze trojanizzate con "prerequisiti" che istruiscono gli utenti a eseguire script shell offuscati o a scaricare archivi protetti da password, culminando in payload come Atomic macOS Stealer (AMOS), una famiglia di malware associata al furto di credenziali e al targeting dei portafogli.

Se i conteggi esatti differiscono tra i report, ilformaè coerente:

  • Competenze utilizzate come distribuzione
  • Istruzioni “prerequisito” utilizzate come persuasione
  • Infostealer utilizzati come obiettivo finale

L'obiettivo finale è importante: i moderni infostealer non sono alla ricerca di una sola password, ma ditoken di sessione,profili del browser,chiavi SSH,credenziali cloud, Eportafogli crittograficiIn altre parole: tutto ciò che trasforma un computer portatile compromesso in un compromesso più ampio.

Se hai mai pensato: "Non ci cascherei", probabilmente hai ragione quando sei calmo e scettico.

Ma i flussi di lavoro degli agenti cambiano il contesto:

  • La velocità diventa l'impostazione predefinita.Ti affidi a un agente perché vuoi agire rapidamente.
  • Il carico cognitivo è esternalizzato.L'agente trasforma una pagina di istruzioni disordinata in una checklist affidabile.
  • L'autorità è presa in prestito.Se l'agente dice "Questa è la dipendenza standard", sembra verificata.

In altre parole: l'agente non ha bisogno di essere "ingannato" in senso tecnico. Deve solo essere presente mentre ti viene chiesto di fare qualcosa di rischioso. Questo è sufficiente per suggerire un comportamento.

E se tuFareSe si consente all'agente di eseguire comandi direttamente, un'abilità dannosa può trasformarsi in un "compromesso a mani libere".

"Ma che dire dell'MCP? Non dovrebbe rendere gli utensili più sicuri?"

Il Model Context Protocol (MCP) rappresenta un vero passo avanti nella strutturazione dell'accesso agli strumenti. Standardizza il modo in cui gli host espongono strumenti, risorse e prompt, e sottolinea il consenso e il controllo dell'utente.

Tuttavia, MCP non rende magicamente sicure le "competenze".

Perché?

  • Le competenze possono indicare agli utenti di eseguire comandi al di fuori dei confini MCP.
  • Le competenze possono essere collegate a script o download che non toccano mai MCP.
  • Non tutte le abilità utilizzano MCP.

MCP può essere d'aiuto quando l'host implementa un sistema di autorizzazione avanzato, richieste di consenso chiare, logging e impostazioni predefinite sicure. Tuttavia, un meccanismo di distribuzione basato su markdown può comunque aggirarlo tramite la classica ingegneria sociale.

Questa è la versione agente della sicurezza della supply chain (e ci siamo già passati)

Il mondo del software ha imparato a sue spese che:

  • I registri popolari vengono abusati.
  • Il typosquatting funziona.
  • "Installa questo helper" è un punto di ingresso comune.
  • Le vittime più preziose sono quelle che costruiscono le cose.

I mercati delle competenze combinano queste lezioni con due nuovi acceleratori:

  1. Il “pacchetto” può essere costituito da istruzioni, non codice, e le istruzioni sono più difficili da leggere in modo affidabile.
  2. L'ambiente di runtime è ricco di credenzialiin base alla progettazione: browser che accedono a tutto, terminali con chiavi SSH, CLI cloud, gestori di password e file locali.

In un certo senso, uno skill marketplace è un app store in cui le app più popolari possono dire "Copia e incolla questo nel Terminale per abilitare la funzionalità". Questo non è un problema risolvibile con una sola casella di controllo.

Difese pratiche (per utenti normali)

Se si sta sperimentando un agente con accesso locale, è necessario trattarlo come un nuovo utente del sistema operativo dotato di superpoteri.

Ecco la base pragmatica:

  1. Utilizzare una macchina o una VM dedicataPer esperimenti con agenti. Nessun accesso aziendale salvato. Nessuna chiave SSH di produzione. Nessuna sessione di amministrazione cloud.
  2. Imposta come predefinito "no" sugli installer a riga singola.In particolare, tutto ciò che si collega a sh, utilizza base64 o chiede di rimuovere le protezioni del sistema operativo.
  3. Non fidarti di "più scaricati".La popolarità è un modo per crescere, non un modello di sicurezza.
  4. Se hai già eseguito qualcosa, ruota prima ciò che conta.Sessioni del browser, chiavi SSH, token API, chiavi cloud.
  5. Preferire competenze controllate alla fonte e revisionabili(Repository Git con cronologia, responsabili noti, provenienza chiara).

Cosa dovrebbero fare i marketplace (se vogliono sopravvivere)

Se gestisci un registro pubblico delle competenze, stai gestendo una superficie di attacco.

Alcuni passaggi pratici che aumentano significativamente i costi per gli aggressori:

  • Reputazione e provenienza dell'editore(identità verificate, cronologia, firma).
  • Scansione automaticaper modelli sospetti (payload codificati, one-liner offuscati, rimozione della quarantena, archivi protetti da password, "installa dipendenza core" con link esterni).
  • Avviso di attrito dell'interfaccia utenteper collegamenti esterni e comandi shell.
  • Smontaggio rapido e risposta visibile agli incidenti(trattalo come un app store, non come un pastebin).

Nessuna di queste soluzioni è perfetta, ma fa guadagnare tempo, e il tempo è ciò di cui i difensori hanno bisogno.

Cosa dovrebbero aspettarsi i costruttori di agenti in futuro

Se si sta creando l'ambiente di esecuzione dell'agente stesso, si presuppone che le competenze saranno trasformate in armi.

Ciò significa:

  • Esecuzione del comando Default-deny(richiedono il consenso per ogni comando, non attivazioni una tantum).
  • Sandboxing forteper l'accesso al file system e al browser.
  • Autorizzazioni limitate nel tempo e con ambito definitocon facile revoca.
  • Registri verificabilidi ciò che l'agente ha letto e di ciò che ha eseguito.

Lo stato finale è la stessa direzione intrapresa dal cloud anni fa: identità, policy, privilegi minimi e audit trail, ma riportati al livello della workstation.

In conclusione

La storia delle competenze di OpenClaw non riguarda solo il fatto che "alcune persone hanno caricato malware". È un'anteprima del prossimo campo di battaglia della supply chain:competenze come distribuzione, markdown come percorso di esecuzione e agenti come acceleratore.

Se gli agenti devono vivere sui nostri computer personali e di lavoro, l'ecosistema ha bisogno di un livello di fiducia che tratti i mercati delle competenze come app store, tratti la documentazione come codice e consideri "l'automazione utile" come un'operazione privilegiata, non una comodità casuale.

Fonti

Document Title
When ‘skills’ become the supply chain: the OpenClaw marketplace malware wake‑up call
Malicious AI-agent ‘skills’ are turning documentation into a distribution channel for infostealers. Here’s how it works — and how to defend against it.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Ikea’s bargain Matter-over-Thread devices are stumbling at the hardest step: getting connected
Should AI chatbots have ads? What Anthropic’s ‘no ads’ stance really means
Page Content
When ‘skills’ become the supply chain: the OpenClaw marketplace malware wake‑up call
Nature
Climate
/
General
/ By
Admin
In the last couple of years, “AI agent” stopped being a marketing phrase and started being a real workflow: an assistant that can read your files, open your browser, run commands, and stitch together actions across services. That’s the promise.
The problem is that
power has a distribution channel
. And that channel is increasingly called a
skill
: a small, shareable “how-to” package that teaches an agent (and often the user) how to accomplish a task. It’s the app store moment for agents — except the “apps” are frequently
markdown instructions
.
This week’s reports about malicious OpenClaw skills are an early, very loud signal that we’re about to repeat open-source supply‑chain history — but with a twist: instead of poisoning a compiled dependency, attackers can poison
documentation
and use the agent’s helpfulness as the lubricant.
Below is a practical explainer of what happened, why it works so well, and what you can do about it.
What OpenClaw skills are (and why they matter)
OpenClaw popularized a simple extension model: drop in a “skill” that explains how to do a narrow task — post on social media, clean folders, summarize a report, automate a workflow — and the agent gains a new capability.
In the broader “agent skills” ecosystem, a skill is typically a folder built around a
SKILL.md
file. That file contains:
Metadata
(name / description)
Instructions
(the actual steps)
Optionally:
scripts
and other bundled assets
That sounds benign because it looks like documentation. But documentation is exactly what people follow quickly, especially when it looks like a prerequisite list or installation guide.
Skills also have a “winner takes all” dynamic: people gravitate to what’s popular, what’s new, and what looks like it will save time. That makes a public skills marketplace a high-value target: compromise a few top downloads, and you can reach a concentrated set of power users — developers, operators, and anyone who has valuable credentials sitting on their machine.
The core trick: markdown isn’t “content” anymore — it’s an installer
Traditional software supply chain attacks often require technical investment: dependency confusion, typosquatting, malicious post-install scripts, maintaining control over a package name, and dodging scanners.
A skills marketplace lowers the bar.
A malicious skill can do something as simple as this:
Present a plausible tool (“Twitter skill,” “crypto tracker,” “automation helper”).
Add a “Prerequisites” section with a “required dependency.”
Provide a convenient link and a one‑liner command.
Rely on the human (or the agent) to execute it.
That’s not a new social engineering idea — it’s been used for years — but agent workflows
amplify
it:
Agents summarize docs confidently (“Just run this to install the dependency”).
Agents reduce friction by generating the command for you.
In some setups, agents can run shell commands themselves.
At that point, “documentation” becomes a remote execution path.
What the reports say happened in the OpenClaw ecosystem
Multiple write-ups describe a campaign in which attackers uploaded large numbers of malicious skills to the ClawHub marketplace and used “setup steps” to deliver infostealing malware.
According to 1Password’s Jason Meller, a top-downloaded skill included instructions that funneled users into a staged delivery chain: a link to a “dependency,” an obfuscated command, and then a payload that ultimately installed an infostealer designed to raid the machine for valuable secrets.
CyberInsider, citing research from Koi Security, describes a similar pattern at scale: trojanized skills with “Prerequisites” instructing users to run obfuscated shell scripts or download password-protected archives, culminating in payloads such as Atomic macOS Stealer (AMOS) — a malware family associated with credential theft and wallet targeting.
Whether the exact counts differ between reports, the
shape
is consistent:
Skills used as distribution
“Prerequisite” instructions used as persuasion
Infostealers used as the end goal
That end goal matters: modern infostealers aren’t after one password — they’re after
session tokens
,
browser profiles
SSH keys
cloud credentials
, and
crypto wallets
. In other words: the stuff that turns one compromised laptop into a broader compromise.
Why agents make this worse than a normal scammy download link
If you’ve ever thought, “I wouldn’t fall for that,” you’re probably right when you’re calm and skeptical.
But agent workflows change the context:
Speed becomes the default.
You’re using an agent because you want to move quickly.
Cognitive load is outsourced.
The agent turns a messy instruction page into a confident checklist.
Authority is borrowed.
If the agent says “This is the standard dependency,” it feels vetted.
In other words: the agent doesn’t need to be “tricked” in a technical sense. It just needs to be present while you’re being nudged to do a risky thing. That’s enough to tip behavior.
And if you
do
allow the agent to run commands directly, a malicious skill can become “hands-free compromise.”
‘But what about MCP? Isn’t that supposed to make tools safer?’
Model Context Protocol (MCP) is a real step forward for structuring tool access. It standardizes how hosts expose tools, resources, and prompts, and it emphasizes user consent and control.
However, MCP doesn’t magically make “skills” safe.
Why?
Skills can instruct users to run commands outside the MCP boundary.
Skills can link to scripts or downloads that never touch MCP.
Not every skill uses MCP at all.
MCP can help when the host implements strong permissioning, clear consent prompts, logging, and safe defaults. But a markdown-based distribution mechanism can still route around it through plain old social engineering.
This is the agent version of supply-chain security (and we’ve been here before)
The software world learned the hard way that:
Popular registries get abused.
Typosquatting works.
“Install this helper” is a common entry point.
The most valuable victims are the ones building things.
Skills marketplaces combine those lessons with two new accelerants:
The “package” can be instructions
, not code — and instructions are harder to scan reliably.
The runtime environment is credential-rich
by design: browsers logged into everything, terminals with SSH keys, cloud CLIs, password managers, and local files.
In a sense, a skills marketplace is an app store where the top apps are allowed to say “Copy-paste this into Terminal to enable the feature.” That’s not a solvable problem with one checkbox.
Practical defenses (for normal users)
If you’re experimenting with an agent that has local access, you need to treat it like a new operating system user with superpowers.
Here’s the pragmatic baseline:
Use a dedicated machine or VM
for agent experiments. No saved corporate logins. No production SSH keys. No cloud admin sessions.
Default to “no” on one-liner installers.
Especially anything that pipes curl into sh, uses base64, or asks you to remove OS protections.
Don’t trust “top downloaded.”
Popularity is a growth hack, not a security model.
Rotate what matters first if you already ran something.
Browser sessions, SSH keys, API tokens, cloud keys.
Prefer skills that are source-controlled and reviewable
(Git repos with history, known maintainers, clear provenance).
What marketplaces should do (if they want to survive)
If you run a public skills registry, you are running an attack surface.
A few practical steps that meaningfully raise attacker cost:
Publisher reputation and provenance
(verified identities, history, signing).
Automated scanning
for suspicious patterns (encoded payloads, obfuscated one-liners, quarantine removal, password-protected archives, “install core dependency” with offsite links).
Warning UI friction
for external links and shell commands.
Fast takedown and visible incident response
(treat it like an app store, not a pastebin).
None of these are perfect, but they buy time — and time is what defenders need.
What agent builders should assume going forward
If you’re building the agent runtime itself, assume skills will be weaponized.
That means:
Default-deny command execution
(require per-command consent, not once-and-forever toggles).
Strong sandboxing
for file system and browser access.
Scoped, time-bound permissions
with easy revocation.
Auditable logs
of what the agent read and what it executed.
The end state is the same direction the cloud took years ago: identity, policy, least privilege, and audit trails — but brought down to the workstation level.
Bottom line
The OpenClaw skills story isn’t just “some people uploaded malware.” It’s a preview of the next supply-chain battlefield:
skills as distribution, markdown as an execution path, and agents as the accelerator.
If agents are going to live on our personal and work machines, the ecosystem needs a trust layer that treats skills marketplaces like app stores, treats documentation like code, and treats “helpful automation” as a privileged operation — not a casual convenience.
Sources
https://www.theverge.com/news/874011/openclaw-ai-skill-clawhub-extensions-security-nightmare
https://1password.com/blog/from-magic-to-malware-how-openclaws-agent-skills-become-an-attack-surface
https://cyberinsider.com/341-openclaw-skills-distribute-macos-malware-via-clickfix-instructions/
https://agentskills.io/what-are-skills
https://modelcontextprotocol.io/specification/2025-06-18
←
Previous Post
Next Post
→
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Ikea’s bargain Matter-over-Thread devices are stumbling at the hardest step: getting connected
Should AI chatbots have ads? What Anthropic’s ‘no ads’ stance really means
Malicious AI-agent ‘skills’ are turning documentation into a distribution channel for infostealers. Here’s how it works — and how to defend against it.
Document Title
Page not found - Florin.blog
Image Alt
Florin.blog
Title Attribute
Florin.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Page Content
Page not found - Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?
Search for:
Search
Quick Links
Outdoors
About
Contact
Explore
Bestsellers
Hot deals
Best of The Year
Featured
Gift Cards
Help
Privacy Policy
Disclaimer
: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.
Florin.blog
Florin.blog » Feed
RSD
Search...
t Italiano