Una campagna informatica ha coinvolto 333 relay di uscita della rete Tor, reindirizzando le connessioni SSH verso server controllati dagli aggressori. Nel mirino anche la posta elettronica, mentre restano da chiarire l’effettiva portata del furto di dati e le modalità complete della compromissione.
La rete Tor è finita al centro di una campagna informatica che ha sfruttato 333 nodi di uscita manipolati per intercettare connessioni SSH e tentare di sottrarre credenziali di accesso. L’operazione, individuata tra il 2 e il 5 ottobre 2026, ha permesso agli aggressori di modificare il percorso delle connessioni dirette ai server remoti, facendole transitare attraverso 12 infrastrutture sotto il loro controllo.
L’attività non si sarebbe limitata alle connessioni SSH, utilizzate dagli amministratori di sistema per gestire server a distanza. Gli attaccanti avrebbero cercato di intervenire anche sul traffico di posta elettronica, sfruttando configurazioni che potevano favorire il trasferimento di messaggi senza cifratura.
La vicenda è stata documentata dal ricercatore di sicurezza noto come Kaba, che ha pubblicato il proprio resoconto il 20 ottobre, dopo aver individuato personalmente una connessione SSH sospetta. Il caso evidenzia un rischio importante per chi utilizza Tor per proteggere la propria navigazione: l’anonimato del percorso non garantisce, da solo, l’integrità delle connessioni né la sicurezza dei servizi raggiunti.
Come funzionava l’attacco ai nodi di uscita Tor
Il meccanismo individuato dagli esperti faceva leva sulla manipolazione dei relay di uscita, i nodi attraverso i quali il traffico della rete Tor raggiunge la destinazione finale.
Gli aggressori hanno modificato le configurazioni dei sistemi compromessi per reindirizzare le connessioni SSH verso 12 server intermedi controllati direttamente. In questo modo potevano posizionarsi tra l’utente e il server legittimo, creando le condizioni per intercettare le informazioni trasmesse durante il tentativo di autenticazione.
Il passaggio decisivo era rappresentato dall’avviso generato dal client SSH. Quando la chiave del server remoto non corrisponde a quella registrata in precedenza, il software segnala una possibile alterazione dell’identità della macchina di destinazione.
Proseguire ignorando l’avvertimento poteva consegnare la password agli aggressori. Il rischio, quindi, non dipendeva soltanto dalla presenza di un nodo compromesso, ma anche dalla decisione dell’utente di accettare una chiave SSH sconosciuta o inattesa.
Un avviso sulla chiave del server non deve essere ignorato: potrebbe indicare un cambiamento legittimo dell’infrastruttura, ma anche un tentativo di intercettazione.
Dal furto delle credenziali all’installazione di una backdoor Linux
Le conseguenze potenziali della campagna andavano oltre la semplice raccolta delle password. Una volta ottenute le credenziali, gli aggressori potevano tentare di raggiungere il server reale e sfruttare la sessione per osservare le attività dell’utente.
Secondo la ricostruzione, l’intermediario ostile poteva inoltre avviare una seconda connessione verso la destinazione autentica e tentare di installare Ebury, una backdoor per Linux associata ad attività di furto delle credenziali SSH.
Un simile scenario avrebbe potuto trasformare un’intercettazione iniziale in una compromissione più persistente del sistema remoto, con possibili conseguenze per l’amministrazione del server e la sicurezza delle infrastrutture collegate.
È importante, tuttavia, distinguere le capacità tecniche osservate dagli esiti effettivamente confermati. Il coinvolgimento di 333 relay non significa che siano stati violati altrettanti server o che tutti gli utenti transitati attraverso quei nodi abbiano perso le proprie credenziali.
Un ulteriore elemento ha reso l’operazione più insidiosa: il normale funzionamento della navigazione web cifrata non implicava necessariamente la sicurezza delle connessioni SSH. Un utente poteva continuare a navigare senza anomalie evidenti, mentre una connessione amministrativa veniva indirizzata verso un intermediario malevolo.
Oltre 3.000 relay controllati durante l’indagine
Per comprendere le dimensioni dell’operazione, Kaba ha esaminato circa 3.000 relay di uscita, confrontando le impronte delle chiavi SSH ricevute con quelle di un server di prova e verificando la provenienza delle connessioni.
L’attività di analisi è stata affiancata dall’impiego di un honeypot, un sistema-esca progettato per attirare e registrare comportamenti sospetti. Questo strumento ha consentito di osservare tentativi di accesso e attività riconducibili all’installazione del malware.
Dai controlli sono emersi 333 nodi coinvolti nel dirottamento del traffico SSH. Il dato descrive l’estensione dell’infrastruttura manipolata, ma non consente di stabilire quanti utenti siano stati effettivamente esposti, quanti abbiano inserito le proprie password o quanti server siano stati compromessi con successo.
La distinzione è essenziale per valutare correttamente l’impatto dell’incidente: il numero dei relay identificati non coincide con quello delle vittime accertate.
Email a rischio: bloccate alcune porte per favorire il traffico non cifrato
La campagna avrebbe interessato anche i servizi di posta elettronica. In particolare, gli aggressori avrebbero bloccato le porte 25, 465, 587, 993 e 995, lasciando disponibili connessioni che potevano consentire la ricezione di messaggi senza adeguata protezione crittografica.
La strategia avrebbe potuto spingere alcuni client o servizi a utilizzare modalità di comunicazione meno sicure, creando un’opportunità per intercettare messaggi in chiaro.
Questo tipo di manipolazione prende di mira un punto debole fondamentale: se un servizio accetta di proseguire senza cifratura, un intermediario può avere maggiori possibilità di leggere i contenuti trasmessi.
Al momento, però, non è stato dimostrato che i tentativi di downgrade della posta elettronica siano andati a buon fine. Il blocco delle porte, da solo, non prova che gli aggressori abbiano raccolto messaggi o sottratto credenziali email.
La vicenda conferma comunque l’importanza di configurare i servizi di posta in modo da rifiutare connessioni non cifrate, anziché consentire automaticamente il passaggio a modalità meno sicure.
Come è iniziata la compromissione? Restano interrogativi aperti
Un altro aspetto ancora da chiarire riguarda l’accesso iniziale alle infrastrutture coinvolte.
Un operatore ha riferito di un episodio avvenuto alla fine di agosto, quando un server di gestione sarebbe stato raggiunto utilizzando una password già impiegata altrove. Dopo l’accesso, sarebbe stato installato Ebury.
Da quel sistema, l’attaccante avrebbe raggiunto Switzerland2, una macchina che ospitava due relay Tor, utilizzando una chiave RSA che non risultava tra quelle autorizzate.
La ricostruzione fornisce indicazioni su una possibile catena di compromissione, ma non spiega completamente come siano stati violati tutti i server interessati. Rimane quindi aperta la questione relativa all’origine dell’intera campagna e alle modalità con cui l’attività si è estesa ad altre infrastrutture.
La risposta del Tor Project e la rimozione dei relay sospetti
Il Tor Project ha confermato le segnalazioni attraverso un avviso pubblicato il 5 ottobre 2026. Secondo quanto comunicato dal gruppo Network Health, alcuni host Linux compromessi presentavano modifiche al file di configurazione torrc, comprese alterazioni finalizzate a trasformare relay intermedi in nodi di uscita.
Le autorità responsabili della gestione delle directory Tor hanno quindi avviato l’esclusione dei relay identificati, con l’obiettivo di impedire che continuassero a essere utilizzati dalla rete.
L’intervento punta a limitare l’esposizione degli utenti, ma gli operatori che gestiscono nodi potenzialmente compromessi devono verificare direttamente l’integrità delle proprie macchine. La semplice rimozione di un relay dalla rete, infatti, non garantisce che il sistema sottostante sia stato ripulito.
Come proteggersi dagli attacchi SSH attraverso Tor
L’incidente offre indicazioni concrete sia agli amministratori di sistema sia agli utenti che utilizzano Tor per proteggere le proprie comunicazioni.
Tra le principali misure di sicurezza raccomandate rientrano:
Verificare le chiavi SSH: non accettare automaticamente avvisi relativi a chiavi sconosciute o modificate. Prima di proseguire, occorre verificare l’identità del server attraverso un canale affidabile.
Preferire l’autenticazione con chiavi crittografiche: l’uso di chiavi SSH, associato a una gestione sicura delle credenziali, riduce la dipendenza dalle password. Per una protezione maggiore, è opportuno disabilitare l’autenticazione tramite password quando non necessaria.
Controllare le configurazioni dei relay: gli amministratori devono verificare il file torrc, i processi attivi e le regole di reindirizzamento del traffico, prestando particolare attenzione alla porta 22, utilizzata normalmente da SSH.
Non riutilizzare le password: credenziali condivise tra più sistemi possono trasformare la compromissione di un singolo server in un punto di ingresso per ulteriori attacchi.
Imporre la cifratura della posta elettronica: i server e i client devono essere configurati per rifiutare connessioni non protette, evitando il ricorso automatico a modalità in chiaro.
Gestire correttamente gli incidenti: in presenza di una compromissione, gli operatori dovrebbero conservare dischi e registri utili alle analisi, reinstallare il sistema da una fonte affidabile e sostituire le identità dei relay e le credenziali potenzialmente esposte.
Tor resta uno strumento per la privacy, ma non sostituisce la sicurezza degli endpoint
La campagna dimostra che anche un’infrastruttura progettata per favorire l’anonimato può essere sfruttata quando alcuni dei suoi componenti vengono compromessi.
Tor protegge il percorso della comunicazione e rende più difficile collegare direttamente l’attività online all’indirizzo IP dell’utente. Non può, tuttavia, garantire che ogni nodo attraversato sia affidabile, né impedire che un utente consegni volontariamente una password a un sistema che si presenta come il server corretto.
Il punto centrale è proprio questo: anonimato, cifratura e autenticazione sono livelli di protezione differenti. Per difendersi da attacchi di questo tipo è necessario combinarli, verificando le identità dei server, evitando credenziali riutilizzate e impedendo qualsiasi passaggio a connessioni non cifrate.
L’indagine sui 333 relay manipolati ha portato alla luce una tecnica capace di sfruttare la fiducia degli utenti nelle connessioni amministrative. Resta da determinare la reale portata dei danni, soprattutto per quanto riguarda le email e l’eventuale compromissione dei server raggiunti attraverso i nodi malevoli.