Gli infostealer ora rubano le sessioni degli agenti di coding. E le trovano in chiaro
Una ricerca Gen Digital documenta almeno dieci famiglie di malware che raccolgono token, configurazioni MCP e cronologie dei prompt di Claude Code, Cursor, Codex e Cline. Non è una falla degli agenti: è che i transcript sono file di testo, e la documentazione lo scrive.
Alessandro Saiani
Human in the Loop
L'8 settembre Gen Digital, il gruppo dietro Norton e Avast, ha pubblicato una ricerca su un cambio di abitudini nel mondo del malware. Gli infostealer, i programmi che una volta installati raccolgono tutto ciò che si può rivendere, hanno aggiunto una voce alla lista: i dati locali degli agenti di coding.
Non uno o due casi isolati. Amatera prende i dati di Cline e Continue. Remus quelli di Claude, Cursor e OpenCode. CallbackBeaver punta a Cursor e Claude, con oltre 5.000 campioni in trenta giorni. Djinn, su macOS, cerca Claude, Codex, Gemini, Cline, OpenCode e Kilo. E poi BeeStealer, STG, HydraStealer, APEX, Otter.
Cosa raccolgono, nelle parole della ricerca: "access and refresh tokens, credentials stored in MCP configurations, prompt histories, conversation databases, account details, and traces of the projects".
Perché il bottino vale più di un cookie
Un token rubato serve a entrare in un account. Questo i ladri lo facevano già con i browser. La differenza, qui, è nella riga che secondo me vale tutta la ricerca:
"In one archive, an attacker may obtain both the means to access an account and the context needed to understand what is valuable behind it."
Le chiavi e la mappa, nello stesso archivio. La cronologia di un agente di coding contiene i nomi dei progetti, la struttura del codice, i servizi collegati, i comandi lanciati. E soprattutto contiene tutto quello che è passato dentro la sessione.
Su questo la documentazione di Claude Code non lascia margini di interpretazione. I transcript stanno in ~/.claude/projects/, e "these files are plaintext. Anything that passes through a tool lands in a transcript on disk: file contents, command output, pasted text". Poco più sotto:
"Transcripts and history are not encrypted at rest. OS file permissions are the only protection. If a tool reads a
.envfile or a command prints a credential, that value is written toprojects/<project>/<session>.jsonl."
Rileggila pensando a una giornata normale. L'agente apre il .env per capire perché la connessione al database fallisce. Lancia un comando che stampa una variabile d'ambiente. Tu incolli una stringa di connessione per fare prima. Ognuna di queste cose finisce, in chiaro, in un file che resta sul disco.
C'è un dettaglio che chiarisce il quadro: la documentazione descrive la rimozione automatica dei pattern di chiavi e token solo per i dati che lasciano la macchina, quando mandi un feedback o condividi un transcript. Per i file che restano sul disco non ne parla. Il transcript locale è la copia integrale.
Ho guardato sulla mia macchina
Il default dichiarato è che i transcript si cancellano dopo 30 giorni. Sulla macchina su cui sto scrivendo ho contato, senza aprirli, cosa c'è in ~/.claude/projects: 866 transcript, 1,5 GB, il più vecchio del 3 maggio. Oltre quattro mesi fa, con cleanupPeriodDays mai toccato.
Non so dire con certezza perché. La documentazione elenca eccezioni che potrebbero spiegarlo: le sessioni avviate o riprese da Claude Desktop o da Cowork vengono conservate a qualunque età, e la pulizia si mette in pausa quando non riesce a determinare il periodo di conservazione. Il punto non è la causa. È che non si può dare per scontato che siano spariti: vanno controllati.
La porta d'ingresso
Per rubarli, ovviamente, qualcuno deve prima entrare nella macchina. E anche qui c'è una campagna costruita apposta per chi sviluppa.
Straiker ha documentato da marzo falsi siti di installazione di Claude Code, raggiunti tramite annunci Google e ricerche come "claude code install instruction": 88 domini su almeno dieci piattaforme, GitHub Pages e Netlify comprese. Il comando da incollare nel terminale sembra quello ufficiale, ma usa un & per far girare il curl legittimo in background mentre il payload parte in primo piano. Il risultato è ACRStealer, che fra le altre cose raccoglie chiavi API di Cline e configurazioni di Continue.
È lo stesso schema di sempre, applicato al nuovo pubblico: chi installa strumenti copiando un comando dal primo risultato di ricerca. L'avevamo visto con i pacchetti inventati dall'AI, qui cambia solo l'esca.
Cosa non cambia
Qui va riportato con precisione quello che scrivono gli autori, perché è la parte che i titoli allarmistici tagliano. I risultati "do not point to a new way of compromising the device" e "do not point to a vulnerability in an AI model or agent". Non c'è una falla in Claude Code o in Cursor: c'è un malware che, una volta dentro, ha imparato a guardare in una cartella in più.
E i numeri vanno letti per quello che sono: i 3,3 milioni di utenti del primo semestre sono rilevamenti su utenti protetti da un antivirus, non infezioni riuscite, e gli autori avvertono che possono sovrapporsi.
Quindi, se la tua macchina è pulita, stamattina non è cambiato niente. Quello che è cambiato è quanto costa il giorno in cui non lo è: prima perdevi le sessioni del browser, adesso perdi anche mesi di lavoro con dentro tutti i segreti che ci sono passati.
Cosa fare stasera
Cinque cose, tutte documentate e nessuna costosa.
- Guarda quanto pesa
~/.claude/projects. È il modo più rapido per capire di cosa stiamo parlando nel tuo caso. - Abbassa
cleanupPeriodDaysnelle impostazioni. Il minimo è 1. Attenzione a un consiglio che circola: impostarlo a 0 non disattiva la pulizia, secondo la documentazione fallisce la validazione. Se usi Desktop o Cowork, imposta anchedesktopSessionCleanupPeriodDays. - Valuta
CLAUDE_CODE_SKIP_PROMPT_HISTORY, la variabile che dice a Claude Code di non scrivere transcript e cronologia. Perdi la ripresa delle sessioni, e per molti è un prezzo accettabile. - Nega la lettura dei file di credenziali con le regole di permesso. Se l'agente non può aprire il
.env, il.envnon finisce nel transcript. - Installa solo dalla documentazione ufficiale, digitando l'indirizzo. E un comando da incollare nel terminale va letto per intero,
&compresi.
Nessuna di queste è una difesa contro un malware già installato. Sono il modo per fare in modo che, se succede, il bottino sia piccolo. Il file più pericoloso sulla tua macchina oggi potrebbe non essere il .env, ma il transcript della sessione in cui l'hai aperto.
Fonti: