Una nuova campagna di furto dati sta colpendo i negozi online sfruttando servizi affidabili come Stripe e Google Tag Manager per nascondere il proprio codice malevolo. La misura più utile da adottare subito è controllare i pagamenti con carte virtuali usa e getta, oltre a verificare che il checkout del sito non carichi script non autorizzati.
Come funziona l’attacco
Secondo l’analisi dei ricercatori, la campagna inserisce uno skimmer di carte in un container di Google Tag Manager, così il codice viene caricato come se fosse parte normale del sito. Questo approccio è particolarmente pericoloso perché i domini coinvolti, in particolare quelli legati a Google e Stripe, sono spesso considerati attendibili dai negozi online e dai sistemi di difesa. In pratica, il traffico dannoso passa sotto il radar di filtri e regole che bloccherebbero un dominio sconosciuto.
Il malware si attiva quando un utente arriva alla pagina di checkout e raccoglie le informazioni inserite nel modulo di pagamento. I dati presi di mira includono numero della carta, scadenza, CVV, nome del cliente e anche dati di fatturazione, email e numero di telefono. L’obiettivo non è solo rubare le carte, ma ottenere un profilo completo del cliente per massimizzare il valore dei dati trafugati.
Perché questa tecnica è efficace
La forza di questa campagna sta nell’uso di servizi legittimi come copertura. Gli aggressori non devono necessariamente ospitare il codice su un dominio sospetto: possono invece appoggiarsi a infrastrutture ampiamente utilizzate e quindi meno controllate. Questo rende più difficile per i sistemi di sicurezza distinguere tra traffico normale e attività malevola.
Un altro elemento rilevante è che il payload non viene sempre inviato subito all’esterno. Invece, i dati vengono prima combinati in una stringa unica, offuscati e conservati localmente. Poi una routine separata li recupera e li trasferisce verso l’account controllato dall’attaccante. Questo comportamento riduce la probabilità che il furto venga notato in tempo reale.
Stripe usato come archivio dei dati rubati
Nel caso osservato, il codice malevolo interroga Stripe per recuperare e ricostruire il payload eseguito nella pagina. I dati sottratti non vengono semplicemente inviati a un server tradizionale: vengono trasformati in un finto record cliente all’interno dell’account Stripe dell’attaccante, con campi metadata usati come contenitore per le informazioni rubate.
Questo significa che Stripe viene di fatto usato come back-end di archiviazione per i dati sottratti. Ogni carta rubata diventa un falso profilo cliente, rendendo l’operazione più discreta e più difficile da intercettare con gli strumenti classici di monitoraggio del traffico.
Dopo la copia dei dati, il file locale viene cancellato per ridurre le tracce dell’attacco e limitare le duplicazioni negli upload successivi. La routine di esfiltrazione, inoltre, non si limita a un singolo evento: viene rieseguita dopo il caricamento della pagina e poi a intervalli regolari, aumentando le possibilità di raccolta dei dati.
Il ruolo di Magento e del checkout
Lo skimmer individuato è stato progettato per colpire pagine di checkout basate su Magento/Adobe Commerce, una piattaforma molto diffusa nell’e-commerce. Questo dettaglio è importante perché il checkout è il punto in cui i dati più preziosi vengono inseriti: proprio lì il criminale informatico può intercettare il momento in cui il cliente compila il pagamento.
L’attacco sfrutta anche la fiducia che i negozi online ripongono nelle integrazioni esterne. Se un sito consente già GTM e Stripe, un payload malevolo inserito nel posto giusto può passare inosservato, soprattutto se la configurazione di sicurezza non è abbastanza restrittiva.
Una variante usa Google Firestore
I ricercatori hanno individuato anche una variante della stessa campagna che non si affida a Stripe, ma a Google Firestore, il servizio database cloud di Google. In questo caso il payload viene caricato da un documento Firestore chiamato tracking/captcha all’interno di un progetto denominato braintree-payment-app.
Anche qui la scelta dei nomi non è casuale: documenti e progetti sembrano legati a funzioni lecite di pagamento o protezione dai bot, così il malware si mimetizza meglio nel traffico legittimo. Nella variante con Firestore, i dati rubati vengono salvati in una chiave di localStorage diversa, chiamata d_data_customer.
Cosa possono fare i clienti
Per gli utenti finali, la difesa più pratica è usare carte virtuali con limite di spesa o carte monouso quando il servizio della banca lo consente. In questo modo, anche se i dati venissero intercettati, l’impatto economico sarebbe più contenuto.
È utile anche controllare con attenzione l’estratto conto e attivare le notifiche in tempo reale per ogni transazione. Se compaiono addebiti non riconosciuti, è importante bloccare subito la carta e contattare l’emittente.
Cosa dovrebbero fare i gestori degli e-commerce
Per i proprietari di negozi online, il punto centrale è ridurre la fiducia implicita verso script esterni. Non basta autorizzare un dominio perché è popolare o usato per i pagamenti: bisogna verificare con continuità quali container GTM sono attivi, quali script vengono caricati e quali risorse comunicano con il browser dell’utente.
È anche utile limitare l’uso di script di terze parti sul checkout, applicare controlli rigorosi sui tag inseriti in Google Tag Manager e rivedere le regole di Content Security Policy in modo che non diventino troppo permissive. Inoltre, il monitoraggio delle modifiche al front-end e l’audit periodico dei container aiutano a individuare alterazioni sospette prima che diventino un problema concreto.
Perché questo attacco è importante
Questa campagna mostra un’evoluzione chiara degli attacchi Magecart: invece di puntare solo su server malevoli isolati, gli aggressori sfruttano infrastrutture fidate e servizi cloud ampiamente diffusi. Il risultato è un attacco più difficile da rilevare e più semplice da far sembrare normale.
Il caso dimostra anche che la sicurezza del checkout non dipende soltanto dal gateway di pagamento, ma dall’intera catena di script, tag e integrazioni che si caricano nella pagina. Quando uno di questi elementi viene compromesso, anche un ambiente apparentemente affidabile può diventare un canale per il furto dei dati.
Technical Deep Dive
L’operazione osservata si basa su una sequenza tecnica piuttosto raffinata. Il codice dannoso viene distribuito tramite un container Google Tag Manager che, una volta caricato in pagina, aggancia il flusso del checkout e recupera il payload da un’infrastruttura considerata lecita dal punto di vista del browser e di molte policy di sicurezza. In questo modo, il caricamento del malware avviene nel contesto di un dominio fidato, riducendo la probabilità di blocco da parte di regole di rete o di Content Security Policy troppo permissive.
Nel caso che sfrutta Stripe, il payload interroga l’API per un record cliente specifico e legge il codice JavaScript memorizzato nei campi metadata. Il codice viene poi ricomposto dinamicamente ed eseguito con new Function(), un approccio che consente di mantenere il primo stadio del malware relativamente piccolo e di spostare la logica più complessa in un contenitore esterno. Questo schema a più fasi è utile per l’offuscamento e per la sostituzione rapida del payload senza dover aggiornare il codice iniziale distribuito nel sito compromesso.
Lo skimmer prende di mira i campi del form di checkout su Magento/Adobe Commerce, intercettando numero della carta, data di scadenza, CVV, nome, indirizzo di fatturazione, email e telefono. I dati vengono aggregati in una singola stringa, trasformati con XOR e memorizzati in locale invece di essere inviati subito a un endpoint sospetto. La scelta di mantenere il contenuto in storage locale riduce il numero di richieste anomale osservabili durante la compilazione del modulo.
La fase di esfiltrazione viene eseguita separatamente dopo il caricamento della pagina e poi a intervalli regolari, tipicamente ogni minuto. Il routine divide il blob in due parti, crea un nuovo oggetto cliente su Stripe e usa i campi metadata per inserire le informazioni rubate. In pratica, l’account dell’attaccante diventa un archivio strutturato, in cui ogni carta sottratta corrisponde a un record cliente falso. Dopo la sincronizzazione, il file locale viene cancellato per limitare le tracce e prevenire caricamenti duplicati.
La variante che usa Firestore segue una logica simile ma sposta l’attenzione su Google Cloud. Il payload viene letto da un documento chiamato tracking/captcha in un progetto dal nome braintree-payment-app, mentre i dati raccolti vengono salvati in una chiave localStorage separata, d_data_customer. L’uso di nomi che richiamano pagamenti e protezione anti-bot serve a mimetizzare l’attività all’interno di flussi legittimi già presenti nel browser.
Dal punto di vista difensivo, l’elemento più importante è osservare gli script caricati nel checkout e i cambiamenti nei container GTM, perché la compromissione non richiede necessariamente l’alterazione del backend del negozio. Anche la sorveglianza delle chiamate verso servizi cloud normalmente attendibili diventa cruciale, soprattutto quando tali servizi vengono usati per recuperare codice dinamico o per memorizzare metadati che non dovrebbero contenere JavaScript eseguibile. Un approccio efficace combina restrizioni strette sui tag, revisione manuale dei container, controllo delle dipendenze esterne e monitoraggio continuo delle anomalie di comportamento nel browser.
