Between October 2 and October 5, unknown attackers seized control of 333 Tor exit nodes, roughly 11 percent of the network’s total exit relay count, and used them to redirect SSH connections through servers they controlled while simultaneously blocking encrypted email ports to expose message contents. The operation was discovered by a Tor volunteer who goes by the name Kaba, whose detailed technical report on October 20 filled in many details that the Tor community had only partially understood.

How the Attackers Got In

The initial breach began in late August, according to Tor volunteer mailing list discussions. The attacker used a valid password that had been reused to gain access to a Tor management server. Once inside, the attacker installed Ebury, a Linux backdoor first identified 12 years ago and associated with large-scale credential theft campaigns.

From that management server, the attacker then connected to a second Tor server called Switzerland2 using an RSA key. Here the investigation ran into its first unresolved problem: investigators could find no record of that RSA key in Switzerland2’s authorized keys file. How it was accepted remains unexplained. With administrative access to Switzerland2, the attacker installed Ebury there as well, then modified the configuration of two exit nodes that Switzerland2 hosted. That foothold eventually expanded to 333 compromised exit relays, though investigators have not established how the attackers reached all of the underlying servers. One hypothesis, described by Kaba as inconclusive, is that a hosting company was breached.

Two Attack Channels: SSH and Email

The hijacked exit nodes were configured to carry out two distinct interception methods simultaneously.

SSH Traffic Redirection

When a Tor user routed an SSH connection on port 22 through one of the 333 compromised nodes, the exit node silently redirected that connection to one of 12 attacker-controlled interception servers. Kaba documented this personally: on the morning of October 17, he attempted an SSH connection over Tor and received the standard OpenSSH host key mismatch warning, which reads in part: “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED” and “IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY.”

For users who dismissed that warning and entered their credentials anyway, the attacker captured three things: the SSH password, a live view of every command typed in the session, and then a second connection back to the victim’s server to install Ebury. The warning is the only visible signal the attack produces. Users who treat it as a routine nuisance and proceed have no other indication that anything is wrong.

Email Downgrade and Plaintext Interception

The second modification blocked ports 25, 465, 587, 993, and 995 on the compromised exit nodes. Those ports carry encrypted email protocols including SMTPS, submission, and IMAPS. By closing them while leaving unencrypted email ports open, the attackers attempted to force email services to downgrade their connections to unencrypted transmissions. If a mail server accepted the downgrade, the attackers could read message contents directly from their position on the exit node. Kaba’s report notes that it remains unclear whether any downgrade attempts succeeded.

How the Campaign Was Mapped

To measure the scope of the attack after his personal encounter with the SSH redirect, Kaba built a script that polled all of Tor’s approximately 3,000 exit nodes. The script connected each node to a test server, then checked whether the reply came from the test server’s legitimate SSH fingerprint or from one of the 12 known interception servers. Kaba also constructed a honeypot to watch the interception software attempt logins and deploy Ebury on victim machines. That combination of active scanning and honeypot observation produced the count of 333 compromised exit relays and the list of 12 interception servers.

What Remains Unknown

Several questions from the investigation remain open. Investigators have not determined how the attackers took control of all 333 servers beyond the documented initial breach of the management server and Switzerland2. The hosting-company hypothesis is unconfirmed. The identity of the attackers is also unknown. Kaba wrote that the use of Ebury and the pattern of collecting unencrypted data in bulk point toward a financially motivated crime group, but described this as speculation. And the Switzerland2 RSA key anomaly, an authentication credential that worked without appearing in the server’s authorized keys list, has no confirmed explanation.

Ebury itself carries a documented history. ESET first disclosed the backdoor and connected it to a cybercriminal operation more than a decade ago. Its reappearance here, at scale inside Tor’s infrastructure, marks one of the more technically ambitious deployments of the malware on record.

What This Means for Tor Users

The Tor network’s design does not protect against a malicious or compromised exit node. The Tor Project’s own documentation states plainly that exit nodes can see the unencrypted content of traffic that is not protected by an additional layer of encryption such as TLS. SSH over Tor relies on SSH’s own host verification to detect a man-in-the-middle attack, which is exactly the warning Kaba received and which the attackers depended on users ignoring.

The practical outcome is straightforward. Any Tor user who connected to an SSH server over port 22 between October 2 and October 5, received a host key mismatch warning, and continued anyway may have had their SSH password stolen and their server infected with Ebury. Any email server that downgraded from encrypted to unencrypted transmission across those exit nodes during the same window may have exposed message content to the attackers.

One question that the investigation leaves open is whether the hosting infrastructure used by the 12 interception servers can be traced to a specific operator or jurisdiction. Kaba’s report identified the fingerprints of the interception servers but did not attribute them to any known group or country.

This article draws on reporting from Ars Technica, the Kaba.cx technical report, The Hacker News, and the Tor relays mailing list.

Want to go deeper? Ask NEX, the Decrypted Matrix research assistant, about the documents behind this story. It indexes every article here the day it is published and cites its sources.