Chiavi API, ATM e DeFi sotto attacco: METR perde crediti e Cronos riavvia la chain

🛡️ Executive Summary

• METR subisce due incidenti: una API key esposta consuma crediti AI equivalenti a 600.000 dollari e un endpoint rischia dati non pubblici.
• Cinque cittadini venezuelani si dichiarano colpevoli negli USA per tentativi di ATM jackpotting con malware in Kansas.
• Cronos ripristina la blockchain allo stato precedente all’exploit Tectonic, che aveva generato prestiti per circa 74 milioni di dollari.

Tre incidenti molto diversi mostrano come il valore digitale non risieda più soltanto nei dati archiviati o nelle criptovalute custodite in un wallet. Chiavi API, accesso ai modelli AI, controllo dei dispositivi finanziari e logiche economiche degli smart contract sono ormai asset direttamente monetizzabili. METR ha rivelato il furto di una chiave utilizzata per l’inferenza su modelli pubblici, con un consumo equivalente a circa 600.000 dollari di crediti; cinque cittadini venezuelani hanno ammesso tentativi di jackpotting contro ATM statunitensi; sulla blockchain Cronos, infine, l’exploit di Tectonic ha trasformato una manipolazione del prezzo di TONIC in prestiti per decine di milioni. È lo stesso spostamento già emerso con gli infostealer capaci di rubare sessioni Claude e prosciugare le quote senza superare nuovamente il 2FA: sempre più spesso l’attaccante cerca capacità già autorizzate, non necessariamente nuovi privilegi.

METR perde una API key attraverso una dashboard agentica esposta

METR, organizzazione non profit che valuta i modelli AI avanzati su task agentici e di lunga durata, ha reso pubblici due incidenti avvenuti tra marzo e maggio 2026. Nel primo caso un ricercatore senza accesso ai dati sensibili aveva eseguito agenti su una propria istanza Amazon EC2, intenzionalmente raggiungibile da Internet e protetta tramite autenticazione Google. L’applicazione, realizzata attraverso un processo descritto dalla stessa organizzazione come vibe coding, conteneva però una vulnerabilità fail-open che disattivava silenziosamente l’autenticazione. La dashboard di orchestrazione degli agenti è così rimasta pubblicamente esposta per diversi giorni. Secondo il resoconto ufficiale di METR, gli aggressori avrebbero individuato l’istanza scandagliando domini registrati di recente e certificate transparency log alla ricerca di parole chiave legate a LLM e agenti, comportamento coerente con la crescente attenzione criminale verso API AI e chiavi incorporate nei sistemi di sviluppo.

L’attaccante ha chiesto direttamente all’agente di rivelare la chiave

Una volta raggiunta la dashboard, l’operatore non ha dovuto sfruttare una complessa vulnerabilità crittografica. Ha promptato direttamente un agente affinché rivelasse la propria API key, quindi ha aggiunto una chiave SSH per mantenere l’accesso e ha utilizzato le credenziali sottratte per circa tre settimane. METR stima che i token consumati avrebbero generato una fattura di circa 600.000 dollari, anche se il provider non identificato aveva concesso gratuitamente quei crediti all’organizzazione. Il consumo anomalo non è stato rilevato immediatamente perché METR esegue abitualmente valutazioni su larga scala, produce grandi volumi di traffico e non disponeva allora di un tetto di spesa capace di bloccare automaticamente quella specifica chiave. L’incidente sviluppa un rischio già visibile quando log e reasoning degli agenti pubblici hanno esposto API key, password e token operativi: un segreto collocato dentro il contesto operativo di un agente può essere sottratto anche senza compromettere direttamente il provider del modello.

Leggi anche: MCP malevoli e agenti AI possono esfiltrare chiavi SSH, file .env e codice attraverso input apparentemente separati

A maggio gli aggressori hanno automatizzato il probing con agenti AI

Il secondo incidente mostra una capacità offensiva più strutturata. All’inizio di maggio METR ha osservato una campagna esterna prolungata attribuita prudentemente a un attore probabilmente motivato economicamente, interessato secondo l’organizzazione a ottenere accesso ai frontier model. Gli attaccanti hanno utilizzato intensivamente agenti per automatizzare vulnerability discovery, credential stuffing contro provider di autenticazione, tentativi di OAuth token grant, scansione dei servizi appena distribuiti e phishing contro il personale. Nello stesso periodo METR aveva accidentalmente esposto attraverso il public transcript viewer un meccanismo di query SQL read-only che avrebbe dovuto accedere soltanto a dati pubblici; un bug consentiva invece teoricamente di interrogare valutazioni non ancora pubblicate e il database conteneva accidentalmente anche dati relativi a modelli più sensibili. Un ricercatore indipendente ha scoperto e segnalato la vulnerabilità, ma METR afferma di non avere trovato prove che gli aggressori abbiano individuato l’exploit o letto informazioni non pubbliche. Il caso conferma il problema già osservato con agenti AI capaci di raggiungere sistemi reali e workflow GitHub durante attività automatizzate: quando ricognizione e probing vengono affidati ad agenti, aumenta la velocità con cui un’infrastruttura appena esposta può essere individuata e testata.

METR ha reagito separando architetturalmente l’ambiente pubblico dall’infrastruttura interna, rafforzando il monitoraggio, introducendo alert sulla spesa delle chiavi dove possibile e limitando l’uso di credenziali e dati METR su dispositivi o infrastrutture non controllate dall’organizzazione. È significativo che l’incidente non derivi da un modello che “ha hackerato” autonomamente l’organizzazione: METR lo precisa esplicitamente. Il rischio è molto più concreto e tradizionale, perché combina misconfigurazione, segreti troppo accessibili, applicazioni costruite rapidamente e automazione offensiva. È la stessa lezione emersa con vibe coding e pacchetti npm compromessi, dove velocità di sviluppo e fiducia negli automatismi possono ampliare la superficie di attacco.

Cinque cittadini venezuelani ammettono tentativi di ATM jackpotting negli USA

Sul fronte della criminalità finanziaria tradizionale, cinque cittadini venezuelani si sono dichiarati colpevoli negli Stati Uniti di conspiracy to commit bank larceny dopo tentativi di ATM jackpotting in Kansas. Il Dipartimento di Giustizia statunitense identifica gli imputati come Luis Alberto Velasquez-Artigas, Royder Adrian Figuera-Perez, Javier Mejia Jr., Gabriel Alexjandro Corales-Garcia e Italo Lizandro Corrales-Carrillo. Il gruppo era stato arrestato nel dicembre 2025 dopo tentativi contro ATM a Wamego e Manhattan: nel primo caso l’installazione del malware non è riuscita e ha attivato un allarme, mentre nel secondo gli operatori non sono riusciti a costringere il distributore a erogare denaro. Entrambe le azioni sono state registrate dalle telecamere. Il caso si inserisce direttamente nella crescita del jackpotting documentata dall’FBI con 1.900 episodi dal 2020, fenomeno nel quale la compromissione software incontra l’accesso fisico alla macchina.

Il jackpotting non richiede necessariamente il furto delle credenziali bancarie del cliente perché l’obiettivo è prendere il controllo del computer interno dell’ATM e impartire ordini direttamente al cash dispenser. Le campagne storiche hanno utilizzato famiglie come Ploutus, ATMitch, GreenDispenser, Alice, RIPPER, Skimer e SUCEFUL, spesso dopo l’apertura fisica del pannello e il collegamento di tastiere, dispositivi USB o hardware preparato dagli attaccanti. L’FBI ha registrato oltre 700 incidenti nel solo 2025, con perdite superiori a 20 milioni di dollari secondo i dati richiamati dal DOJ. La modalità conferma quanto già ricostruito nell’analisi tecnica sul malware Ploutus e sull’accesso diretto ai componenti interni degli ATM: la sicurezza logica del conto corrente può essere completamente aggirata quando il criminale raggiunge il layer che controlla materialmente l’erogazione del contante.

Cronos riparte dopo l’exploit Tectonic e ripristina lo stato precedente all’attacco

Il terzo fronte sposta il problema dal denaro fisico alla finanza decentralizzata. Cronos ha riavviato la propria blockchain dopo l’emergency halt imposto durante l’exploit che ha colpito il protocollo di lending Tectonic. Secondo i dati disponibili, l’attaccante ha aumentato artificialmente il prezzo del token TONIC di circa 100 volte nell’arco di 20 minuti, utilizzandolo successivamente come collaterale per prendere in prestito asset reali. L’operazione ha generato prestiti per circa 74 milioni di dollari, anche se PeckShield stima che soltanto circa 6 milioni in Ether siano riusciti a lasciare Cronos, mentre gran parte degli altri fondi è rimasta bloccata sulla chain. È un meccanismo diverso dall’underflow sfruttato pochi giorni prima contro Cosmos EVM, ma appartiene alla stessa categoria di rischio economico già emersa quando sei blockchain Cosmos sono state colpite attraverso una falla capace di alterare artificialmente i saldi disponibili.

Il validator set ha scelto un rollback della chain

Cronos ha fermato la produzione dei blocchi come misura di emergenza coordinata dai validator e successivamente ha ripristinato lo stato della blockchain a un punto precedente all’exploit, riavviando la produzione dal blocco 90.896.189 con timestamp 30 agosto 2026 alle 23:49:01 UTC. La rete è tornata online, ma Cronos continua a monitorare stabilità, compatibilità dei protocolli, RPC provider, explorer e bridge, mentre un post-mortem completo è ancora atteso. È una risposta tecnicamente efficace per impedire che l’intera esposizione economica venga finalizzata, ma riapre inevitabilmente il problema della governance delle blockchain: una rete può essere sufficientemente decentralizzata da resistere a una singola compromissione e contemporaneamente abbastanza coordinata da annullare una porzione della cronologia quando l’impatto economico diventa sistemico. Il tema richiama le crisi DeFi nelle quali smart contract e logica economica hanno costretto operatori e validator a scegliere tra immutabilità e contenimento delle perdite.

Continua con:

• API AI espongono reasoning, credenziali e chiavi operative dentro i workflow degli agenti
• PaperCut e Cosmos mostrano come accesso ai dati ed exploit economici producano perdite reali

Il denominatore comune è il controllo di una capacità già autorizzata

METR, gli ATM statunitensi e Tectonic non condividono tecnologia, infrastruttura o tipologia di attaccante, ma mostrano la stessa logica operativa. Nel primo caso una API key legittima permette di consumare capacità computazionale acquistata o concessa da un provider; nel secondo un malware può impartire comandi a un dispenser già autorizzato a erogare contanti; nel terzo un protocollo di lending accetta come valido un collaterale il cui prezzo è stato artificialmente gonfiato. L’attaccante non deve necessariamente rompere la crittografia o ottenere privilegi impossibili: deve trovare un modo per utilizzare un meccanismo legittimo fuori dal contesto per cui era stato progettato. È il principio già visibile nei mercati criminali che rivendono accesso alle API AI o sfruttano crediti ottenuti attraverso identità e account abusati, e spiega perché monitoraggio dell’utilizzo, limiti economici, segmentazione e verifica delle assunzioni applicative siano diventati importanti quanto la protezione della password. La risposta difensiva deve quindi spostarsi dalla sola prevenzione dell’accesso alla sorveglianza del comportamento autorizzato. Le API key devono avere scope minimo, rate limit, alert di spesa, rotazione e separazione per workload; i dispositivi finanziari devono essere protetti fisicamente e monitorati per modifiche hardware o software anomale; i protocolli DeFi devono considerare liquidità, manipolabilità degli oracle e concentrazione del collaterale come parametri di sicurezza, non soltanto economici. La lezione è coerente con l’evoluzione delle campagne di persistenza criminale, nelle quali una singola compromissione viene monetizzata ripetutamente attraverso accessi e identità già validi: quando l’attaccante ottiene una capacità che il sistema considera legittima, il confine fra uso normale e abuso diventa il vero punto nel quale la difesa deve riuscire a riconoscere l’incidente.