La campagna mette in catena tre fasi consecutive, ognuna delle quali sfrutta un servizio legittimo per eludere il rilevamento .
Gli aggressori compromettono per prima cosa un contenitore (container) di Google Tag Manager (GTM) presente sul negozio online preso di mira. Al suo interno inseriscono un tag malevolo che si carica su ogni pagina. Poiché lo script proviene da googletagmanager.com, un dominio di analytics universalmente fidato, esso aggira le tipiche Content Security Policy (CSP) e gli ad-blocker senza destare alcun sospetto . GTM diventa così un meccanismo di consegna impossibile da bloccare.
Invece di contattare un losco server di terze parti, il tag GTM richiede il codice dello skimmer a api.stripe.com. Gli aggressori memorizzano l'intero skimmer JavaScript all'interno di un campo metadati del Cliente (Customer metadata) del proprio account Stripe. Per farlo, usano una chiave segreta di modalità test (sk_test_...), che permette loro di scrivere e leggere i dati . Lo skimmer arriva così da un dominio che i gestori dei negozi considerano implicitamente parte della loro infrastruttura di pagamento; di conseguenza, il monitoraggio di rete e le regole CSP raramente segnalano la chiamata API.
Quando un acquirente inserisce i dettagli della carta di credito, le informazioni personali e l'indirizzo di fatturazione alla cassa, lo skimmer iniettato cattura i dati e li rispedisce all'account Stripe degli aggressori. Le informazioni vengono scritte come finti record di Clienti o nuovi metadati, utilizzando la stessa API di Stripe . Poiché il traffico di esfiltrazione è diretto proprio a
api.stripe.com, si confonde perfettamente con le legittime chiamate API per i pagamenti. Questo rende il furto praticamente invisibile ai log del firewall e agli strumenti di rilevamento delle anomalie .
L'intera operazione, secondo gli indicatori osservati dai ricercatori, è attiva almeno dal 24 dicembre 2025 .
Le chiavi segrete di test di Stripe (sk_test_...) concedono pieno accesso in lettura e scrittura all'interno dell'ambiente sandbox e permettono la creazione illimitata e gratuita di clienti e campi metadati fittizi . Poiché queste chiavi non attivano mai addebiti reali, è facile trascurarne un utilizzo improprio. Gli aggressori fanno leva sul fatto che molte organizzazioni trattano le chiavi di test come elementi a basso rischio e non sottopongono l'attività del sandbox allo stesso rigore con cui controllano il traffico di produzione.
Una minaccia correlata, ma distinta, è l'esposizione di chiavi segrete reali (sk_live_...). Se compromesse, darebbero a un aggressore accesso diretto ai dati transazionali reali e la capacità di emettere rimborsi o trasferire fondi . Sebbene questa campagna usi chiavi di test per muoversi in modo furtivo, il principio di fondo è lo stesso: le chiavi API di Stripe, in qualsiasi modalità, sono credenziali potenti che non dovrebbero mai apparire nel codice lato client o nei contenitori di Google Tag Manager
.
Mentre la campagna Stripe prende di mira i flussi di checkout dell'e-commerce, i proprietari di siti WordPress devono affrontare una minaccia altrettanto urgente. Una vulnerabilità in un plugin è sotto sfruttamento attivo dal 13 aprile 2026 .
CVE-2026-3300 è una falla di esecuzione di codice remoto (RCE) senza autenticazione presente nel plugin Everest Forms Pro, che conta circa 4.000 installazioni attive . La vulnerabilità ha un punteggio di 9.8 sulla scala CVSS e interessa tutte le versioni fino alla 1.9.12 inclusa
.
Il bug risiede nella funzione process_filter() all'interno del componente aggiuntivo Calculation. Quando la funzione "Calcolo Complesso" è abilitata, il plugin prende i valori forniti dall'utente nei campi del modulo di tipo stringa, li concatena direttamente in una stringa di codice PHP e passa il risultato alla funzione eval(), senza un adeguato escaping . La funzione
sanitize_text_field() applicata all'input non neutralizza gli apici singoli o altri caratteri con significato speciale in un contesto di codice PHP, consentendo a un aggressore di uscire dalla stringa prevista e iniettare comandi arbitrari .
Wordfence ha bloccato oltre 29.300 tentativi di sfruttamento e riferisce che gli aggressori stanno creando account amministratore non autorizzati come parte del processo post-sfruttamento . I proprietari dei siti dovrebbero cercare indicatori di compromissione come nuovi utenti amministratori con nomi insoliti (es. "diksimarina"), file inaspettati sul server o connessioni in uscita sospette
.
api.stripe.com come script-src a meno che non sia strettamente necessario. Se dovete includerlo, applicate hash di Sub-Resource Integrity (SRI). Bloccare gli script inline fornisce un ulteriore livello di difesa eval() eval(), e connessioni di rete in uscita verso IP non noti. È essenziale un controllo di integrità completo di WordPress su core, temi e checksum dei file dei plugin dopo la correzione
Comments
0 comments