Cosa sostiene l’indagine su CARLIY0S
Il 21 ottobre 2026 Straiker ha pubblicato un’indagine su CARLIY0S, un sistema che, secondo l’azienda, sarebbe stato utilizzato da operatori associati a CyberCartel per coordinare attività contro oltre 400 obiettivi finanziari in America Latina. Tra le organizzazioni cercate figurano, secondo il rapporto, banche e fornitori di servizi di pagamento. La cifra si riferisce agli obiettivi: non dimostra che oltre 400 istituzioni siano state effettivamente violate.
Straiker afferma di aver basato l’indagine sull’accesso a un’istantanea di sistemi e materiali di lavoro attribuiti al gruppo, tra cui file di configurazione, script, infrastrutture e un archivio chiamato FinancialSoft. Questi elementi forniscono prove dirette di ciò che era presente in quell’ambiente, ma il rapporto non offre una verifica indipendente di ogni attacco e non identifica le organizzazioni coinvolte. Le attribuzioni e la portata delle operazioni vanno quindi considerate risultati dell’indagine dell’azienda, non una conferma pubblica delle responsabilità o dei danni subiti da ogni istituzione.
Anche la copertura del caso mette in evidenza questo limite: i nomi delle banche non sono stati resi noti e non è possibile stabilire pubblicamente quali istituzioni della regione siano state violate. Inoltre, nelle fonti disponibili non c’è un elenco verificabile che colleghi ciascuno degli oltre 400 obiettivi a un accesso riuscito, a un’esfiltrazione di dati o a perdite finanziarie.
Una catena di strumenti, non un unico agente autonomo
Straiker descrive CARLIY0S come una struttura distribuita che combinava operatori umani, script, strumenti di sicurezza e modelli commerciali. Il sistema si sarebbe basato su PentAGI, un framework per i test di sicurezza automatizzati, e su componenti che permettevano di condividere informazioni e delegare compiti. È più preciso definirlo un’operazione assistita e coordinata con l’IA che un agente capace di agire da solo.
Il rapporto attribuisce funzioni differenti a diversi modelli. Claude compare in una configurazione di agenti con compiti di analisi, generazione di codice o valutazione delle alternative; un modello sarebbe stato usato come coordinatore tramite Cursor. Grok è associato alla raccolta e classificazione di informazioni, mentre Kimi compare in configurazioni di riserva. La documentazione di configurazione, da sola, non prova che ogni modello sia stato eseguito con successo in ogni fase o contro ciascun obiettivo.
Sono descritti anche strumenti convenzionali per automatizzare le interazioni sul web, analizzare il traffico e sincronizzare dati tra computer. I modelli potevano fornire analisi o suggerimenti, ma l’accesso ai sistemi e l’esecuzione dipendevano da strumenti, credenziali, script e infrastrutture. La capacità effettiva di ciascuna fase, quindi, non si può dedurre dalla sola presenza di una configurazione di IA.
Il ruolo attribuito a ciascun componente
La tabella riassume ciò che Straiker afferma di aver osservato nei materiali attribuiti al sistema; non dimostra che ogni funzione sia stata completata in tutti gli attacchi.
| Componente | Funzione descritta | Limite delle prove |
|---|---|---|
| Claude | Analisi, discussione delle opzioni e coordinamento dei compiti in configurazioni con più agenti. | I file di configurazione non dimostrano che il modello sia stato invocato con successo in ogni operazione. |
| Grok | Raccolta o elaborazione di dati destinati a FinancialSoft. | L’esistenza di cinque «Grok miners» non prova l’origine o l’utilizzo di ogni singolo record. |
| Kimi | Modello alternativo o di riserva in determinati flussi di lavoro. | Una configurazione di riserva non dimostra che sia stata attivata in ogni caso. |
| Script e strumenti | Automazione della navigazione, gestione dei dati e collegamento con altri sistemi. | La presenza di software non conferma di per sé il successo di un’intrusione. |
| Operatori umani | Definizione degli obiettivi e supervisione dell’operazione descritta. | L’indagine non quantifica con precisione l’intervento umano in ogni fase. |
Cosa mostrano i registri e cosa non permettono di concludere
Nell’istantanea che Straiker afferma di aver esaminato, FinancialSoft conteneva 4.493 record. La descrizione comprende dati di conti finanziari, indirizzi e-mail, password, chiavi API e altri materiali sensibili. Tra i conteggi pubblicati figurano 2.911 indirizzi e-mail e 903 numeri di conto. Sono quantità attribuite all’inventario osservato, non una misura delle persone coinvolte né una conferma che tutti i dati fossero validi o siano stati utilizzati.
Il rapporto cita anche credenziali associate a infrastrutture di pagamento, comprese informazioni che potrebbero essere collegate a SPEI, il sistema messicano di pagamenti interbancari. L’esposizione di credenziali può aumentare il rischio di accessi non autorizzati o frodi, ma non basta a dimostrare che siano stati effettuati bonifici, che si sia avuto accesso ai conti dei clienti o che le credenziali fossero ancora attive.
L’azienda afferma di aver anonimizzato le organizzazioni e ripulito i materiali sensibili pubblicati. Di conseguenza, il lettore non può verificare l’identità delle entità né controllare pubblicamente lo stato di ciascun conto o chiave citati. Quantità e tipologia dei record giustificano attenzione sul piano della difesa, ma non vanno trasformate in un’affermazione di perdite concrete.
La risposta dei fornitori e la portata delle misure
Straiker afferma di aver condiviso indicatori pertinenti con i fornitori dei modelli. Secondo l’azienda, Anthropic ha revocato una credenziale compromessa utilizzata per accedere a Claude. Straiker ha inoltre dichiarato che xAI era stata informata e stava esaminando l’attività associata a cinque «Grok miners». Queste misure riguardano l’accesso a servizi specifici; non dimostrano che l’intera infrastruttura attribuita al gruppo sia stata disattivata.
I materiali disponibili non documentano misure concrete adottate da banche latinoamericane per bloccare gli agenti di IA e non indicano quali istituzioni stiano implementando controlli specifici. Non è quindi possibile affermare che, in seguito a questo caso, le banche della regione abbiano introdotto un blocco generalizzato degli agenti di terze parti. È importante distinguere questa questione dalle restrizioni preventive descritte in altri mercati, che non dimostrano una risposta delle istituzioni latinoamericane.
Dal punto di vista della difesa, il caso indica alcune aree che le istituzioni possono esaminare: credenziali esposte, autorizzazioni API, accessi ai portali amministrativi, attività insolite e collegamenti con servizi esterni. Sono ambiti pertinenti per contrastare i rischi di accesso e automazione, non garanzie di rilevamento né misure di cui sia stata confermata l’adozione da parte delle banche coinvolte.
Cosa verificare in caso di possibile esposizione di credenziali
Questi passaggi sono criteri generali di risposta; le fonti disponibili non confermano che una specifica istituzione li abbia applicati in questo caso.
- 01Individuare quali credenziali o chiavi potrebbero essere esposte e a quali sistemi consentono di accedere.
- 02Revocare o sostituire le credenziali interessate e verificare eventuali accessi o utilizzi insoliti.
- 03Esaminare i registri di autenticazione, l’attività delle API e le modifiche ai sistemi collegati.
- 04Limitare le autorizzazioni a quanto necessario e separare le funzioni di consultazione da quelle che consentono di eseguire operazioni.
- 05Continuare a monitorare i fornitori e i servizi esterni coinvolti nella risposta.
Cosa cambia — e cosa no — per la sicurezza dell’IA
L’importanza del caso non dipende dall’ipotesi che un modello abbia agito con autonomia generale. L’indagine descrive una combinazione di modelli commerciali, strumenti automatici, script, infrastrutture condivise e operatori. Questo insieme può contribuire a organizzare i compiti e ampliare la portata di un’operazione, ma il rapporto non permette di concludere che l’IA abbia sostituito gli aggressori o scelto ed eseguito da sola ogni azione.
Le prove presentate da Straiker costituiscono uno studio di caso basato su materiali che l’azienda attribuisce all’ambiente di lavoro degli operatori. Da sole, non misurano in modo indipendente la frequenza degli attacchi condotti con agenti e non dimostrano che la stessa architettura produca risultati analoghi con altri gruppi o in altri settori. La presenza di una configurazione di un modello non prova neppure che quel modello abbia generato un’intrusione riuscita.
La conclusione pratica è più circoscritta: le istituzioni finanziarie dovrebbero considerare la possibilità che strumenti di IA siano inseriti in flussi di lavoro offensivi già basati su software e infrastrutture tradizionali. La risposta non si limita a bloccare un modello: richiede anche di proteggere le credenziali, limitare le autorizzazioni, monitorare il comportamento di account e API e verificare gli incidenti attraverso registri tecnici. Le fonti disponibili non permettono di attribuire al caso una nuova misura normativa né di descrivere una politica comune delle banche latinoamericane.
Questioni aperte
- Le organizzazioni prese di mira non sono state identificate pubblicamente, quindi non è possibile verificare quali abbiano subito accessi riusciti.
- Non è pubblicata una corrispondenza verificabile tra gli oltre 400 obiettivi e il numero di istituzioni violate, i dati estratti o le perdite.
- La presenza di configurazioni di modelli nei materiali attribuiti al gruppo non dimostra che ogni modello sia stato eseguito con successo in ogni fase.
- Le fonti disponibili non confermano quali misure concrete abbiano implementato le banche latinoamericane per rilevare o bloccare gli agenti di IA.
Continua a esplorare
Fonti consultate
Correzioni e trasparenza
Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.
Proponi una correzione