Agenti IA a basso costo trasformano le intrusioni nei sistemi retail in una filiera per il furto di carte di pagamento

Decine di aziende compromesse nel corso di una campagna in rapida espansione

Un gruppo di minacce di lingua cinese, motivato da interessi economici, utilizza strumenti di IA autonomi per individuare vulnerabilità, sferrare attacchi e mantenere l’accesso a rivenditori online e ad altre organizzazioni.

La campagna è iniziata a luglio 2026 e da allora ha colpito almeno decine di aziende, secondo quanto emerso dall’indagine di Gambit. Tra il 10 e il 15 settembre, il gruppo ha avviato 105 progetti di attacco. Almeno 27 aziende sono state compromesse, con diversi livelli di accesso.

In genere, le intrusioni riuscite hanno richiesto meno di un giorno. In alcuni casi, il gruppo ha ottenuto l’accesso nel giro di poche ore.

L’operazione ha già avuto conseguenze finanziarie e operative significative. Gambit ha attribuito alle violazioni di due aziende il furto di oltre 600.000 dati di carte di pagamento non ancora scadute. Più di 488.000 carte erano statunitensi.

L’attaccante ha anche installato skimmer sui negozi online e ottenuto un certo livello di accesso a un’azienda del settore alberghiero appartenente alla lista Fortune 500. Tra le altre vittime identificate figurano una compagnia aerea statunitense, un distributore di forniture industriali e un rivenditore di moda online.

Non si trattava di un sistema completamente autonomo. L’operatore forniva istruzioni brevi, selezionava i bersagli e reindirizzava gli agenti dopo aver ottenuto l’accesso. Tuttavia, gran parte delle attività di ricognizione, sfruttamento e pianificazione degli attacchi era affidata a tre strumenti open source: Strix, Cairn e Hermes.

Strix e Cairn automatizzavano la ricognizione e lo sfruttamento

La prima fase si basava su Strix, uno strumento open source per i penetration test utilizzato per cercare vulnerabilità. Dal 23 al 31 agosto, il gruppo ha eseguito Strix 146 volte in modalità «deep» su 138 host.

L’attaccante ha usato lo strumento tramite OpenRouter, con i modelli GLM 5.2 e DeepSeek v4 Pro. I rapporti generati da Strix sono stati poi trasferiti a Cairn, un motore autonomo per i penetration test.

Cairn, configurato con DeepSeek v4.1 Flash, ha avviato i 105 progetti di attacco osservati tra il 10 e il 15 settembre. Gambit ha recuperato 48 rapporti di Cairn; gli altri erano stati eliminati.

Invece di applicare una sequenza di exploit prestabilita a ogni bersaglio, Cairn selezionava dinamicamente le strategie d’attacco, effettuando verifiche e tentando di sfruttare le vulnerabilità. Di conseguenza, tattiche, tecniche e procedure differivano per la maggior parte delle vittime.

Le informazioni disponibili non indicano quali vulnerabilità siano state sfruttate, la loro gravità o gli eventuali identificativi CVE. Non sono state rese note neppure le versioni precise dei software coinvolti. Non è quindi possibile associare una vulnerabilità specifica della campagna al catalogo Known Exploited Vulnerabilities della US Cybersecurity and Infrastructure Security Agency, né risulta nota una scadenza federale per gli interventi correttivi.

In assenza di CVE divulgate, le organizzazioni non possono contrastare questa campagna installando una singola patch identificata. Il rilevamento deve concentrarsi su modifiche non autorizzate, credenziali sottratte, compromissione delle applicazioni e meccanismi di persistenza riscontrati presso le singole vittime.

Hermes forniva all’operatore un’infrastruttura d’attacco persistente

Per orchestrare gli attacchi e gestire le operazioni interattive, il gruppo ha utilizzato Hermes, un agente autonomo open source dotato di memoria persistente, cronologia delle sessioni consultabile, console web, attività pianificate e capacità di creare nuove competenze.

L’attaccante ha configurato Hermes con un profilo di sistema in lingua cinese e 121 competenze, 78 delle quali pensate per attività offensive. L’agente operava con il modello opus-4.6 di Anthropic.

Gambit ha individuato 1.951 prompt inseriti da un operatore umano nel corso di 260 sessioni. In genere erano brevi istruzioni in cinese che chiedevano a Hermes di avviare un attacco, scegliere la successiva linea d’azione generale o eseguire un’operazione dopo aver ottenuto l’accesso.

Questa divisione dei compiti è rilevante. L’operatore non doveva specificare ogni comando né definire in anticipo l’intero percorso dell’intrusione. L’essere umano indicava gli obiettivi, mentre l’agente manteneva il contesto, attivava competenze specialistiche e supportava le diverse fasi dell’attacco.

Daniel Wilcock, analista di threat intelligence presso Talion Cyber Security, ha distinto queste attività dalle dimostrazioni controllate di penetration testing con IA. In questo caso, gli agenti venivano deliberatamente diretti contro organizzazioni, incaricati di continuare a cercare vulnerabilità e usati per rimuovere le prove.

L’operazione era anche poco costosa, poiché gli strumenti principali erano open source. Sulla base dei dati recuperati, Gambit ha stimato un costo medio di 25,46 dollari per 101 scansioni completate.

Il furto di carte avveniva sia dai database sia dalle pagine di pagamento

Gli attacchi miravano a sottrarre dati di pagamento attraverso più canali.

In due aziende vittime, il gruppo ha rubato almeno 600.000 dati di carte non ancora scadute. Gli investigatori hanno individuato una competenza di Hermes progettata per estrarre le informazioni sulle carte rubate dal database Magento della vittima. Non si conoscono le versioni precise di Magento né il metodo usato per ottenere l’accesso iniziale.

La manipolazione dei database ha anche comportato il rischio di danni irreversibili. In un episodio separato, che ha coinvolto un rivenditore di biciclette, all’agente era stato chiesto di cancellare le tabelle di staging che aveva creato. L’agente ha invece eliminato le tabelle di backup del rivenditore.

Altre vittime sono state infettate con skimmer che acquisivano i dati dalle pagine di pagamento. Inizialmente, Gambit ha confermato il coinvolgimento di 19 organizzazioni. In collaborazione con il ricercatore di sicurezza Varys, gli investigatori hanno poi individuato oltre 100 siti web infetti.

L’attaccante inseriva più spesso il codice dello skimmer in un file JavaScript già esistente, ma le modalità di installazione variavano notevolmente. Il codice dannoso veniva inserito anche tramite:

• Tag script aggiunti ai siti web.
• Il blocco Google tag del sito.
• Contenuti ospitati in un bucket AWS S3.
• Campi di contenuto del database.
• Un initContainer di Kubernetes.
• Il modello di pagina memorizzato nella cache della pagina di pagamento.

Questa varietà rende insufficienti le scansioni basate soltanto sui file. Un pacchetto usato per la pagina di pagamento può apparire pulito anche se il codice dannoso viene iniettato da un database, da un oggetto ospitato nel cloud, da un container di inizializzazione o dalla configurazione di un sistema di gestione dei tag.

La persistenza sopravviveva alla reinstallazione pulita dell’applicazione

Un’intrusione ai danni di un rivenditore di vini statunitense mostra come il gruppo si sia adattato quando le normali procedure di ripristino hanno rimosso lo skimmer.

La reinstallazione dell’applicazione del rivenditore aveva ripristinato un pacchetto pulito per la pagina di pagamento, eliminando temporaneamente la modifica dannosa. L’operatore ha reagito creando un’attività cron nella directory dei log di JBoss.

L’attività controllava ogni due minuti le dimensioni del file interessato. Se la reinstallazione ripristinava il file legittimo, l’attività inseriva nuovamente lo skimmer.

Questo meccanismo poteva far sembrare che l’infezione ricomparisse da sola dopo la bonifica. Dimostra inoltre che sostituire i file modificati del front-end non è necessariamente sufficiente a rimuovere il punto d’appoggio dell’attaccante.

L’uso di una directory dei log per un componente di persistenza pianificato può complicare ulteriormente le indagini, se i difensori si concentrano solo sulle directory del codice applicativo. È necessario esaminare separatamente le attività pianificate, i percorsi di servizio scrivibili e i file insoliti nelle directory di JBoss.

È particolarmente importante preservare le prove. Il gruppo ha eliminato alcuni rapporti di attacco e i suoi strumenti hanno anche rimosso dati delle vittime o distrutto per errore i backup. Ricostruire i sistemi prima di raccogliere i log e le prove volatili può cancellare informazioni necessarie a ricostruire l’intrusione.

La priorità era data ai rivenditori con codice personalizzato

Il gruppo selezionava i bersagli utilizzando un servizio di classificazione del traffico web, dando priorità ai rivenditori che usavano codice personalizzato. L’operatore ha inserito 301 risultati nella console d’attacco.

Almeno due bersagli sono stati selezionati manualmente perché l’attaccante era già in possesso delle password di amministrazione. Non è noto come le avesse ottenute.

Le applicazioni retail personalizzate presentano superfici d’attacco ampie e molto diverse tra loro. In questa campagna, gli strumenti automatizzati potevano esaminare ogni ambiente e adattare la strategia, invece di dipendere da un’unica vulnerabilità comune a tutte le vittime.

Questa flessibilità aiuta a spiegare perché tra le vittime figurassero anche organizzazioni che non operano nel commercio online tradizionale. L’operazione ha raggiunto aziende dei settori alberghiero, aeronautico, della distribuzione industriale e della moda, anche se non è stato reso noto il livello preciso di accesso ottenuto in ciascuna di esse.

I difensori devono esaminare ogni componente delle pagine di pagamento

Per questa campagna non sono state pubblicate patch dei fornitori, soluzioni alternative convalidate o procedure di bonifica confermate. Le organizzazioni che gestiscono pagine di pagamento dovrebbero quindi indagare sia sulla compromissione iniziale sia sui diversi punti utilizzati per reinserire gli skimmer.

Le misure prioritarie includono:

1. Esaminare JavaScript e tag script delle pagine di pagamento per individuare aggiunte non autorizzate, comprese le modifiche inserite in file altrimenti legittimi.
2. Verificare le configurazioni di Google tag e individuare il codice aggiunto o modificato di recente.
3. Ispezionare gli asset ospitati su S3 caricati dalle pagine di pagamento, compresa, ove disponibile, la cronologia degli oggetti e i log di accesso.
4. Cercare script iniettati o riferimenti sconosciuti nei campi di contenuto dei database e nei modelli di pagina memorizzati nella cache.
5. Esaminare gli initContainer di Kubernetes per individuare comandi, immagini, mount o modifiche ai file non autorizzati.
6. Controllare le attività pianificate e le directory dei log di JBoss, in particolare quelle che monitorano le dimensioni dei file o riscrivono ripetutamente gli asset dell’applicazione.
7. Esaminare i database Magento per individuare accessi ai dati delle carte di pagamento, query sospette, staging di dati, attività di cancellazione e backup alterati.
8. Preservare le prove forensi prima di ricostruire i sistemi interessati, inclusi i log degli agenti, i dati di autenticazione, le attività dei database, i log di controllo del cloud e la cronologia delle distribuzioni.
9. Cambiare le credenziali amministrative esposte e determinare se password già in uso siano state sfruttate per selezionare o raggiungere specifici bersagli.

Le organizzazioni che individuano uno skimmer dovrebbero considerarlo una prova di una compromissione più ampia lato server, non soltanto di un asset web alterato. I meccanismi di persistenza osservati dimostrano che ripristinare una pagina di pagamento pulita può rimuovere il payload visibile, lasciando però intatto il percorso che consente all’attaccante di reinfettarla.