Evooo1Bot trasforma router in proxy SOCKS5 e nodi DDoS

🛡️ Executive Summary

• Evooo1Bot sfrutta vulnerabilità note in router, gateway e apparati edge di diversi produttori per distribuire binari Linux compatibili con dodici architetture.
• Il malware integra proxy SOCKS5, shell remota, brute force SSH, sniffer di credenziali e sedici modalità DDoS derivate da Mirai.
• Firmware aggiornati, credenziali robuste, pannelli remoti disabilitati e monitoraggio delle connessioni outbound riducono l’esposizione dei dispositivi Internet-facing.

Una nuova botnet Linux denominata Evooo1Bot sta trasformando router, gateway e altri dispositivi esposti su Internet in un’infrastruttura multifunzione per proxy SOCKS5, attacchi DDoS, brute force SSH e raccolta di credenziali. La famiglia deriva da Mirai, ma ne supera ampiamente il tradizionale modello basato sulla sola potenza di fuoco distribuita. Secondo l’analisi di FortiGuard Labs, l’attività viene osservata almeno da luglio 2026 e sfrutta vulnerabilità note in prodotti Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare e D-Link. Il componente più rilevante è il relay SOCKS, capace di trasformare l’indirizzo IP della vittima in un punto di transito per altre operazioni.

Evooo1Bot sfrutta vecchie CVE per entrare nei dispositivi edge

La campagna è emersa dalla telemetria FortiGuard IPS, che ha rilevato tentativi di sfruttamento contro apparati edge con callback dirette allo stesso loader. Tra le vulnerabilità effettivamente osservate nel traffico figurano CVE-2007-3010 su Alcatel OmniPCX Enterprise, CVE-2016-6277 su router NETGEAR, CVE-2018-14558 e CVE-2020-10987 su dispositivi Tenda, CVE-2019-14931 sui sistemi Mitsubishi Electric ME-RTU, CVE-2021-46422 e CVE-2024-29269 su apparati Telesquare e diverse falle nei router D-Link, comprese CVE-2022-37055, CVE-2025-10123 e CVE-2025-55583. Il denominatore comune non è quindi una singola zero-day, ma l’esistenza di dispositivi Internet-facing ancora raggiungibili attraverso vulnerabilità pubbliche, alcune delle quali risalgono a molti anni fa. Una volta ottenuta l’esecuzione di comandi, uno script scarica il binario adatto all’architettura della vittima scegliendo tra dodici build, utilizzando in sequenza wget, BusyBox, curl o TFTP, quindi cancella la cronologia Bash per ridurre le tracce immediate dell’infezione. Il meccanismo ricorda il modello già osservato con AryStinger, che trasformava router legacy vulnerabili in proxy globali: hardware ancora operativo ma scarsamente aggiornato diventa una risorsa riutilizzabile molto tempo dopo la pubblicazione delle falle. Il rapporto tecnico di FortiGuard Labs evidenzia inoltre che i comandi di download includono etichette differenti per ciascuna campagna, elemento che permette agli operatori di misurare separatamente il rendimento dei vari exploit.

Il proxy SOCKS5 trasforma ogni vittima in un relay operativo

La caratteristica che distingue maggiormente Evooo1Bot dalle numerose ricompilazioni di Mirai è il modulo SOCKS5, progettato per convertire il dispositivo compromesso in un relay TCP utilizzabile dagli operatori. In modalità diretta il malware apre un listener SOCKS5, normalmente sulla porta TCP 1080, tentando prima una configurazione dual-stack IPv6 e ripiegando su IPv4 quando necessario. Più interessante è la modalità reverse relay: il bot apre autonomamente una connessione cifrata verso un server scelto dall’operatore e mantiene un canale persistente attraverso il quale possono essere create nuove sessioni proxy senza esporre direttamente una porta verso Internet.

Ogni sessione dispone di una connessione dedicata e più flussi possono funzionare contemporaneamente. In questo modo l’indirizzo IP appartenente alla rete compromessa può essere utilizzato come origine apparente di scansioni, frodi, accessi ad altri servizi o attività che beneficiano di una provenienza residenziale o aziendale. Fortinet osserva che, su una botnet sufficientemente estesa, questa funzione potrebbe essere monetizzata anche attraverso servizi di proxy residenziali o enterprise clandestini. È un’evoluzione che Matrice Digitale aveva già documentato con Tengu, variante Mirai dotata anch’essa di proxy SOCKS5 e meccanismi avanzati di persistenza: il dispositivo IoT compromesso non vale più soltanto per i pacchetti che riesce a generare durante un DDoS, ma per la posizione di rete, l’indirizzo IP e l’accesso persistente che può offrire.

Shell remota, sniffer e brute force ampliano il controllo

Il relay costituisce soltanto uno dei moduli presenti nella versione più recente di Evooo1Bot. Gli operatori dispongono di una vera shell interattiva basata su pseudo-terminal, possono eseguire comandi, avviare processi in background e trasferire file in entrambe le direzioni. Un modulo sniffer osserva /proc/net/tcp e cerca di intercettare intestazioni HTTP Basic Authorization e Cookie, trasformando il nodo infetto anche in una possibile fonte di credenziali e token presenti nel traffico accessibile al sistema. Il componente SSH dispone invece di un dizionario con più di 150 combinazioni di username e password che non comprende soltanto credenziali tipiche dei dispositivi IoT, ma anche account come jenkins, postgres, oracle, nagios e deploy, più comuni negli ambienti enterprise e operativi. Prima di procedere con l’infezione, il malware tenta inoltre di riconoscere honeypot come Cowrie e Kippo, analizzando banner SSH, filesystem e informazioni sul kernel. Anche la fase di avvio contiene numerosi controlli anti-analisi: Evooo1Bot cerca debugger, strumenti di reverse engineering, packet analyzer, sandbox, macchine virtuali e container prima di collegarsi al C2 sulla porta 443, scelta che permette al traffico di confondersi meglio con le normali connessioni HTTPS osservate sul perimetro. Le stringhe interne sono protette attraverso più livelli basati su AES, ChaCha20 e XOR, mentre le chiavi vengono ricostruite a runtime invece di comparire direttamente nel binario.

Mirai resta nel motore DDoS ma non definisce più la botnet

L’eredità di Mirai rimane evidente nel modulo DDoS, che conserva un motore strutturalmente compatibile con il codice sorgente reso pubblico anni fa e mette a disposizione sedici modalità di flood. Gli operatori possono generare traffico UDP, DNS, TCP SYN e ACK, GRE, pacchetti TCP frammentati e richieste HTTP personalizzabili, oltre a modalità progettate per aumentare il numero di pacchetti o tentare di superare specifiche protezioni anti-DDoS. Il valore di Evooo1Bot, tuttavia, nasce proprio dal fatto che questa capacità non è più il centro esclusivo dell’architettura. La stessa macchina può svolgere ricognizione, offrire un proxy, tentare nuove compromissioni SSH, eseguire comandi e partecipare successivamente a un flood distribuito. La tendenza è coerente con quanto osservato nella botnet Dysphoria, dove oltre 200.000 dispositivi IoT venivano utilizzati anche come relay e proxy oltre che per attacchi DDoS. Evooo1Bot integra inoltre un modulo dedicato allo sfruttamento di CVE che contiene riferimenti a bersagli come Hikvision, Atlassian Confluence, Zyxel, TP-Link, D-Link NAS, WSO2, PHP-CGI e Kubernetes ingress-nginx. Fortinet precisa però che alcune routine sono implementate in modo errato e non sono sfruttabili così come risultano nei campioni analizzati: la presenza di un identificativo CVE nel malware non dimostra quindi automaticamente che l’exploit corrispondente funzioni né che sia stato osservato in uso operativo.

La persistenza rende insufficiente il semplice riavvio

Una volta installato, Evooo1Bot tenta di rendere stabile la compromissione utilizzando simultaneamente più meccanismi Linux. Può creare un servizio systemd mascherato da componente Apache, aggiungere uno script SysV init, modificare rc.local e i profili shell e inserire un’attività cron che riscarica il payload ogni cinque minuti. Il malware interviene anche su /proc/self/oom_score_adj per ridurre la probabilità di essere terminato dall’OOM killer e mantiene aperto /dev/watchdog, complicando ulteriormente gli interventi che si limitano alla terminazione del processo. Per amministratori e proprietari di apparati edge la mitigazione parte quindi dalla prevenzione: applicazione degli aggiornamenti firmware, eliminazione delle credenziali predefinite, disattivazione dei pannelli di amministrazione remota non necessari e sostituzione degli apparati che non ricevono più patch. Negli ambienti aziendali diventa inoltre essenziale controllare le connessioni outbound anomale da router, gateway, telecamere e sistemi embedded, perché il reverse relay permette alla vittima di iniziare la comunicazione verso l’esterno senza attendere connessioni inbound evidenti. In presenza di una compromissione non è sufficiente presumere che un reboot abbia eliminato il malware: servizi di avvio, cron, profili shell e configurazioni persistenti devono essere verificati prima di considerare il dispositivo nuovamente affidabile. Evooo1Bot conferma così una trasformazione ormai evidente nell’ecosistema Mirai: le botnet Linux stanno diventando piattaforme modulari nelle quali DDoS, proxying, accesso remoto e propagazione convivono sullo stesso nodo compromesso.