Agenti AI open source rubano 600.000 carte di credito

Cosa ha documentato Gambit

Una campagna di furto di carte di credito gira da luglio 2026 su framework per agenti AI distribuiti in open source, ed era ancora attiva al 22 settembre. A scoprirla è stata Gambit, startup di sicurezza, che ha ottenuto accesso diretto a un server di staging dell'attaccante.

I numeri pubblicati il 23 settembre 2026 da BleepingComputer^[1]: oltre 600.000 record di carta validi presi a due aziende, skimmer attivi su almeno 119 siti, 27 imprese compromesse in cinque giorni.

Fra le vittime figurano una catena di ospitalità del Fortune 500, una grande compagnia aerea statunitense, un distributore industriale americano e un retailer di moda online. La ricerca primaria resta quella pubblicata sul blog di Gambit Security^[2]. Il dettaglio che pesa di più è un altro.

Un unico operatore umano, indicato dai ricercatori come cinese, ha dato agli agenti istruzioni brevi sugli obiettivi dell'operazione. Tutto il resto lo hanno eseguito i modelli.

Tre agenti, tre ruoli distinti

La catena d'attacco poggia su tre strumenti, ognuno con un compito separato.

• Strix: framework di penetration testing, usato per scansione e scoperta di vulnerabilità
• Cairn: motore di sfruttamento autonomo, guidato da obiettivi del tipo "ottieni una shell" oppure "ottieni accesso admin"
• Hermes: orchestrazione della campagna, decisioni tattiche e lavoro post-exploitation, appoggiato al modello claude-opus-4.6

Hermes portava al suo interno una persona chiamata "SOUL - Red Team Operator" e 121 skill caricate, di cui 78 legate all'attacco. È un profilo da operatore red team confezionato come pacchetto software.

Questa separazione dei ruoli conta parecchio. Ricognizione, sfruttamento e orchestrazione restano moduli sostituibili: chi gestisce la campagna può cambiare il motore di exploit e tenere il resto dello stack. L'architettura ricalca una pipeline CI, con gli stessi vantaggi di manutenzione.

Il Cairn di questa campagna va tenuto distinto dall'omonimo strumento di analisi malware rilasciato da Cisco Talos il 22 settembre 2026. Stesso nome, finalità opposte.

Il punto tecnico interessante è che tutti e tre girano su codice pubblico. Il vantaggio dell'attaccante arriva dall'integrazione dei pezzi, più che dalla potenza del singolo componente.

La cadenza: 105 ondate in cinque giorni

Fra il 23 e il 31 agosto 2026 Strix è stato lanciato 146 volte contro 138 host, per un totale di 633 ore di scansione. Fra il 10 e il 15 settembre l'attaccante ha lanciato 105 ondate distinte, con esito positivo su almeno 27 bersagli.

Questo volume descrive una fabbrica, più che un intruso.

Un team umano equivalente richiederebbe turni, coordinamento e un budget mensile a sei cifre. Qui il costo marginale della ventottesima vittima tende a quello di una chiamata API. L'economia dell'attacco si ribalta: il collo di bottiglia passa dalle ore-uomo ai token.

Per chi difende, la conseguenza pratica riguarda la finestra temporale. La distanza fra la scansione e lo sfruttamento si comprime da settimane a ore, e un ciclo di patch mensile diventa aritmeticamente inadeguato.

Sei modi di piantare lo skimmer

L'iniezione del codice di skimming variava in base al livello di accesso ottenuto, alle falle trovate e all'architettura del bersaglio. I metodi osservati dai ricercatori coprono l'intera pila tecnologica.

• Codice aggiunto in coda a file JavaScript legittimi
• Tag script inseriti nelle pagine di checkout o nei blocchi Google Tag
• Avvelenamento di contenuti su S3 e CDN, oltre che di cache lato server
• Modifica di campi nel database
• Alterazione di deployment Kubernetes
• Cron job che ripristinano lo skimmer dopo la rimozione

L'ultima voce merita attenzione. Un cron job di ripristino trasforma la bonifica in un loop: il team rimuove il payload, la pianificazione lo riscrive, il monitoraggio segnala pulito nella finestra sbagliata.

La lista descrive un avversario che conosce le pipeline di deploy moderne. Kubernetes e CDN erano trattati come superfici di persistenza al pari del filesystem. Questo livello di competenza operativa, applicato a centinaia di bersagli in parallelo, era prima appannaggio di gruppi strutturati.

La selezione dei bersagli passava per un servizio di classifica del traffico web, applicato alla lista prodotta da Strix, con priorità ai siti su piattaforme custom. La logica economica è lineare: traffico alto significa più carte per ora di lavoro dell'agente.

La condizione di fondo: il runtime è pubblico

La condizione che lega i tre componenti è semplice: sono progetti aperti, installabili in pochi minuti. Il rilascio di un runtime open source per agenti AI distribuisce capacità offensiva e capacità difensiva con la stessa licenza.

Questa è una proprietà strutturale, e va trattata come tale nelle valutazioni di rischio.

La comunità della sicurezza ha già vissuto il caso Cobalt Strike e quello di Metasploit. La differenza oggi riguarda il piano di controllo: gli strumenti precedenti richiedevano un operatore per ogni sessione, mentre questi accettano un obiettivo in linguaggio naturale e producono decisioni tattiche in autonomia.

Chi controlla l'orchestrazione controlla l'architettura, e qui l'orchestrazione costa zero. La difesa perde il vantaggio che derivava dalla scarsità di operatori capaci.

Il corollario per chi compra tecnologia: la stima di rischio basata su "quanto è difficile trovare gente brava" è scaduta. Va sostituita con una stima basata sul throughput che un avversario riesce a comprare con qualche centinaio di dollari di inferenza.

Quanto di questo è davvero nuovo

Qui serve equità intellettuale. Gli agenti hanno sfruttato falle web classiche: accessi mal configurati, componenti esposti, catene di deploy permissive. La ricerca descrive volume e velocità, più che una classe di exploit inedita.

Il dato è insieme rassicurante e scomodo.

Rassicurante perché l'igiene di base funziona ancora: gestione delle patch, segmentazione, integrità dei file serviti, controllo dei tag di terze parti sulle pagine di pagamento. Scomodo perché la stessa igiene, applicata con i ritardi tipici di un'azienda media, lascia aperta una finestra che un agente sfrutta in poche ore.

Va detto con chiarezza: il rapporto documenta la campagna e le sue metriche, e lascia fuori i dettagli sul tasso di errore degli agenti. Quante delle 105 ondate siano fallite per allucinazione del modello, e quante per difese efficaci, resta materia aperta. Una lettura onesta tiene conto di questo margine.

Tre domande per il team AI enterprise

Queste domande vanno poste nella prossima riunione di sicurezza applicativa, con una risposta scritta a verbale.

1. In quanti minuti il team rileva la modifica di un file JavaScript servito in produzione, e con quale controllo di integrità?
2. Quale processo verifica i tag di terze parti caricati sulle pagine di checkout, e con quale cadenza?
3. Quanto tempo passa fra la pubblicazione di una CVE sui componenti esposti e la patch effettiva sul perimetro pubblico?

La prima domanda misura la capacità di vedere lo skimmer. La seconda misura il controllo sulla superficie di pagamento, che resta il bersaglio economico dell'intera campagna.

La terza misura la distanza fra il ciclo di patch interno e la cadenza dell'avversario. Un valore espresso in settimane indica un rischio accettato in modo implicito, e andrebbe portato in consiglio come tale.

Chi risponde "il monitoraggio copre il perimetro" ha già dato la risposta sbagliata: gli skimmer descritti vivevano dentro asset legittimi, serviti dal CDN aziendale.

Un quarto elemento merita spazio nel verbale: la lista dei domini che servono JavaScript alle pagine di pagamento. Nella maggior parte delle imprese quella lista è più lunga di quanto il team si aspetti, e conviene ridurla prima del prossimo picco di traffico.

Decisioni per il prossimo ciclo di pianificazione

Per il CTO la revisione riguarda la catena di consegna del frontend. Integrità dei bundle, firma degli artefatti e Subresource Integrity sulle pagine di pagamento passano da buona pratica a requisito.

Per l'Head of Engineering il punto è la velocità di rilevamento, più che l'ampiezza degli strumenti. Un controllo di hash sui file serviti, eseguito ogni pochi minuti, intercetta buona parte dei metodi di iniezione elencati dai ricercatori.

Per il CFO cambia il profilo di rischio della spesa in sicurezza applicativa. Il costo atteso di un incidente su e-commerce sale, perché la probabilità di essere raggiunti cresce con il throughput dell'attaccante. Le voci di budget su WAF, bot management e integrity monitoring vanno rilette in questa luce.

Per il comitato acquisti tecnologia la domanda contrattuale è una sola: quale fornitore di CDN, tag manager e piattaforma e-commerce garantisce per iscritto il rilevamento delle modifiche ai contenuti serviti, e in quale tempo? Le clausole generiche sulle "best practice di sicurezza" vanno sostituite con SLA misurabili, con penali collegate.