Dopo la prima pubblicazione di questo articolo, il progetto precedentemente noto come Clawdbot e Moltbot ha completato un altro rebranding e ora si chiama OpenClaw. L'architettura agenziale sottostante e le considerazioni sulla sicurezza discusse in questo articolo rimangono rilevanti anche con il nuovo nome.
---
Clawdbot è emerso come uno degli agenti AI open source più discussi all'inizio del 2026, non perché fosse un altro chatbot, ma perché ha superato un limite che molti strumenti non avevano superato. Ha combinato modelli linguistici di grandi dimensioni con un accesso diretto e autonomo a sistemi operativi, file, credenziali e piattaforme di messaggistica.
Ma ciò che gli utenti hanno guadagnato in termini di produttività, gli aggressori lo hanno guadagnato come nuova superficie di attacco.
E quando Clawdbot ha cambiato nome in Moltbot a causa di problemi relativi al marchio registrato, il profilo di rischio è cambiato nuovamente. Non perché l'agente sottostante fosse cambiato, ma perché la rapida popolarità si è scontrata con l'impreparazione operativa. Nella fretta di rinominare repository, domini e account social, sono emerse lacune nella proprietà. Gli aggressori hanno agito più rapidamente dei gestori, dirottando identità abbandonate e sfruttando la fiducia della comunità in pochi secondi.
Il passaggio del progetto a OpenClaw è stato accompagnato da una rinnovata attenzione alla progettazione incentrata sulla sicurezza e da avvertimenti più chiari sui rischi dell'accesso autonomo al sistema, a dimostrazione del fatto che i responsabili della manutenzione riconoscono ora il divario in termini di rafforzamento della sicurezza evidenziato dai primi utenti.
Ora la diffusione esplosiva dello strumento gioca a favore degli hacker. Un numero sempre crescente di utenti è desideroso di provarlo, clonarlo, integrarlo ed eseguirlo con ampie autorizzazioni prima ancora che le questioni relative alla sicurezza siano state comprese appieno. Questa combinazione di privilegi elevati, diffusione virale e momentanea confusione di identità trasforma uno strumento di automazione già sensibile in un obiettivo altamente appetibile.
Clawdbot non è progettato per essere esposto per impostazione predefinita. Se non ti senti a tuo agio nel rafforzare la sicurezza di un server, comprendere i limiti di affidabilità dei proxy inversi ed eseguire servizi con privilegi elevati con controlli minimi, non è consigliabile implementarlo su un VPS pubblico.
Il progetto presuppone un livello di maturità operativa che molti utenti sottovalutano, e la maggior parte dei fallimenti riscontrati finora nel mondo reale sono riconducibili alla configurazione, non agli exploit.
Questa non è la storia di un progetto di intelligenza artificiale fallito. È la storia di come si formano gli attacchi moderni quando la fiducia, l'automazione e l'identità si muovono più velocemente dei controlli di sicurezza.
Per capire perché Clawdbot attira così rapidamente gli aggressori, è utile osservare come funziona effettivamente l'agente una volta distribuito.
TL;DR
- Moltbot trasforma l'automazione in una superficie di attacco ad alto privilegio quando è esposta o configurata in modo errato.
- La maggior parte delle violazioni nella realtà deriva da errori di configurazione e abuso di fiducia, non da vulnerabilità zero-day.
- Una volta compromesso, l'agente consente il furto delle credenziali, il movimento laterale e il ransomware.
- Gli agenti autonomi di intelligenza artificiale devono essere trattati come infrastrutture privilegiate, non come strumenti di produttività.
- Se non è possibile rafforzarlo e monitorarlo, non esporlo.
Il resto di questo articolo spiega come Moltbot sia diventato così rapidamente un obiettivo appetibile , come gli aggressori lo sfruttino nella pratica e cosa questo significhi per il futuro della sicurezza dell'IA agentica. I lettori alla ricerca di indicazioni operative possono passare direttamente alla sezione dedicata al rafforzamento della sicurezza verso la fine dell'articolo.
L'agente AI come superutente ombra persistente
Clawdbot è stato progettato per funzionare su infrastrutture controllate dall'utente, laptop, server domestici, cloud e persino computer a scheda singola. È in grado di eseguire comandi shell, leggere e scrivere file, navigare sul web, inviare e-mail o messaggi di chat e mantenere la memoria persistente tra le sessioni. In pratica, funge da livello di automazione altamente privilegiato, spesso contenente chiavi API, token OAuth, credenziali di chat e, talvolta, accesso a livello di root. Questo design riunisce più confini di fiducia in un unico sistema. Piattaforme di messaggistica, sistemi operativi locali, cloud e strumenti di terze parti convergono tutti attraverso un unico agente autonomo. Una volta implementato, Clawdbot non è più solo un'applicazione, ma diventa parte integrante della struttura di sicurezza dell'ambiente.
Dal punto di vista di un hacker, questa è la situazione ideale. Compromettere l'agente una volta sola per ottenere l'accesso a tutto ciò a cui può accedere, in tutti gli ambienti.
Una volta raggiunto quel livello di accesso, gli aggressori non hanno bisogno di nuove tecniche, ma semplicemente riutilizzano quelle già note attraverso un intermediario molto più capace.
Come gli hacker sfruttano Clawdbot nella pratica
Una volta implementato Clawdbot, ora Moltbot, la domanda non è più se possa essere utilizzato in modo improprio, ma come. Alcune tecniche sono già state segnalate (esposizione a configurazioni errate e trucchi della catena di approvvigionamento), mentre altre, come l'iniezione di prompt, sono ben documentate nella ricerca e diventano realistiche quando gli agenti possono leggere contenuti non attendibili ed eseguire strumenti.
Accesso iniziale: dove l'agente diventa il punto di ingresso
Il modo più comune in cui Clawdbot viene compromesso non è attraverso un exploit ingegnoso, ma attraverso una semplice esposizione. L'interfaccia utente di controllo è un'interfaccia amministrativa pensata per essere accessibile localmente. In pratica, alcuni utenti la rendono accidentalmente raggiungibile dalla rete Internet pubblica a causa di configurazioni errate, porte aperte o impostazioni proxy non sicure.
Quando ciò accade, una dashboard di amministrazione locale può iniziare a comportarsi come un pannello di controllo remoto.
Parte della confusione deriva dal modo in cui la parola esposto . In pratica, esistono differenze significative:
- Connessione a Internet: raggiungibile tramite IP pubblico e porta.
- Impronta digitale: rilevabile da Shodan o Censys perché la risposta HTTP corrisponde alle firme Moltbot o Clawdbot, anche se l'autenticazione è abilitata.
- Non autenticato o bypassato: è possibile accedere all'interfaccia utente di controllo senza un abbinamento o credenziali validi, spesso a causa di una configurazione errata. Si tratta di un caso pericoloso.
Questa distinzione è importante. Una volta che un'interfaccia amministrativa è raggiungibile dalla rete Internet pubblica, la scoperta diventa facile. Motori di ricerca come Shodan possono individuare rapidamente questi sistemi, trasformando un singolo errore di configurazione in un problema diffuso.
Gli screenshot pubblici che mostrano un gran numero di risultati relativi a Clawdbot possono essere fuorvianti. Molti rappresentano sistemi visibili ma comunque protetti. Il rischio reale risiede nel numero minore di casi in cui l'autenticazione è assente o inefficace.
In tali situazioni, l'interfaccia utente di controllo è accessibile dalla rete Internet pubblica e gli aggressori potrebbero essere in grado di visualizzare i dati di configurazione, accedere alla cronologia delle conversazioni o impartire comandi, a seconda di come è stato configurato l'agente.
Anche quando gli utenti ritengono che l'autenticazione sia abilitata, impostazioni predefinite non sicure e configurazioni proxy errate hanno consentito agli aggressori di aggirarla completamente. Non zero-day necessario zero-day . Una singola riscrittura dell'intestazione o una regola di inoltro può abbattere il confine tra accesso affidabile e non affidabile. Una volta all'interno, gli aggressori ereditano tutto ciò che l'agente può fare.
Non tutti gli accessi iniziali richiedono l'esposizione alla rete o una configurazione errata.
Ingegneria sociale e iniezione immediata
La capacità di Clawdbot di leggere e-mail, messaggi di chat e documenti crea una nuova superficie di attacco in cui il payload è il linguaggio, non malware.
L'iniezione di prompt è stata dimostrata nella ricerca e nelle configurazioni pratiche degli agenti: un messaggio appositamente creato può talvolta indurre un agente a divulgare dati sensibili o a compiere azioni non intenzionali, anche quando l'autore dell'attacco non entra mai direttamente in contatto con l'host.
La difesa non consiste tanto nel "correggere un bug", quanto piuttosto nel limitare ciò che l'agente può fare, chi può comunicare con esso e come gestisce i contenuti non attendibili.
Quando gli aggressori riescono a ottenere un punto d'appoggio sull'host, il design locale di Clawdbot crea un secondo percorso più silenzioso per il controllo.
Malware i dati di Clawdbot
malware Endpoint malware gli infostealer non necessitano di un exploit specifico per Clawdbot per trarre vantaggio dalle distribuzioni degli agenti. Se i token, gli artefatti OAuth o lo stato dell'agente sono memorizzati localmente, e in particolare se sono memorizzati in chiaro, una endpoint ordinaria endpoint può degenerare nel controllo dell'agente e di tutti i servizi connessi a cui può accedere.
In altri casi, gli aggressori non toccano mai direttamente l'host, ma arrivano attraverso estensioni e integrazioni affidabili.
Abusi nella catena di fornitura, plugin ed estensioni dannose
Il modello di plugin di Clawdbot introduce un altro vettore di accesso iniziale. Le estensioni vengono eseguite come codice sulla stessa macchina dell'agente e ne ereditano le autorizzazioni. Un plugin dannoso, o uno legittimo compromesso, funziona come un'esecuzione di codice remoto istantanea. L'agente diventa il meccanismo di distribuzione.
Oltre al software principale, gli aggressori hanno anche abusato dell'ecosistema circostante. Recentemente è stata utilizzata una falsa estensione Clawdbot VS Code per installare il trojan di accesso remoto ScreenConnect, sfruttando la fiducia degli sviluppatori nel nome del progetto per ottenere il controllo remoto completo. L'estensione sembrava legittima, riportava il marchio corretto e si basava sul tempismo e sulla notorietà del nome piuttosto che su una vulnerabilità del software.
Questo tipo di attacco diventa più efficace durante i rebranding. Quando i nomi dei progetti, i repository e i domini cambiano rapidamente, gli aggressori sfruttano la confusione pubblicando repository o estensioni simili che sembrano legittimi. La compromissione avviene spesso prima che il codice venga revisionato, perché la fiducia viene data per scontata in base al nome e alla tempistica.
La difesa in questo caso non riguarda tanto l'applicazione di patch quanto la verifica dell'identità. Dopo un rebranding, le installazioni dovrebbero essere limitate all'organizzazione GitHub ufficiale e al dominio del progetto. I repository di nuova creazione o sponsorizzati meritano un'attenzione particolare, mentre i plugin o le competenze dovrebbero essere limitati a liste di autorizzazioni selezionate.
Lo stesso vale per gli strumenti di sviluppo. Per le estensioni dell'editor, verificare l'editore, controllare la cronologia e la frequenza degli aggiornamenti e verificare gli hash o le firme, se disponibili. In questo ecosistema, la fiducia nella catena di fornitura fa parte dei confini di sicurezza.
Una volta installata un'estensione dannosa, non è necessario alcun ulteriore exploit e il controllo avviene immediatamente.
Comando e controllo: trasformare l'agente nel canale C2
Se un aggressore ottiene l'accesso all'interfaccia utente di controllo o a qualsiasi canale in grado di eseguire strumenti, Clawdbot stesso diventa il framework di comando e controllo. Attraverso l'interfaccia di controllo o l'API, è possibile eseguire comandi shell, raccogliere output e operare in modo interattivo. Il rischio non è che Moltbot violi magicamente la sicurezza da solo, ma che un agente compromesso disponga già di percorsi di esecuzione, persistenza e comunicazione integrati.
Abuso di integrazioni legittime
Clawdbot può inviare messaggi tramite Slack, Telegram, e-mail e altre piattaforme utilizzando credenziali legittime. Gli aggressori possono sfruttare queste integrazioni per sottrarre dati o ricevere istruzioni, mimetizzandosi perfettamente nel traffico normale. Dal punto di vista del rilevamento, questo sembra un comportamento di automazione previsto, non traffico C2.
Man-in-the-middle a livello cognitivo
Se un aggressore è in grado di modificare la configurazione dell'agente, i messaggi di richiesta o la memoria archiviata (ad esempio dopo aver ottenuto l'accesso al file system), può tentare di influenzare ciò che l'utente vede e ciò che l'agente fa.
In pratica ciò potrebbe significare modificare i riepiloghi, sopprimere gli avvisi o inserire istruzioni nascoste che si attivano in un secondo momento. È meglio considerarlo come un potenziale risultato di un compromesso, non come una funzionalità garantita in una configurazione adeguatamente isolata.
Il controllo dell'agente abbatte anche i tradizionali confini dei privilegi.
Elevazione dei privilegi e abuso delle credenziali
Se Clawdbot viene eseguito come utente standard, gli aggressori possono utilizzarlo per eseguire tecniche tradizionali di escalation dei privilegi. In molte implementazioni, l'escalation non è necessaria perché l'agente viene già eseguito con autorizzazioni elevate, in particolare nelle configurazioni containerizzate o a utente singolo.
Clawdbot centralizza le credenziali in modo sistematico. Chiavi API, token OAuth, credenziali di chat, cloud e, talvolta, accessi VPN sono tutti conservati in un unico posto. Una volta raccolte, queste credenziali consentono agli aggressori di impersonare gli utenti, accedere cloud e muoversi lateralmente senza toccare nuovamente il sistema originale.
Negli ambienti ibridi, questo impatto si moltiplica. Un agente compromesso in esecuzione su un laptop può esporre l'accesso SaaS aziendale. Uno in esecuzione nel cloud detenere autorizzazioni IAM che consentono agli aggressori di creare infrastrutture, accedere agli archivi dati o manomettere le pipeline CI/CD. L'agente diventa un ponte tra ambienti che non sono mai stati pensati per essere collegati direttamente.
Una volta ottenuto l'accesso, gli aggressori si concentrano sul rimanere sul posto senza essere notati.
Persistenza: quando l'agente ricorda l'autore dell'attacco
Poiché gli agenti spesso conservano lo stato a lungo termine su disco, un host compromesso può trasformare tale stato in persistenza. Se un aggressore è in grado di scrivere nella memoria o nella configurazione dell'agente, può lasciare istruzioni o artefatti che sopravvivono ai riavvii e continuano a causare azioni dannose fino a quando il sistema non viene ricostruito e i segreti non vengono ruotati.
Poiché Clawdbot è progettato per funzionare in modo continuo ed eseguire attività secondo una pianificazione prestabilita, gli aggressori possono incorporare azioni ricorrenti. L'esfiltrazione dei dati, l'enumerazione del sistema o le comunicazioni in uscita possono essere attivate automaticamente, senza ulteriori interazioni.
Con l'accesso alla shell, gli aggressori possono anche ricorrere a metodi di persistenza classici, attività pianificate, script di avvio o backdoor aggiuntive. La differenza è che Clawdbot spesso nasconde queste azioni dietro un'automazione legittima, rendendo più difficile l'analisi forense.
Il vero danno inizia quando l'agente compromesso viene utilizzato come ponte per tutto il resto.
Movimento laterale e impatto più ampio
Da un singolo agente compromesso, gli aggressori possono eseguire la scansione delle reti interne, riutilizzare le credenziali e spostarsi lateralmente. E poiché Clawdbot si estende spesso cloud personali, aziendali e cloud , la compromissione in un dominio porta spesso alla compromissione in tutti e tre.
I token rubati consentono agli aggressori di accedere alle piattaforme SaaS, agli strumenti di collaborazione interna e cloud . Possono impersonare gli utenti, inviare messaggi affidabili e diffondere ulteriori accessi attraverso canali social che i difensori raramente monitorano come percorsi di attacco.
All'estremo, gli aggressori possono utilizzare Clawdbot per distribuire ransomware, distruggere dati o sabotare operazioni. L'agente dispone già dell'accesso ai file, dei diritti di esecuzione e dei canali di comunicazione. Ogni azione distruttiva è semplicemente un altro "compito" che l'assistente deve portare a termine.
Nel loro insieme, questi comportamenti rivelano un cambiamento più ampio nel modo in cui si svolgono gli attacchi moderni.
Quando l'automazione diventa una superficie di attacco
Clawdbot racchiude in sé sia le promesse che i rischi dell'intelligenza artificiale autonoma. Offre una potente automazione, ma quella stessa autonomia crea una superficie di attacco di alto valore. Interfacce esposte, input dannosi e malware adattato malware agli aggressori di riutilizzare l'agente per il comando e il controllo, l'abuso di privilegi, la persistenza e il movimento laterale. Queste tecniche rendono meno netta la linea di demarcazione tra i tradizionali percorsi di intrusione e gli abusi guidati dall'intelligenza artificiale, con un impatto che si estende ai sistemi personali, cloud e alle reti aziendali. Un agente compromesso può consentire qualsiasi cosa, dal furto mirato di dati al ransomware su larga scala, a seconda di ciò a cui è collegato.
Clawdbot/Moltbot dovrebbe essere considerato come un'infrastruttura altamente privilegiata, non come un semplice esperimento da weekend, poiché centralizza le credenziali e può eseguire azioni su account e dispositivi. Autenticazione forte, esposizione di rete limitata e gestione attenta dei segreti sono requisiti fondamentali. Le organizzazioni devono avere visibilità su dove vengono eseguiti questi agenti, applicare la segmentazione e monitorare comportamenti anomali come azioni non richieste o comunicazioni inaspettate. L'iniezione di prompt aggiunge un ulteriore livello di rischio, in cui gli abusi possono essere invisibili a meno che non venga monitorato il comportamento stesso dell'agente.
Clawdbot si comporta come un superutente ombra all'interno dell'ambiente. Con la diffusione degli agenti autonomi, la lezione da trarre è semplice: capacità senza controllo significa esposizione. Ora spetta agli utenti e ai team di sicurezza proteggere questi agenti prima che lo facciano gli aggressori.
Comprendere questo cambiamento è solo il primo passo. Per ridurre il rischio è necessario trattare Moltbot come qualsiasi altro sistema privilegiato e applicare controlli mirati in materia di esposizione, identità, esecuzione e monitoraggio.
Come ridurre i rischi durante l'esecuzione di Moltbot
Gli agenti autonomi non falliscono con eleganza. Una volta implementati con un ampio accesso, piccoli errori di configurazione possono avere un impatto sproporzionato. L'obiettivo dell'hardening non è quello di rendere Moltbot "sicuro", ma di limitare il raggio d'azione, ridurre l'esposizione e rendere rilevabili gli abusi.
1. Lista di controllo per il rafforzamento della linea di base
2. Isolamento dell'host e dell'infrastruttura
- Non esporre l'interfaccia utente di controllo alla rete Internet pubblica. Preferisci una VPN come Tailscale o WireGuard, oppure un tunneling SSH verso localhost. Isola l'agente dai carichi di lavoro di produzione.
- Non eseguire Moltbot sullo stesso VPS che ospita servizi di backend, database o file personali.
- Rendi più sicuro SSH su qualsiasi VPS. Disattiva l'autenticazione tramite password e l'accesso come root, utilizza solo chiavi e attiva le regole del firewall oltre alla limitazione della velocità o fail2ban.
- Esegui l'agente come utente non root. Evita i container con privilegi e non montare mai il filesystem host o il socket Docker.
- Applicare regolarmente le patch. Applicare gli aggiornamenti del sistema operativo, aggiornare le immagini dei container e ruotare le chiavi a lunga durata.
3. Interfaccia utente di controllo e configurazione del gateway
- Collega il gateway e l'interfaccia utente di controllo a 127.0.0.1, a meno che non sia strettamente necessario l'accesso remoto.
- Abilita l'autenticazione dell'interfaccia utente di controllo e verifica le impostazioni del proxy inverso in modo che i client remoti non vengano trattati come localhost.
- Registra e avvisa in caso di nuovi accoppiamenti di dispositivi, modifiche alla configurazione ed eventi di esecuzione degli strumenti.
4. Canali e integrazioni
- Utilizza liste di autorizzazione rigorose per stabilire chi può inviare messaggi al bot. L'impostazione predefinita dovrebbe essere "rifiuta per impostazione predefinita".
- Disattiva o limita gli strumenti ad alto rischio come l'accesso alla shell, la scrittura di file e l'automazione del browser, a meno che non siano assolutamente necessari.
- Utilizza account separati con privilegi minimi per le integrazioni, come account Gmail dedicati, bot Slack con privilegi limitati e token GitHub limitati.
- Trattare i codici QR e gli URI che collegano i dispositivi come password. Non lasciare gli artefatti di accoppiamento in luoghi accessibili a tutti e, se esposti, ruotarli o ricollegarli.
- Preferisci account bot per servizio e limita l'esposizione. Evita i server Discord pubblici e blocca i messaggi diretti su un elenco di autorizzazioni.
5. Segreti e trattamento dei dati
Queste sono le posizioni predefinite comuni da controllare sul tuo host. Considerale sensibili e blocca le autorizzazioni:
Controlli aggiuntivi:
- Trattate l'agente come un gestore di segreti. Bloccate i permessi dei file e crittografate l'archiviazione ove possibile.
- Ruota e revoca i token in modo aggressivo dopo ogni sospetta esposizione. Preferisci token OAuth di breve durata rispetto a chiavi API di lunga durata.
- Limitare la conservazione della cronologia delle conversazioni e degli allegati. Un'impostazione predefinita semplice è di 7-14 giorni per i registri delle sessioni, con rotazione o eliminazione settimanale e crittografia a riposo se è richiesta una conservazione più lunga.
6. Iniezione immediata e contenuti non attendibili
- Considera che qualsiasi e-mail, documento, pagina web o messaggio di chat potrebbe contenere istruzioni ostili.
- Non consentire che testi non attendibili attivino direttamente comandi shell o esportazioni di credenziali.
- Utilizza criteri degli strumenti per canale. Ad esempio, consenti la sintesi su e-mail o Slack, ma nega le azioni di shell o scrittura di file da Telegram o Discord.
- Richiedi la conferma umana per azioni ad alto rischio come l'esecuzione di comandi, l'esportazione di file, la modifica delle impostazioni o l'avvio di accessi.
- Considera l'automazione del browser come un'attività ad alto rischio. Utilizza un profilo browser separato e disconnesso per l'agente e non riutilizzare mai una sessione personale.
- Un modello utile è l'etichettatura dell'origine dei contenuti combinata con una politica degli strumenti per origine e la conferma obbligatoria per gli strumenti ad alto rischio.
7. Monitoraggio e rilevamento, copertura minima praticabile
ATT&CK: abbreviazione per i difensori
- Accesso iniziale: interfaccia utente di controllo esposta o abuso della catena di approvvigionamento
- Esecuzione: invocazioni di shell e strumenti
- Accesso alle credenziali: token locali e file di configurazione
- Persistenza: configurazioni modificate, memoria o plugin
- Comando e controllo: canali di chat
- Esfiltrazione: upload e webhook
Segnali minimi da tenere d'occhio
- Controlla gli errori di autenticazione dell'interfaccia utente, gli accoppiamenti di nuovi dispositivi e le modifiche alla configurazione.
- Invocazioni di strumenti quali esecuzione di shell, lettura e scrittura di file, automazione del browser e upload in uscita
- Modifiche impreviste al filesystem in ~/.clawdbot/* e nell'area di lavoro dell'agente
- Attività di rete quali nuovi domini in uscita, picchi nella messaggistica o traffico webhook insolito
- Segnali host quali registri firewall sulle porte Moltbot, eventi di accesso SSH e processi secondari insoliti
8. Se sospetti un'esposizione: reagisci rapidamente
- Interrompi il servizio e conserva le prove. Crea uno snapshot della VM o del container e raccogli i log di sistema più ~/.clawdbot/*.
- Ruota e revoca le credenziali. Sostituisci i token, revoca le sessioni OAuth, ruota le chiavi SSH e riemetti le chiavi API a lunga durata.
- Invalidare i percorsi di accesso. Disabilitare i canali esposti, reimpostare gli elenchi di autorizzazioni e ruotare l'accoppiamento o le password dell'interfaccia utente di controllo.
- Cancella la cronologia sensibile, se opportuno. Elimina le trascrizioni delle sessioni se contengono informazioni riservate, quindi applica una conservazione breve.
- In caso di dubbio, ricostruisci. Se l'host era raggiungibile senza un'autenticazione forte o si sospetta l'esecuzione di comandi, ricostruisci da un'immagine pulita e ricollega attentamente i canali.
- Punti di persistenza post-controllo come servizi systemd, crontab, chiavi autorizzate SSH e plugin o estensioni installati.
Cosa portare con sé
- Trattate Moltbot come un'infrastruttura privilegiata. Conserva segreti, esegue comandi e comunica attraverso canali affidabili.
- La maggior parte dei guasti è dovuta a problemi di configurazione, non a exploit. Le interfacce utente di controllo pubblico, le impostazioni proxy deboli, i canali aperti e gli strumenti troppo potenti sono responsabili della maggior parte degli incidenti.
- L'identità fa parte della superficie di attacco. Fidati solo di organizzazioni, domini ed estensioni ufficiali, soprattutto durante i rebranding.
- Se non è possibile rafforzarlo, non esporlo. Mantenere l'interfaccia utente di controllo su localhost o VPN, limitare i canali e richiedere la conferma per le azioni rischiose.
Per difendersi da questo modello è necessario avere visibilità sul comportamento, non solo sulle risorse. È qui che entra in gioco la Vectra AI diventa fondamentale, fornendo ai team di sicurezza la capacità di rilevare i comportamenti degli aggressori che emergono quando l'automazione affidabile viene abusata in ambienti di identità, rete, cloud e ibridi, prima che tali comportamenti degenerino in una compromissione totale.
---
Fonti:
- Linee guida ufficiali sulla sicurezza di Moltbot/Clawdbot (rafforzamento, proxy inverso, autenticazione): https://docs.clawd.bot/gateway/security
- Sito ufficiale del progetto: https://molt.bot (anche https://clawd.bot)
- Repository/organizzazione GitHub ufficiale: https://github.com/moltbot/clawdbot (pagina dell'organizzazione: https://github.com/clawdbot/)
- Articolo didattico di Chirag (@mrnacknack) sulle configurazioni errate più comuni e sui percorsi di prompt injection (da utilizzare come contesto secondario): https://x.com/mrnacknack/article/2016134416897360212 (vedere anche i thread di @theonejvo).
- Copertura di Cointelegraph sui casi esposti e sul rischio di fuga di credenziali (tramite mirror TradingView): https://www.tradingview.com/news/cointelegraph:99cbc6b7d094b:0-viral-ai-assistant-clawdbot-risks-leaking-private-messages-credentials/
- Sintesi delle notizie di Binance sul dirottamento di GitHub/X + confusione sulla truffa dei token: https://www.binance.com/en/square/post/01-27-2026-clawdbot-founder-faces-github-account-hijack-by-crypto-scammers-35643613762385
- Cronologia della comunità DEV sul cambio di nome e sull'ondata di truffe e furti d'identità: https://dev.to/sivarampg/from-clawdbot-to-moltbot-how-a-cd-crypto-scammers-and-10-seconds-of-chaos-took-down-the-internets-hottest-ai-project-4eck
- Analisi di sicurezza Aikido di una falsa estensione Clawdbot VS Code:malware
- Registro delle modifiche del progetto (per tenere traccia delle modifiche relative alla sicurezza): https://github.com/clawdbot/clawdbot/blob/main/CHANGELOG.md
- Segnalazione secondaria sull'interesse degli infostealer per gli ecosistemi Clawdbot/Moltbot (indicativa, non definitiva): https://www.infostealers.com/article/clawdbot-the-new-primary-target-for-infostealers-in-the-ai-era/