An attacker took control of 333 Tor exit relays and turned them into a collection platform: SSH sessions passing through the compromised exits were redirected to one of 12 interception servers, while ports used for encrypted email submission and retrieval were blocked so that messages could be read in the clear if a service fell back to an unencrypted connection. The account comes from an Ars Technica report by Dan Goodin, which draws on a post and investigation by a Tor volunteer identified as Kaba and on statements from other volunteers.
The scale matters because the network is small: the article puts Tor at roughly 3,000 exit nodes, so the hijacked relays represent about a tenth of the exits traffic can leave through.
A reused password, Ebury, and the pivot to Switzerland2
According to the Tor volunteers cited in the report, the intrusion began in late August, with the hijacking itself falling between October 2 and October 5. The entry point was a valid password that had been reused on a Tor management server. From there the attacker installed Ebury, a Linux backdoor that the article says was discovered 12 years earlier, and then opened an SSH connection from that management server to a second Tor machine referred to as Switzerland2.
That second hop used an RSA key that investigators could not find among Switzerland2's authorized keys. Ebury was installed on Switzerland2 as well, and two exit relays hosted by that machine were reconfigured. The volunteers have not established how the attacker obtained control of the remaining underlying servers, and one theory they have floated — that a hosting company was compromised — is described as inconclusive.
How SSH traffic was captured and turned into more infections
Kaba's investigation found that SSH traffic on port 22 traversing the compromised exits was redirected to the 12 attacker-run servers. When users ignored the host-key change warning, the attacker stole their SSH password, opened a connection to the victim server and observed all typed commands, and then opened a second connection and infected the server with Ebury.
The fingerprint presented in the spoofed warning is SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. The warning text is the standard client message beginning "REMOTE HOST IDENTIFICATION HAS CHANGED". Anyone who accepted a new key from an exit relay during the affected window should treat both the credentials used in that session and the server on the far end as suspect.
Email: blocking the encrypted ports
On the email side, the compromised exits blocked ports 25, 465, 587, 993 and 995 — the ports used for encrypted submission and retrieval — while leaving the ports for receiving unencrypted mail open. The effect was to push traffic toward connections the attacker could read if a mail service downgraded. Whether any downgrade attempt actually succeeded is not established in the report.
The polling script and the honeypot that exposed it
The compromise surfaced through a checking method rather than a tip-off. A script polled every exit relay to see whether it presented the correct SSH fingerprint for a test server; the test server also recorded whether an incoming connection came from a pinned exit or from one of the 12 interception servers. A honeypot was deployed to watch the interception software attempt a login and install Ebury. The hijacking began in late August and occurred from October 2 to October 5; Kaba's own test connection was redirected on a Friday morning, and the researcher's report was published on Tuesday.
Attribution remains speculation
Kaba said the use of Ebury together with broad collection of unencrypted data points to a financially motivated crime group, and explicitly described that as speculation. The article does not identify who is behind the campaign.
Practical steps for anyone who used these exits
The measures the article lists are aimed squarely at what the attacker exploited. Accept only encrypted email traffic on the client side and refuse unencrypted ports. Turn off password authentication for SSH and use key-based logins, which the captured credentials would not have helped against. And treat an unexpected host-key change as a possible man-in-the-middle rather than a nuisance to click through — the warning itself tells users to contact the system administrator, and verifying the new key out of band is the only way to tell a legitimate rotation from an interception server.
