Per dieci giorni, un decimo dei nodi di uscita della rete Tor non ha fatto quello che doveva fare. Invece di consegnare il traffico cifrato dei suoi utenti alla destinazione finale, lo intercettava, lo decifrava al volo e ne rubava le credenziali. Dietro l’operazione c’è Ebury, la backdoor Linux che l’industria della sicurezza conosce (e dà per semi-sconfitta) dal 2014, e che ha dimostrato di essere tutt’altro che morta.

Un avviso SSH che non doveva comparire

Il 2 ottobre 2026 un ricercatore di sicurezza svizzero noto con lo pseudonimo KABA si connette in SSH a un proprio server passando, come fa abitualmente, attraverso la rete Tor. Il client SSH gli mostra un avviso che chiunque amministri server conosce bene e che normalmente fa accapponare la pelle: la chiave host del server remoto è cambiata. Invece di ignorarlo, KABA indaga, e scopre che l’impronta ricevuta non corrisponde a quella del suo server, ma a quella di un sistema sconosciuto.

Usando exitmap, lo strumento sviluppato proprio per testare il comportamento dei nodi di uscita Tor, KABA fissa un singolo relay e apre ripetutamente connessioni SSH verso un proprio server di controllo, verificando ogni volta l’impronta ricevuta. Ripete il test su circa tremila exit relay attivi. Il risultato: una dozzina di nodi presentano apertamente una chiave host falsa, ma oltre trecento reindirizzano silenziosamente le connessioni verso lo stesso gruppo di dodici server, sufficiente per dichiararli compromessi. In totale, 333 exit relay, circa il 10% dell’intera capacità di uscita della rete Tor in quel momento.

Ebury, la backdoor che non muore mai

Il malware installato sui server compromessi è Ebury, una backdoor OpenSSH e stealer di credenziali per Linux documentata per la prima volta da ESET nel 2014 nell’ambito dell’operazione Windigo, e tornata agli onori delle cronache nel maggio 2024 quando lo stesso ESET ha stimato che dal 2009 avesse infettato quasi 400.000 server in tutto il mondo, con oltre 100.000 macchine ancora compromesse alla fine del 2023. La versione individuata in questo caso, la 1.8.3, è più recente di quella descritta negli indicatori pubblici di ESET (ferma alla 1.8.2), segno che gli operatori del malware continuano a svilupparlo attivamente.

Ebury si comporta come un rootkit userland: si maschera da libreria di sistema libkeyutils.so, non modifica i binari di sshd o sudo, supera i controlli di integrità dei pacchetti come dpkg -V e debsums, e non lascia traccia nei log di accesso standard. Sopravvive ai riavvii. Sui server analizzati dal ricercatore, il processo malevolo si camuffava da rsyslogd o da systemd-udevd, comunicando attraverso un socket UNIX astratto nascosto.

Dall’accesso iniziale al dirottamento del traffico

Il caso meglio documentato è quello dell’operatore noto come Zimmer, che gestiva la famiglia di relay “Quetzalcoatl”. Il 28 agosto 2026 un attaccante accede con successo, al primo tentativo, al server di gestione ospitato su Contabo, usando una password che secondo lo stesso Zimmer era stata riutilizzata per l’accesso SSH, per sudo e come passphrase di backup — e salvata in chiaro su due macchine diverse. In cinque minuti l’attaccante ottiene privilegi di root. Poco più di un’ora dopo raggiunge un secondo server, “Switzerland2”, e vi installa Ebury.

Da lì in poi i relay compromessi vengono silenziosamente alterati nel file di configurazione torrc: alcuni middle relay vengono trasformati in exit node con una policy che consente esplicitamente la porta 22, mentre su gran parte dei nodi vengono chiuse le porte cifrate per la posta (465, 587, 993, 995), lasciando aperte quelle in chiaro (IMAP, POP3) per spingere i client a connessioni non protette. Il 1° ottobre, 40 relay gestiti da 21 operatori diversi cambiano policy nell’arco di cinque minuti e mezzo, probabilmente tramite un ricaricamento automatizzato della configurazione: è l’inizio della finestra di attacco attiva, che si chiude il 5 ottobre.

Tecnicamente, l’attacco è un man-in-the-middle SSH classico: le connessioni verso la porta 22 vengono dirottate verso dodici server controllati dagli attaccanti, che presentano una propria chiave host, raccolgono la password digitata dalla vittima, poi si ricollegano al server legittimo inoltrando l’intera sessione in modo trasparente. L’autenticazione basata su chiave pubblica non è vulnerabile, perché la firma crittografica è legata in modo univoco alla sessione e non può essere inoltrata. A essere esposte sono quindi soprattutto le password digitate manualmente e il traffico email non cifrato.

La risposta del Tor Project

Il 4 ottobre il team Network Health del Tor Project, avvisato della scoperta, contatta direttamente gli operatori dei relay sospetti. Zimmer conferma di non aver effettuato alcuna modifica e spegne i propri server. Nello stesso giorno le autorità di directory iniziano a votare i flag BadExit e MiddleOnly per i relay coinvolti, che compaiono nel consenso della rete entro le 21:00 UTC. Il picco di capacità exit compromessa, misurato per peso di consenso, tocca il 7,46%. Il 5 ottobre, dopo un riavvio automatizzato che interessa decine di host dell’operatore Quetzalcoatl, l’ultimo relay con la policy dell’attaccante esce dal consenso di rete. Al 18 ottobre, il numero complessivo di relay con flag Exit non è ancora tornato ai livelli precedenti: mancano all’appello circa 370 nodi.

Un dato che dà la misura della concentrazione geografica dell’attacco: su FranTech Solutions/BuyVM, un provider molto usato dagli operatori di relay Tor, 71 relay su 101 ospitati hanno cambiato policy, contro appena 13 su 9.054 relay ospitati altrove. Ventisei dei ventisette server compromessi individuati al di fuori della famiglia Quetzalcoatl erano proprio su quell’infrastruttura, suggerendo che l’attaccante possa aver sfruttato un accesso privilegiato a livello di hosting, anche se il Tor Project non ha confermato questa ipotesi.

Cosa significa per chi usa (o gestisce) Tor

Va detto con chiarezza: la compromissione non significa che l’attaccante abbia visto tutto il traffico della rete Tor, né che abbia identificato gli utenti. Tor instrada ogni connessione attraverso tre nodi, e solo chi usciva proprio da uno dei 333 relay infetti, con traffico SSH o email non cifrato, era esposto. Ma per chi amministra server via Tor — una pratica comune tra ricercatori di sicurezza, whistleblower e operatori in paesi ad alta sorveglianza — il rischio concreto è stato il furto di credenziali SSH.

Il Tor Project raccomanda a chi avesse accettato una chiave host sconosciuta passando per Tor tra l’1 e il 5 ottobre di considerare la password compromessa, mettere offline il relay coinvolto, preservare disco e log per un’analisi forense, reinstallare da zero, generare una nuova identità del relay e ruotare tutte le credenziali presenti sull’host. Per gli operatori Linux in generale, la lezione è più ampia: riutilizzare la stessa password per SSH, sudo e un backup è esattamente il tipo di errore che Ebury, da oltre quindici anni, continua a sfruttare su scala industriale.

Resta aperta la domanda più importante: chi c’è dietro questa campagna, e quanti altri server — tra i quasi 400.000 compromessi da Ebury nella sua storia — sono ancora sotto il suo controllo. Come ha osservato Marc-Etienne M. Léveillé, ex ricercatore ESET e co-autore degli studi storici su Ebury, il numero di infezioni accumulate nel tempo rende probabile che altri relay compromessi restino ancora da scoprire.

Indicatori di compromissione

Malware: Ebury 1.8.3 (backdoor OpenSSH / credential stealer per Linux)

File sospetto:
/usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2
(libreria setuid non appartenente ad alcun pacchetto installato;
hash differente su ogni host compromesso)
Symlink: libkeyutils.so.1 -> file sopra

Processi mascherati osservati:
/sbin/rsyslogd (falso)
systemd-udevd (falso)
arpd (falso)
snf (processo nascosto)

Socket UNIX astratto:
@event-0YsOG9WSOE

Chiavi SSH associate all'infrastruttura degli attaccanti:
RSA   SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk
ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E
RSA   SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo
ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y

IP sorgente login iniziale (28 agosto 2026):
185.225.226.62

Server di intercettazione MITM: 12 host con chiavi host SSH proprie
che inoltrano il traffico verso il server legittimo dopo la cattura
della password.

Indicatori comportamentali:
- Modifiche non autorizzate al file torrc (policy exit con porta 22 aperta)
- Chiusura delle porte TLS di posta 465/587/993/995 con apertura
  delle corrispondenti porte in chiaro
- File di sistema che superano dpkg -V / debsums nonostante la
  compromissione (rootkit userland)
- Comandi di verifica privilegi osservati in honeypot: id -u,
  command -v sudo, sudo -n true, seguiti da installer Perl
  con payload base64 veicolato tramite libreria Python paramiko

Raccomandazione: prima di ispezionare un host sospetto, avviare la
shell con variabili che bypassano eventuali LD_PRELOAD del rootkit:
H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash