ClickFix su blockchain: oltre 5.400 siti compromessi distribuiscono codice malevolo

WordPress e PrestaShop trasformati in punti di distribuzione

Oltre 5.400 siti web compromessi stanno partecipando a un’operazione criminale che combina esche ClickFix, smart contract e comunicazioni WebRTC. L’attività, analizzata da Netskope e resa nota il 5 settembre 2026, coinvolge soprattutto portali costruiti con WordPress e PrestaShop.

Gli attaccanti inseriscono nei siti uno script capace di recuperare il payload successivo dalla BNB Smart Chain Testnet. In questo modo, pagine appartenenti principalmente a piccole imprese diventano punti di distribuzione per codice controllato da remoto.

Non è noto come sia avvenuto l’accesso iniziale ai siti. Potrebbero quindi essere coinvolti componenti vulnerabili, credenziali sottratte o altri vettori, ma non ci sono elementi sufficienti per stabilirlo. Non sono state comunicate neppure le versioni di WordPress, PrestaShop o degli eventuali plugin interessati.

L’operazione non è associata a una vulnerabilità identificata formalmente: non risultano CVE, livelli di gravità standardizzati o inserimenti nel catalogo Known Exploited Vulnerabilities della CISA. Il problema osservato riguarda siti già compromessi, non una falla specifica attribuita a un singolo prodotto.

La scala è significativa. Netskope stima che vengano impiegati più di 300 siti infetti ogni giorno. Dalla primavera è cresciuto costantemente il numero di domini che contattano gli endpoint RPC della BNB Smart Chain Testnet. In agosto la media ha sfiorato i 400 siti giornalieri, con un picco di 536.

EtherHiding sposta il payload dentro uno smart contract

Lo script iniettato nei siti non deve necessariamente contenere l’intera catena malevola. Interroga invece, attraverso gli endpoint RPC, uno smart contract collocato sulla BNB Smart Chain Testnet e ne recupera codice o dati di configurazione.

Questa tecnica viene chiamata EtherHiding. La blockchain viene usata come livello di distribuzione persistente, mentre il sito compromesso svolge il ruolo di punto d’ingresso verso la vittima.

La scelta della testnet offre diversi vantaggi operativi. La rete è destinata agli sviluppatori, riproduce il funzionamento della mainnet ed è utilizzabile gratuitamente. Il traffico RPC può inoltre confondersi con attività legittime legate ad applicazioni blockchain e strumenti di sviluppo.

Per disattivare completamente la campagna non basta quindi rimuovere un server web tradizionale. Il contenuto raggiungibile attraverso lo smart contract rimane disponibile sulla rete, rendendo più complessa un’azione di abbattimento centralizzata.

Gli attaccanti possono anche modificare il contenuto fornito dal contratto. Questa caratteristica consente loro di sostituire un’esca, uno stager o una configurazione senza reiniettare manualmente nuovo codice in tutti i 5.400 siti.

È precisamente quanto è accaduto durante l’attività analizzata: il payload ClickFix iniziale è stato rimpiazzato con uno stager basato su WebRTC Data Channel.

Il falso CAPTCHA convince la vittima a eseguire PowerShell

La prima variante osservata mostra un CAPTCHA contraffatto all’interno del sito compromesso. Non si tratta di una verifica tecnica reale, ma di un’istruzione di ingegneria sociale progettata per spingere l’utente a compromettere autonomamente il proprio computer.

La vittima viene invitata ad aprire la finestra Windows Run, incollare un comando PowerShell ed eseguirlo. Quel comando scarica e avvia il payload finale.

ClickFix aggira così uno degli ostacoli tipici delle infezioni via browser. Il sito non deve necessariamente sfruttare una vulnerabilità del sistema operativo: induce l’utente a impartire un comando che appare come una procedura necessaria per risolvere un problema o completare una verifica.

La natura esatta del payload finale non è stata resa nota. Non sono disponibili neppure hash, nomi di file o ulteriori indicatori che permettano di ricondurre la catena a una famiglia malware specifica.

Per gli utenti, il segnale più immediato è comportamentale. Un CAPTCHA legittimo non richiede di aprire Windows Run, incollare comandi o avviare PowerShell. Una pagina che propone questa procedura deve essere chiusa senza eseguire le istruzioni.

La variante WebRTC esegue JavaScript senza scriverlo su disco

Nella fase successiva gli operatori hanno sostituito nello smart contract il contenuto ClickFix con uno stager JavaScript basato su WebRTC Data Channel.

WebRTC viene normalmente impiegato dai browser per comunicazioni in tempo reale. In questo caso, lo stager crea una connessione peer e un canale dati, producendo una descrizione della sessione simile a quella usata durante un normale handshake.

Il flusso è però anomalo: lo stager costruisce autonomamente la risposta e la reinserisce nella connessione. Evita così un handshake effettivo, pur riuscendo ad aprire un canale dati verso l’infrastruttura dell’attaccante.

Il codice JavaScript viene ricevuto da un indirizzo command-and-control incorporato nello stager. I dati vengono accumulati nella memoria del browser e poi eseguiti quando il canale si chiude oppure allo scadere di 10 secondi.

L’esecuzione avviene dinamicamente mediante l’aggiunta del codice all’elemento head del DOM. Il contenuto non deve quindi essere salvato come file sul disco.

Questa modalità riduce la quantità di artefatti disponibili per i controlli concentrati sui file. Non rende tuttavia l’attività invisibile: rimangono osservabili le richieste RPC, il traffico WebRTC, il comportamento del browser e le comunicazioni verso il C2.

L’indirizzo hardcoded del server di comando e controllo non è stato reso pubblico. Non sono noti neppure gli indirizzi specifici degli endpoint RPC coinvolti, sebbene Netskope abbia indicato un insieme di endpoint da bloccare nelle proprie raccomandazioni.

I controlli da applicare su siti, rete ed endpoint

Gli amministratori di siti WordPress e PrestaShop dovrebbero esaminare pagine, template e componenti alla ricerca di script iniettati. L’analisi deve includere le richieste verso endpoint RPC della BNB Smart Chain Testnet e il confronto con il comportamento previsto del portale.

L’assenza di versioni vulnerabili note impedisce di ridurre l’intervento a una singola patch. Aggiornare CMS e componenti resta una misura utile, ma non dimostra che un sito già compromesso sia stato ripulito. Serve una verifica diretta del codice e delle chiamate di rete.

Per i difensori aziendali, Netskope raccomanda di:

• bloccare l’insieme degli endpoint RPC della BNB Smart Chain Testnet individuato dai ricercatori;
• monitorare traffico UDP non web associato a WebRTC;
• cercare richieste RPC anomale provenienti da siti WordPress e PrestaShop;
• rilevare PowerShell avviato attraverso Windows Run;
• controllare l’esecuzione dinamica di JavaScript nella memoria del browser;
• individuare connessioni verso indirizzi C2 incorporati nel codice.

Il blocco indiscriminato richiede una valutazione degli usi legittimi della testnet, soprattutto negli ambienti di sviluppo. Dove non sia possibile applicarlo, le richieste RPC dovrebbero essere registrate e correlate con dominio di origine, browser, processo e traffico WebRTC successivo.

Gli indicatori più utili sono quindi concatenati. Una visita a un sito, seguita da una chiamata RPC verso la testnet e dall’apertura di un canale WebRTC inatteso, offre un segnale più solido rispetto a ciascun evento considerato isolatamente.

Dopo l’accesso iniziale, molte azioni restano indisturbate

L’operazione mostra due livelli distinti di compromissione. Da una parte ci sono i gestori dei siti, la cui infrastruttura viene usata per raggiungere altre vittime. Dall’altra ci sono gli utenti, esposti a comandi PowerShell o a JavaScript consegnato attraverso WebRTC.

Non è stata fornita un’attribuzione nominale degli attaccanti. Rimangono inoltre sconosciuti il metodo usato per violare i siti e la destinazione finale di tutte le catene d’infezione.

Il Blue Report 2026 richiamato separatamente da Netskope aiuta a contestualizzare il problema delle fasi successive all’ingresso. Sulla base di 338 milioni di simulazioni condotte negli ambienti di produzione dei clienti, il rapporto rileva che, dopo l’impiego di credenziali valide, viene bloccato soltanto il 37% delle azioni degli attaccanti.

Quel dato non attribuisce la campagna ClickFix a uno specifico vettore e non prova che siano state usate credenziali rubate. Evidenzia però il limite di una difesa valutata soltanto sulla capacità di fermare l’accesso iniziale.

In questa operazione, il rilevamento deve seguire l’intera catena: compromissione del sito, interrogazione della blockchain, interazione con la vittima, PowerShell o WebRTC e infine comunicazione con il C2. Fermare uno solo di questi passaggi può interrompere l’attacco. Ignorarne la correlazione, invece, lascia agli operatori diversi percorsi alternativi.