EtherRAT: analisi rischio C2 tramite Smart Contract Ethereum

EtherRAT sfrutta gli Smart Contract Ethereum per infrastrutture C2 immuni ai takedown tradizionali. Scopri l'impatto su sysadmin e DevOps: ecco cosa sapere.

Contenuto

EtherRAT: analisi rischio C2 tramite Smart Contract Ethereum
EtherRAT: analisi rischio C2 tramite Smart Contract Ethereum

A marzo 2026, l'Atos Threat Research Center (TRC) ha identificato una campagna malevola sofisticata e ad alta resilienza mirata ad amministratori aziendali, ingegneri DevOps e analisti di sicurezza. La campagna unisce tattiche di attacco Web2, come il SEO poisoning e l'uso di tool amministrativi trojanizzati su GitHub, a infrastrutture di comando e controllo Web3 basate su Smart Contract Ethereum. Questa convergenza rende le infrastrutture malevole immuni ai tradizionali takedown, colpendo proprio i professionisti incaricati di difenderle.

Infrastrutture C2 su Ethereum: il Blockchain-based Dead Drop Resolving

Negli ultimi 2 anni, il divario tra malware tradizionale e attacchi incentrati su crypto si è chiuso significativamente. A dimostrare questa pericolosa convergenza è l'architettura della nuova variante di EtherRAT, che implementa un approccio definito Blockchain-based Dead Drop Resolving (DDR). Come evidenziato a marzo 2026 dall'Atos TRC, il malware interroga ripetitivamente un endpoint pubblico Ethereum (ETH) RPC, utilizzando un indirizzo Smart Contract specifico hardcoded per recuperare dinamicamente l'indirizzo del server C2 live.

Questa metodologia sfrutta l'immutabilità e la decentralizzazione della blockchain per garantire la sopravvivenza dell'infrastruttura di comando e controllo. L'Atos TRC descrive questo meccanismo spiegando come il malware ritrova il proprio "home" attraverso i gateway Ethereum. Questo rende i tentativi di sequestro o blocco del dominio C2 inefficaci: fintanto che lo Smart Contract esiste sulla rete Ethereum, l'indirizzo di controllo può essere aggiornato dai threat actor in qualsiasi momento, senza che i defender possano intervenire alla radice per oscurare l'infrastruttura di riferimento.

Tattiche Web2: SEO poisoning e architettura dual-stage su GitHub

Per la distribuzione iniziale del malware, i gruppi minacciosi non hanno abbandonato le classiche e collaudate tecniche di inganno tipiche del Web2. A marzo 2026, la campagna ha utilizzato il SEO poisoning su motori di ricerca come Bing, Yahoo, DuckDuckGo e Yandex. L'obiettivo era dirigere gli utenti verso un repository GitHub "facciata" primario, completamente privo di codice malevolo, superando così i primi controlli di sicurezza automatizzati e le analisi dei repository.

L'architettura su GitHub è strutturata in modo ingegnoso per garantire resilienza anche in fase di distribuzione: il repository facciata contiene un link a un secondo repository GitHub nascosto, che funge da vero punto di distribuzione del malware. Secondo l'Atos TRC, questa struttura dual-stage consente ai threat actor di ruotare rapidamente i repository secondari se segnalati, mantenendo intatta e pulita la porta di ingresso pubblica primaria.

Strumenti amministrativi trojanizzati: l'evoluzione di EtherRAT su Windows

L'esca perfetta per gli amministratori di sistema sono gli strumenti che utilizzano quotidianamente per il loro lavoro. A marzo 2026, la campagna distribuiva installatori MSI malevoli camuffati da tool amministrativi legittimi come PsExec, AzCopy, Sysmon, LAPS e Kusto Explorer. L'Atos TRC sottolinea la gravità della cosa, spiegando che il successo di un'infezione sulla workstation di un amministratore consegna agli attaccanti le "keys to the kingdom", garantendo privilegi elevati e accesso trasversale alle risorse critiche dell'infrastruttura.

Nel 2026, gli analisti LevelBlue SpiderLabs hanno identificato che EtherRAT, originariamente documentato come implant basato su JavaScript/Node.js che prendeva di mira server Linux, è evoluto in una minaccia focalizzata su Windows, consegnata proprio tramite questi installatori MSI. Questo cambiamento di target riflette un adattamento strategico: colpire l'ecosistema aziendale dominante per massimizzare il raggio d'azione dell'attacco.

Un ulteriore vettore di infezione evidenziato nel 2026 dagli analisti LevelBlue SpiderLabs è l'incorporazione di una nuova variante di EtherRAT in una copia trojanizzata di Tftpd64, etichettata specificamente come "Tftpd64 v4.74". Questa copia era ospitata su un repository GitHub falso che impersonava il progetto ufficiale. L'archivio trojanizzato includeva file anomali con estensioni .dat, .cmd, .ini e .tmp, strategicamente posizionati in percorsi accessibili dall'utente nella cartella dei dati applicazione locali per facilitare l'esecuzione e la persistenza del codice malevolo.

CyberSecurityNews e LevelBlue SpiderLabs hanno definito questo approccio un "blended attack model", un modello d'attacco ibrido che unisce diverse finalità dannose: la capacità di rubare credenziali, mantenere un accesso remoto persistente sui sistemi compromessi e, sfruttando la natura Web3 dell'infrastruttura, svuotare contemporaneamente i wallet digitali delle vittime.

Indicatori di compromissione e limiti degli Smart Contract

Di fronte a minacce così strutturate e capaci di ruotare rapidamente le proprie infrastrutture, gli Indicatori di compromissione (IoC) assumono un ruolo centrale per i team di sicurezza. Un IoC non è più esclusivamente un semplice match su una lista di firme, ma deve essere considerato un oggetto con significato operativo. Un data feed efficace è un processo continuo, che deve rispondere subito a domande precise sul contesto dell'attacco. Quando questo processo è progettato per essere vicino al contesto reale delle aziende che protegge, l'effetto difensivo non è teorico, ma immediatamente operativo.

Esempi di questi IoC includono indirizzi IP associati ad attività dannose e domini di comando e controllo (C2) utilizzati dagli hacker per gestire i malware. La verifica degli IoC tramite hash e le group policy rimane una pratica essenziale: è fondamentale monitorare gli indirizzi IP noti per essere associati a server di comando e controllo o a infrastrutture di attacco, così come i domini noti per essere associati a campagne malevole e i protocolli di rete anomali.

Dal punto di vista difensivo specifico sulla componente Web3, l'uso di Smart Contract Ethereum pone sfide inedite. L'assessment di sicurezza serve a capire se lo smart contract che è stato scritto contenga delle vulnerabilità note. Tuttavia, i tool di analisi hanno un limite intrinseco: essi consentono di fornire un'assurance solo rispetto a vulnerabilità già note fino a quel momento. Non è detto che lo smart contract realizzato sia totalmente esente da vulnerabilità o realizzi la specifica in maniera corretta, perché quella specifica potrebbe non essere stata ancora inserita all'interno della libreria dalla quale attingono questi tool. Nel caso di EtherRAT, gli attaccanti sfruttano a proprio vantaggio questa superficie d'attacco e questi limiti di valutazione automatizzata, scrivendo logiche di risoluzione C2 che sfuggono alle tradizionali definizioni di vulnerabilità e ai database delle firme.

Domande frequenti

Come funziona il Blockchain-based Dead Drop Resolving di EtherRAT?
Il malware interroga ripetitivamente un endpoint pubblico Ethereum (ETH) RPC usando un indirizzo Smart Contract specifico hardcoded per recuperare dinamicamente l'indirizzo del server C2 live, sfruttando la blockchain per resistere ai takedown tradizionali.
Quali strumenti amministrativi sono stati trojanizzati nella campagna?
Gli attaccanti hanno distribuito installatori MSI malevoli camuffati da PsExec, AzCopy, Sysmon, LAPS, Kusto Explorer e una versione trojanizzata di Tftpd64 etichettata come v4.74.
Perché l'infrastrutture C2 su Ethereum è difficile da smantellare per i defender?
Lo Smart Contract vive sulla blockchain in modo immutabile e decentralizzato. I defender possono bloccare l'indirizzo IP del server C2 recuperato, ma i threat actor possono aggiornare l'indirizzo del server all'interno dello Smart Contract in qualsiasi momento, rendendo inefficaci i blocchi tradizionali basati su sequestro di domini o IP.

Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.

Fonti

Link utili

Apri l'articolo su DeafNews