Come un singolo script di tracciamento ha reindirizzato i pagamenti in criptovaluta sul web

La tecnologia pubblicitaria è la materia oscura dell'internet moderno. È invisibile all'utente medio, eppure esercita un'influenza massiccia sul modo in cui i dati fluiscono nel web. Quando questo strato invisibile fallisce, l'impatto si estende istantaneamente su migliaia di siti web non correlati. Il 27 luglio 2026, Adform ha scoperto che uno dei suoi script di tracciamento principali era stato rivolto contro i suoi utenti. Una compromissione della supply-chain ha permesso agli aggressori di iniettare codice malevolo in un file JavaScript ampiamente utilizzato, trasformandolo in uno strumento che riscrive gli indirizzi dei portafogli di criptovaluta in tempo reale.

Ho trascorso la mattinata analizzando i campioni catturati dello script malevolo. La compromissione prende di mira trackpoint-async.js, un file servito dall'infrastruttura di Adform. Poiché questo script è integrato negli header di circa 1.800 siti di clienti per facilitare l'analisi pubblicitaria, gli aggressori non hanno avuto bisogno di violare le singole aziende. Hanno semplicemente avvelenato il pozzo. Una volta caricato lo script alterato nel browser di un visitatore, questo ha iniziato a monitorare il Document Object Model alla ricerca di pattern specifici simili a indirizzi Bitcoin, Ethereum o Tron.

Il rischio invisibile delle dipendenze di terze parti

La moderna architettura web si basa sulla fiducia implicita nelle risorse di terze parti. Quando uno sviluppatore aggiunge una riga di codice per richiamare uno script da un fornitore globale, concede a quel fornitore un controllo significativo sull'esperienza dell'utente. Questo incidente è un esempio da manuale di un attacco alla supply-chain in cui viene sfruttato il rapporto di fiducia. Lo script in questione, trackpoint-async.js, è progettato per essere eseguito su interi siti web o sezioni specifiche. In questo caso, gli aggressori hanno aggiunto due blocchi di codice malevolo alla fine della libreria legittima.

Dal punto di vista del rischio, questo è uno scenario da incubo per qualsiasi amministratore di sito. Si può avere una postura di sicurezza perfetta, un server blindato e un rigoroso processo di revisione interna del codice, eppure un singolo script esterno può comunque compromettere i propri utenti. Gli aggressori hanno aggirato il perimetro della rete passando attraverso una porta secondaria che viene quasi sempre lasciata aperta per gli strumenti di marketing e analisi. Ciò dimostra perché il concetto di perimetro di rete è un fossato di castello ormai obsoleto. Se permetti a script esterni di essere eseguiti con privilegi elevati sul tuo sito, hai effettivamente invitato un estraneo a gestire la tua sicurezza.

Anatomia della compromissione di trackpoint

L'analisi tecnica dei blocchi malevoli rivela uno sforzo mirato a dirottare le transazioni finanziarie. Il codice utilizza una chiave XOR a sei byte per offuscare gli indirizzi dei portafogli sostitutivi, una tattica comune per eludere il rilevamento basato su firme elementari. Una volta eseguito lo script, questo avvia due distinti percorsi di attacco. Il primo blocco si concentra sugli appunti di sistema (clipboard). Monitora l'evento di copia e tenta di leggere gli appunti ogni quattro secondi. Se identifica una stringa che corrisponde a un pattern di portafoglio di criptovaluta, sostituisce quella stringa con un indirizzo di portafoglio di proprietà dell'aggressore.

Dietro le quinte, il secondo blocco di codice è ancora più invasivo. Percorre i nodi di testo del documento e monitora ogni campo di input, textarea ed elemento contenteditable. Quando un utente digita o incolla un indirizzo in un campo di un modulo, lo script intercetta l'evento e riscrive il valore. Si spinge persino a ripristinare la posizione del cursore dopo la riscrittura per garantire che l'utente non noti lo spostamento. Questo livello di manipolazione granulare assicura che, anche se un utente bypassa gli appunti digitando manualmente un indirizzo, la transazione rimanga vulnerabile al reindirizzamento.

Gli appunti sono un ambiente conteso

Il ricercatore indipendente Kevin Beaumont ha notato un tratto particolarmente aggressivo di questo malware. Anche se un utente si accorge che l'indirizzo è errato e tenta di copiare nuovamente l'indirizzo originale del portafoglio, lo script continua a sostituirlo. Questa persistenza rende l'ambiente del browser stesso inaffidabile. In caso di una violazione come questa, il browser diventa un agente malevolo che agisce contro gli interessi dell'utente.

Dal punto di vista dell'utente finale, l'attacco è quasi interamente silenzioso. Non ci sono pop-up, rallentamenti o segni evidenti di infezione del sistema. Il malware non tenta di installare software o di stabilire una persistenza sul disco rigido. Esiste solo nella memoria volatile della scheda del browser. Una volta che l'utente chiude la pagina interessata, il processo malevolo termina. Tuttavia, il danno avviene nei secondi necessari per cliccare sul pulsante di invio. Un solo indirizzo alterato al momento del pagamento è sufficiente per reindirizzare migliaia di dollari in un modo che è funzionalmente irreversibile su una blockchain decentralizzata.

Riconciliare il conflitto della cronologia

Esiste una discrepanza tra il rapporto ufficiale dell'incidente e le osservazioni indipendenti. Adform identifica il 27 luglio come data dell'incidente e dichiara di aver rimosso il codice tempestivamente. Kevin Beaumont ha riferito di aver visto attività malevole tramite Adform per almeno una settimana prima di quella data. Questo divario temporale è un problema significativo per la valutazione del rischio. Se lo script è stato attivo per sette giorni invece di uno, il numero di visitatori esposti aumenta di ordini di grandezza. Adform serve circa 1,5 miliardi di annunci al giorno in 180 paesi. Anche se solo una piccola frazione di quegli annunci trasportasse il payload malevolo, il bacino di potenziali vittime sarebbe enorme.

Come contromisura, Adform ha consigliato a tutti gli utenti di svuotare la cache del browser. Questo è un passaggio fondamentale perché la versione malevola di trackpoint-async.js potrebbe rimanere memorizzata localmente sul computer di un utente anche dopo la correzione lato server. Se il browser carica la versione memorizzata nella cache dello script, l'attacco rimane attivo. Ciò evidenzia un difetto persistente nella sicurezza web, dove la longevità di una cache può estendere la vita di una minaccia alla sicurezza molto tempo dopo la distribuzione di una patch.

Valutare le capacità di esfiltrazione

Uno degli aspetti più preoccupanti del codice è la sua comunicazione con un server esterno. Lo script tenta di inviare una richiesta HTTP a un indirizzo IP (84.32.102[.]230) al caricamento della pagina. Questa richiesta include l'hostname e il percorso specifico della pagina che il visitatore sta visualizzando in quel momento. Adform ha dichiarato di non aver trovato prove che gli indirizzi IP dei visitatori o la cronologia di navigazione abbiano raggiunto gli aggressori. Tuttavia, l'avviso di incidente ammette che tale trasmissione era tecnicamente possibile in base alla costruzione del codice.

Nella mia esperienza di analisi di APT e violazioni della supply-chain, gli aggressori raramente includono capacità di esfiltrazione di dati senza l'intento di utilizzarle. I dati dell'hostname e del percorso forniscono agli operatori una mappa in tempo reale di quali siti stiano servendo con successo il loro malware. Questo li aiuta a dare priorità ai loro obiettivi e a misurare l'efficacia della loro compromissione. Parlando in modo proattivo, dobbiamo presumere che qualsiasi dato a cui lo script potesse accedere sia stato potenzialmente registrato dal server di comando e controllo dell'aggressore.

Misure difensive per il web moderno

Questo incidente serve come brusco promemoria del fatto che gli script di terze parti sono un importante vettore di rischio sistemico. Per difendersi da ciò, le organizzazioni devono muoversi verso un modello di sicurezza granulare. L'uso degli hash di Subresource Integrity (SRI) è una difesa primaria. L'SRI consente a un browser di verificare che uno script recuperato non sia stato manipolato. Se l'hash del file sul server non corrisponde all'hash definito nel codice del sito web, il browser rifiuta di eseguirlo. Se i clienti di Adform avessero implementato l'SRI per trackpoint-async.js, la versione malevola sarebbe stata bloccata automaticamente.

Un'altra difesa critica è la Content Security Policy (CSP). Una CSP ben configurata può limitare i domini da cui gli script possono essere caricati e impedire loro di inviare dati a indirizzi IP esterni non autorizzati. Se fosse stata in vigore una CSP che bloccava esplicitamente le connessioni all'indirizzo IP dell'aggressore, il tentativo di esfiltrazione dei dati sarebbe fallito. La sicurezza non è un singolo strumento ma una serie di strati sovrapposti. Quando uno strato è compromesso, gli altri devono essere pronti a intercettare il fallimento.

In definitiva, la responsabilità di verificare una transazione rimane dell'utente. La difesa più efficace in questo caso specifico è la più semplice: verificare sempre l'indirizzo di destinazione attraverso un secondo canale o ricontrollando ogni carattere prima di premere invio. In un mondo in cui il codice stesso che usi per navigare nel web può rivoltarsi contro di te, una sana paranoia è un requisito funzionale per la vita digitale.

Punti chiave per i leader IT

• Controllare tutti gli script di terze parti attualmente in esecuzione negli ambienti di produzione e rimuovere quelli che non sono mission-critical.
• Implementare gli hash di Subresource Integrity per tutte le dipendenze JavaScript esterne per impedire l'esecuzione di codice non autorizzato.
• Rafforzare le Content Security Policy per limitare l'esecuzione degli script e l'esfiltrazione dei dati a domini noti e affidabili.
• Adottare un approccio zero-trust per le risorse lato client, assumendo che qualsiasi dipendenza esterna possa essere compromessa alla fonte.

Fonti

• Adform Incident Notice (Luglio 2026)
• MITRE ATT&CK Framework: Supply Chain Compromise (T1195)
• NIST Special Publication 800-161: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations

Dichiarazione di non responsabilità: questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit professionale di sicurezza informatica o un servizio di risposta agli incidenti.