Agenti AI autonomi: 600.000 carte rubate a 25 dollari l'una

L'economia di una violazione di carte di pagamento è appena cambiata. Per tutta la stagione di Magecart, montare una campagna di skimming contro un retailer reale significava un operatore esperto che spendeva giorni in ricognizione manuale, costruiva o comprava un exploit funzionante e restava con le mani sulla tastiera per ogni vittima. Il 23 settembre 2026 la startup di threat intelligence Gambit ha pubblicato la ricostruzione di una campagna che ha eliminato quasi tutto quel lavoro umano. Tre agenti AI pronti all'uso — uno per trovare la via d'ingresso, uno per entrare, uno per condurre l'operazione — hanno violato almeno 27 aziende e sottratto oltre 600.000 record di carte di pagamento valide, a un costo marginale di circa 25 dollari a bersaglio, secondo il report di BleepingComputer sui rilievi di Gambit.

Non è la storia di un nuovo exploit ingegnoso. Ogni tecnica impiegata ha dieci anni. È la storia di cosa accade al modello di minaccia quando il costo di eseguire quelle tecniche contro un'azienda reale scende al prezzo di una cena, e l'operatore non deve nemmeno essere sveglio per lanciarle.

Cosa ha ricostruito Gambit

Gambit ha recuperato l'infrastruttura di staging dell'operatore e ha ricostruito l'operazione a partire da essa. Il lavoro era diviso su tre agenti autonomi, ciascuno un progetto open-source esistente, concatenati da un umano che forniva solo i bersagli e gli obiettivi:

Agente	Ruolo	Cosa faceva senza supervisione
Strix	Ricognizione	Scansionava i bersagli, enumerava la superficie d'attacco, trovava vulnerabilità candidate
Cairn	Sfruttamento	Trasformava una candidata in una shell o accesso admin — "ottieni accesso" come obiettivo, non come script
Hermes	Orchestrazione	Memoria persistente, skill scritte da sé, job schedulati, archivio ricercabile delle sessioni e una console web per condurre la campagna

Il risultato misurato in una finestra di cinque giorni (10–15 settembre) è stato di 105 ondate d'attacco e almeno 27 aziende compromesse a vari livelli, secondo il resoconto di The Register sulla campagna. Gli skimmer sono stati confermati su 19 bersagli, con oltre 100 siti correlati identificati, e più di 600.000 record di carte validi sono stati estratti da appena due delle vittime. Tra i settori colpiti figurano una società di hospitality Fortune 500, una grande compagnia aerea statunitense, un grosso distributore industriale USA e un retailer di moda online. La campagna è attiva da luglio ed era ancora operativa il 22 settembre. L'attribuzione, sulle evidenze recuperate, indica un operatore cinese.

25 dollari a bersaglio: si è rotta la curva dei costi, non la tecnica

Il numero che dovrebbe preoccupare un CISO non è 600.000. È 25. Gambit ha trovato un account OpenRouter con 7.005,71 dollari spesi in circa quattro settimane al 25 agosto, con l'intera campagna stimata tra 12.000 e 18.000 dollari di fee di accesso ai modelli. Distribuito sui bersagli, sono poche decine di dollari ciascuno, e gli agenti colpivano circa dieci aziende al giorno. Dove l'accesso veniva ottenuto ci volevano di solito meno di un giorno — in molti casi poche ore — come ha osservato SecurityWeek nella sua copertura.

L'economia manuale di Magecart impone una selezione: un operatore sceglie una manciata di carrelli ad alto valore perché il suo tempo è la risorsa scarsa. L'economia autonoma rimuove la selezione. Quando un bersaglio costa 25 dollari e nessuna attenzione umana, la strategia razionale non è scegliere — è saturare. Ogni negozio di media dimensione con una pagina di checkout diventa un bersaglio, perché il tentativo marginale è quasi gratis e l'agente che fallisce passa semplicemente al nome successivo nella lista.

"Siamo troppo piccoli per essere un bersaglio" è sempre stata una scommessa sul fatto che un attaccante umano avrebbe speso il suo tempo limitato su qualcuno di più grande. Quella scommessa ora è contro un job schedulato che arriverà a te questa settimana, perché arrivare a te gli costa venticinque dollari e nessuna della sua attenzione.

Il payload dello skimmer in sé è ordinario — codice aggiunto ai file JavaScript, tag script iniettati nelle pagine di checkout, contenuti CDN avvelenati, campi di database modificati, deployment Kubernetes alterati. La novità è che un singolo operatore ha prodotto quel payload su 119 siti senza toccarne la maggior parte a mano.

Lo skimmer è silenzioso. L'esfiltrazione no.

Lo skimming lato client è costruito per essere invisibile sulla macchina. Lo script iniettato è piccolo, spesso offuscato, e si carica dentro la logica legittima di checkout. Gli strumenti endpoint sul web server non segnalano poche righe aggiunte a un asset JavaScript. Una scansione settimanale della pagina può mancare un payload che si attiva solo per una frazione di sessioni, o che vive in un edge CDN che lo scanner non recupera mai. È esattamente per questo che il PCI DSS ha imposto controlli sugli script lato client — ed è anche perché così tanti merchant scoprono gli skimmer solo quando li chiama la banca acquirer.

Ma uno skimmer che raccoglie dati di carte deve fare una cosa che non può nascondere: mandare i dati da qualche parte. I campi raccolti lasciano il livello di checkout come traffico in uscita, di solito piccole POST periodiche verso un endpoint di raccolta con cui l'ambiente non ha mai parlato prima. Quell'uscita è anomala sul filo indipendentemente da ciò che dicono i log dell'host compromesso:

• Un host web/checkout che storicamente serve soltanto traffico inizia improvvisamente a fare connessioni in uscita sostenute.
• La destinazione è un dominio e un ASN senza baseline precedente nell'ambiente — registrato di recente, o un sosia di un vero provider di analytics o CDN.
• Il traffico è cifrato (lo skimmer usa HTTPS) quindi l'ispezione a firma non vede nulla, ma il pattern comportamentale — beacon regolari, payload piccoli e uniformi, costanza fuori orario — è leggibile da un modello che ha imparato cosa è normale per quell'host.
• Uno skimmer ospitato su CDN aggiunge un secondo segnale: la pagina di checkout ora carica script da un'origine fuori dall'inventario dichiarato dal merchant.

Il punto che separa una campagna intercettata da un dwell time di 90 giorni è quando vedi l'uscita. Nel digest SIEM del mattino dopo, le carte sono già andate. Mentre il beacon si sta stabilendo, hai ancora la sessione.

Perché i tuoi log non ti salveranno

Gli agenti non si limitavano a rubare — ripulivano. La ricostruzione di Gambit ha trovato l'operazione configurata per, dopo aver estratto e scaricato tutti i dati delle carte, azzerare i campi di origine a lotti, e per usare job cron per ripristinare lo skimmer se veniva rimosso. Su un host con privilegi di root, quel comportamento è decisivo: le righe di database che proverebbero il furto vengono cancellate, i log applicativi sono scrivibili dall'attaccante, e ogni skimmer che rimuovi ricompare al tick di cron successivo.

È la lezione ricorrente di ogni compromissione di appliance e server che raccontiamo, e vale esattamente qui. La telemetria on-box è una dichiarazione dell'avversario, non una prova. L'unico record che l'attaccante non può modificare a posteriori è il traffico che ha già attraversato la rete — l'esfiltrazione delle carte in uscita, la callback verso un ASN mai visto, il fetch CDN da un'origine non autorizzata. Se la tua unica visibilità è sull'host compromesso, un operatore autonomo con una routine di pulizia ti consegnerà una macchina apparentemente pulita al posto di un database di carte rubate.

Remediation

Non c'è un singolo CVE da patchare qui — i vettori d'ingresso erano ordinarie vulnerabilità web che gli agenti trovavano su richiesta. La postura difendibile è controllo degli script, visibilità sull'uscita e caccia alla persistenza.

1. Sono esposto? — verifica dell'esposizione.

• Inventaria ogni script che si carica su una pagina di pagamento, inclusi quelli di terze parti e ospitati su CDN. Se non riesci a produrre quell'inventario, sei già fuori conformità PCI DSS.
• Confronta il JavaScript effettivamente servito a un browser al checkout con una baseline nota-buona. Lo skimmer aggiunge; un confronto per byte o per hash coglie l'aggiunta.
• Controlla CDN e object storage per asset modificati, e confronta i manifest Kubernetes distribuiti con il source control — la campagna alterava entrambi.
• Elenca job cron e task schedulati sugli host web e di checkout; cerca qualsiasi cosa riscriva contenuti web o ri-scarichi script remoti.

2. Colma il gap di controllo — PCI DSS 4.0.1. I requisiti 6.4.3 (gestione degli script — ogni script della pagina di pagamento inventariato, giustificato, autorizzato, con integrità verificata) e 11.6.1 (un meccanismo di rilevamento di modifica e manomissione sulle pagine di pagamento, eseguito almeno settimanalmente) sono obbligatori dal 31 marzo 2025, e i QSA ora bocciano gli assessment senza evidenze per entrambi. La guida del PCI Security Standards Council su sicurezza delle pagine di pagamento ed e-skimming è l'implementazione di riferimento. Imponi una Content-Security-Policy con nonce o hash perché uno script inline iniettato non venga eseguito, e usa la Subresource Integrity sugli script ospitati esternamente.

3. Non puoi ri-architettare ora? — controlli compensativi. Metti in allowlist l'uscita dal livello di checkout, così un host web possa raggiungere solo le destinazioni di cui ha legittimamente bisogno; uno skimmer che fa beacon verso un nuovo dominio fallisce allora in uscita. Porta il rilevamento di manomissione lato client dal settimanale al tempo reale. La riemissione delle carte spetta all'acquirer, ma segnala l'esposizione presto.

4. Caccia alla compromissione — segnali mappati su MITRE ATT&CK.

• POST in uscita da un host di checkout verso un dominio/ASN mai visto — Exfiltration Over Web Service (T1567) / over C2 (T1041).
• <script> inline iniettato o JS aggiunto sulle pagine di pagamento — Input Capture / web portal capture (T1056.003) via JavaScript (T1059.007).
• Pagina di checkout che carica script da un'origine CDN fuori inventario — Compromise Software Supply Chain (T1195.002).
• Web shell o artefatti di accesso admin dall'ingresso iniziale — Exploit Public-Facing Application (T1190), Server Software Component: Web Shell (T1505.003).
• Job cron che ripristinano contenuti rimossi (T1053.003); cancellazione a lotti dei campi carta (Data Destruction, T1485).

5. Eradica + verifica. Rimuovi lo skimmer e la sua persistenza — il job cron e ogni manifest di deployment alterato — nella stessa finestra, altrimenti torna al tick successivo. Ruota credenziali e API key raggiungibili dall'host compromesso. Coordina la riemissione delle carte con l'acquirer. Poi conferma la pulizia dopo la remediation con controlli continui di integrità degli script, non con una scansione singola, perché l'intero disegno di questa campagna presuppone che tu rimuova il payload una volta e smetta di guardare.

Cosa lascia ai difensori

La campagna è un'anteprima dell'attaccante a cui Zero Hunt è costruito per rispondere, e tocca due dei nostri tre pilastri insieme.

I dati delle carte in uscita dal livello di checkout sono la parte che l'attaccante non poteva nascondere, e intercettarli mentre accadono è il compito dell'AI Traffic Analysis di Zero Hunt: un modello di deep learning proprietario con quattro teste di inferenza — traffico sospetto, classificazione del malware, identificazione del tipo d'attacco, fingerprinting applicativo — addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'appliance a oltre 2,7 Gbit/s. La testa di fingerprinting applicativo sa che aspetto ha il traffico normale per un dato host, quindi nel momento in cui un server di checkout che serve soltanto inizia a fare beacon di piccole POST cifrate verso un ASN mai visto, quello è anomalo appena appare — non nel digest SIEM di domani, e indipendentemente dai log on-box che l'attaccante ha già cancellato.

L'altra metà è simmetrica. Questa operazione ha funzionato perché tre agenti autonomi economici potevano trovare e sfruttare una via d'ingresso più in fretta e a costo minore di quanto qualsiasi difensore potesse verificarne una a mano. Zero Hunt usa la stessa classe di motore dal lato del difensore: uno swarm di 10 agenti di generative pentest con campagne change-triggered che partono entro un'ora dalla comparsa di un nuovo asset sul perimetro, scrivendo exploit per-bersaglio con un LLM locale invece di riprodurre proof-of-concept pubblici. Risponde alla domanda che uno scanner di vulnerabilità non può — questo stack di checkout è davvero raggiungibile e sfruttabile nel modo in cui lo sfrutterebbe Cairn — e ogni finding è firmato ECDSA al momento della scrittura. Quando la perdita è dato di carta di pagamento regolamentato, quella traccia di evidenza firmata si mappa direttamente sui controlli PCI DSS, GDPR e NIS2 che la violazione mette in scope — un finding, evidenziato una volta, verificabile dopo.

L'operatore che ha condotto questa campagna ha automatizzato l'attacco. L'unica risposta duratura è automatizzare la validazione e la sorveglianza allo stesso modo — e mettere la sorveglianza dove l'attaccante non può modificare il record.