EtherHiding evolve con WebRTC: oltre 5.400 siti trasformano la blockchain in C2

🛡️ Executive Summary

• Netskope rileva oltre 5.400 siti compromessi che interrogano smart contract BSC Testnet per recuperare dinamicamente codice malevolo attraverso EtherHiding.
• Una nuova variante sostituisce ClickFix con uno stager WebRTC capace di aprire direttamente un canale C2 UDP cifrato senza signaling tradizionale.
• La difesa richiede controllo dell’integrità dei CMS, monitoraggio degli endpoint RPC blockchain e visibilità sul traffico WebRTC non intercettato dai proxy HTTP.

La tecnica EtherHiding continua a evolvere e supera ormai la semplice distribuzione di payload attraverso smart contract. Netskope Threat Labs ha individuato una campagna che coinvolge oltre 5.400 siti compromessi appartenenti a più di 2.200 organizzazioni, utilizzati per interrogare la BNB Smart Chain Testnet e recuperare dinamicamente codice JavaScript malevolo. La maggior parte delle catene osservate conduce ancora a esche ClickFix, ma una nuova variante introduce uno stager capace di aprire un canale WebRTC cifrato verso il C2, eliminando parte del signaling normalmente osservabile dai sistemi difensivi. È un’evoluzione diretta del modello già visto quando ClearFake aveva trasformato gli smart contract BSC Testnet in un’infrastruttura resistente al takedown: la blockchain non ospita più soltanto istruzioni e payload, ma diventa il primo livello di una catena progettata per spostare anche il comando e controllo fuori dai percorsi di rete più facilmente ispezionabili.

Oltre 5.400 siti interrogano la BSC Testnet per recuperare il payload

La ricerca pubblicata da Netskope Threat Labs parte da migliaia di richieste anomale osservate verso endpoint JSON-RPC della BSC Testnet. I siti coinvolti appartengono soprattutto a piccole attività — cliniche, idraulici, negozi online e altre realtà senza relazioni evidenti tra loro — e utilizzano frequentemente WordPress, con una presenza minore di installazioni PrestaShop. Netskope non attribuisce al momento una tecnica precisa alla compromissione iniziale dei CMS, quindi non è possibile stabilire dalla ricerca se gli aggressori sfruttino vulnerabilità, credenziali sottratte, plugin alterati o altri vettori. Il dato confermato riguarda invece ciò che accade dopo l’accesso: un piccolo script viene aggiunto a file JavaScript legittimi oppure collocato all’interno di directory che imitano pacchetti o plugin reali. Il loader esegue una chiamata eth_call verso uno smart contract e riceve da questo il secondo stadio della catena. Nel periodo analizzato, i ricercatori hanno contato oltre 5.400 siti distinti, con più di 300 domini attivi nei giorni feriali e una crescita costante dalla primavera. L’ampiezza della campagna conferma che EtherHiding non rappresenta più una tecnica sperimentale isolata, ma una vera infrastruttura operativa utilizzabile su larga scala.

La BSC Testnet offre hosting gratuito e resilienza contro i takedown

La scelta della testnet è funzionale al modello economico e operativo dell’attacco. Una blockchain di produzione richiede il pagamento delle transazioni e degli aggiornamenti degli smart contract; nella rete di test, invece, i token vengono distribuiti gratuitamente attraverso faucet destinati agli sviluppatori. Gli attaccanti ottengono così un’infrastruttura programmabile e persistentemente raggiungibile senza sostenere i costi della mainnet. Il vantaggio principale non è però soltanto economico. Aggiornando un singolo contratto, gli operatori possono modificare ciò che migliaia di siti compromessi consegneranno ai visitatori alla successiva apertura della pagina. Il sito violato non contiene necessariamente il payload finale e il codice malevolo può cambiare senza che sia necessario toccare nuovamente il server web. È la stessa logica di dead drop resolver che sta emergendo in molte campagne moderne: GoCaracal utilizza Ethereum per recuperare un nuovo C2 quando l’infrastruttura primaria non risponde, mentre altri malware hanno utilizzato transazioni, servizi pubblici o dati apparentemente innocui come livello intermedio. La blockchain diventa così un punto di distribuzione resiliente perché il difensore non può neutralizzarla con il semplice sequestro di un dominio o la rimozione di un server.

Leggi anche: Node.js diventa un vettore malware tra ClickFix, EtherHiding e backdoor evasive

ClickFix resta il percorso principale ma il payload può cambiare in qualsiasi momento

Nella catena più comune osservata da Netskope, il codice recuperato dalla blockchain genera una pagina ClickFix sovrapposta al sito compromesso. Lo sfondo viene oscurato e l’utente visualizza un falso CAPTCHA che lo induce ad aprire la finestra Esegui di Windows e incollare un comando precedentemente copiato negli appunti. Il comando avvia quindi il downloader incaricato di recuperare il payload finale. L’aspetto più rilevante è che il payload non è fisso: lo smart contract controllato dall’attaccante può essere aggiornato per indirizzare visitatori differenti verso stadi diversi, rendendo la stessa rete di siti compromessi una piattaforma distribuibile e modificabile centralmente.

Questo schema coincide con quanto osservato nelle recenti campagne ClearFake con WordlistLoader e Amatera, nelle quali il compromesso iniziale del sito e l’infrastruttura di distribuzione vengono separati proprio per ridurre l’efficacia del blocco di singoli indicatori. La nuova ricerca mostra però un passaggio ulteriore: in alcuni campioni il secondo stadio on-chain non porta a ClickFix, ma costruisce direttamente una comunicazione C2 all’interno del browser.

Il nuovo stager WebRTC elimina il signaling tradizionale

La variante più interessante utilizza WebRTC DataChannel, tecnologia normalmente impiegata per scambiare audio, video e dati tra peer attraverso il browser. In una sessione legittima, i due endpoint devono negoziare la connessione attraverso un meccanismo di signaling: vengono scambiate descrizioni di sessione, informazioni ICE, credenziali e fingerprint dei certificati, mentre la rete può mostrare richieste DNS, traffico STUN/TURN e handshake DTLS. Lo stager analizzato da Netskope altera completamente questo processo.

Il JavaScript crea una peer connection e genera regolarmente l’offerta iniziale, ma non la invia a un server di signaling. Costruisce invece autonomamente la risposta che dovrebbe arrivare dal peer remoto e la consegna al browser come se fosse stata realmente negoziata. IP del C2, porta UDP, password ICE e fingerprint DTLS sono già incorporati nel codice. L’indirizzo IP viene inoltre ricostruito partendo da valori numerici separati, evitando che compaia direttamente come stringa. Il risultato è un canale cifrato che può essere aperto già dal primo pacchetto senza la normale fase di scambio. La tecnica converge con altre operazioni nelle quali WebRTC viene utilizzato per nascondere comunicazioni operative dentro protocolli ammessi, come TwinLoot e altri framework che sfruttano browser headless, TURN e infrastrutture Microsoft 365.

Il codice arriva via UDP e viene eseguito direttamente nel DOM

Dopo l’apertura del DataChannel, il C2 trasmette il codice direttamente attraverso WebRTC. Lo stager accumula i messaggi ricevuti e, alla chiusura del canale o allo scadere di un timeout di dieci secondi, ricompone il contenuto e lo esegue nella pagina. Non è necessario salvare un file sul disco e non compare una richiesta HTTP contenente una stringa eval facilmente riconoscibile. Il JavaScript viene invece aggiunto dinamicamente alla sezione head del documento. La variante analizzata introduce anche un meccanismo per aggirare la Content Security Policy: se la pagina utilizza un nonce su uno script legittimo, il malware lo copia e lo applica al proprio elemento <script>, inducendo il browser a considerarlo autorizzato. Se il nonce non è disponibile, utilizza una funzione alternativa per eseguire il codice. Dopo l’esecuzione, il nodo viene immediatamente rimosso e il DataChannel viene terminato. La combinazione tra esecuzione in memoria, abuso della CSP e trasporto WebRTC riduce gli artefatti disponibili sia sull’endpoint sia sul proxy. Non è un principio isolato: PINHOLE ed E4del hanno già mostrato come servizi e protocolli legittimi possano essere trasformati in resolver e canali C2 difficili da bloccare.

La difesa non può fermarsi agli indicatori HTTP

L’architettura descritta da Netskope unisce due problemi differenti. Il primo è EtherHiding, che sposta la distribuzione del codice su una rete blockchain pubblica e rende poco efficace il takedown di singoli domini. Il secondo è WebRTC, che consente al browser di comunicare con un endpoint remoto attraverso traffico UDP cifrato che può non transitare nei normali sistemi di ispezione HTTP. Bloccare soltanto l’endpoint RPC principale non è sufficiente perché il malware può utilizzare un intero pool di nodi BSC Testnet; allo stesso modo, filtrare URL e richieste web non intercetta necessariamente il successivo DataChannel. I proprietari dei siti devono invece verificare l’integrità dei file del CMS, cercare JavaScript aggiunto a risorse legittime, directory di plugin non riconosciute e modifiche inattese ai template. Sul lato aziendale diventano rilevanti le richieste JSON-RPC verso infrastrutture blockchain, soprattutto da dispositivi e browser che non hanno una ragione operativa per utilizzarle, insieme al monitoraggio del traffico WebRTC e delle connessioni UDP verso indirizzi non abituali. È lo stesso spostamento verso una detection comportamentale già richiesto dall’uso di smart contract, servizi pubblici e infrastrutture decentralizzate come C2.

Continua con:

• ClearFake usa smart contract BSC Testnet per nascondere il comando e controllo
• GoCaracal porta Ethereum dentro l’infrastruttura C2 di Dark Caracal

Blockchain e WebRTC diventano due livelli della stessa infrastruttura evasiva

La novità della campagna non è soltanto l’uso contemporaneo di blockchain e WebRTC, ma la divisione precisa dei rispettivi ruoli. La BSC Testnet fornisce un livello persistente attraverso il quale aggiornare da remoto il comportamento di migliaia di siti compromessi; WebRTC offre invece un trasporto cifrato capace di aggirare parte della telemetria prodotta dal signaling convenzionale e dei controlli concentrati sul traffico HTTP. Il browser si trova quindi al centro della catena: recupera codice da uno smart contract, costruisce autonomamente una sessione apparentemente valida, raggiunge il C2 attraverso UDP e infine esegue il payload senza scriverlo necessariamente sul disco. Per i difensori questo significa che blockchain RPC, integrità dei CMS, JavaScript dinamico e telemetria WebRTC devono essere analizzati come componenti dello stesso incidente, non come superfici separate. Con oltre 5.400 siti già osservati, EtherHiding mostra ormai una scala incompatibile con l’idea di tecnica marginale: l’infrastruttura decentralizzata sta diventando uno strumento operativo stabile e gli attaccanti stanno iniziando a costruirvi sopra nuovi livelli di evasione.