333 Tor exit relays rerouted SSH and tilted mail ports toward plaintext

Roughly one in ten Tor exit relays was quietly turned into an SSH password trap in early October. A researcher publishing as kaba scanned all of Tor's roughly 3,000 exits on October 2 and found 333 redirecting SSH to the same 12 interception servers. Nothing in Tor's cryptography failed. The attackers took over the Linux hosts underneath the relays and rewrote a text file.

01How the relays were turned

An exit relay carries traffic only to the ports its exit policy allows, and that policy lives in the relay's torrc configuration file. Starting October 1, attackers rewrote those policies to open port 22. That enabled SSH on 342 relays that had blocked it and turned 24 non-exit relays into exits.

The one fully documented entry path is a relay operator's own infrastructure, not Tor Project systems. Ars Technica's summary calls it a "Tor management server", but the post-mortem describes it differently. It was the operator's Contabo VPS, which served as a WireGuard gateway, SSH jump host and obfs4 bridge. A second machine, Switzerland2, was a FranTech VPS running two of the operator's exit relays. The attacker used the operator's password, which worked on the first try, and had root five minutes later. That matches Ars's account of a reused password.

Ebury 1.8.3 was installed on that server. About an hour later, Switzerland2 accepted a login with an RSA key that was in none of its authorized_keys files, and Ebury was installed there one second later. The operator says how that key was accepted is still an open question. Marc-Etienne Léveillé, who has tracked Ebury for 13 years, suggested on the mailing list that Ebury may have been present earlier and updated on September 30. He also raised a compromised hosting provider as a possibility.

The operator's own post-mortem shows how the attacker rewrote policy on Switzerland2. The operator's ansible-generated accept list of 60 port ranges was removed. Five reject lines for ports 25, 465, 587, 993 and 995 were appended after "# end of torrc". Both Switzerland2 relays published the result at 09:34:04 on October 2.

How the other relays fell is unresolved. Ars notes that investigators have not established how all 333 underlying servers were taken. One pattern points at hosting, though. 71 of the 101 third-party relays at FranTech Solutions flipped, against 13 of the 9,054 relays hosted elsewhere. That is correlation, not proof of a provider breach.

02The two payloads: SSH and mail

SSH. Traffic to port 22 left the compromised exits for one of 12 interceptors. The interceptor presented its own host key, recorded any password typed, then logged in to the real server so the session looked normal. A user who ignored OpenSSH's changed-host-key warning therefore exposed their credentials and gave the attacker a live view of the session. Ars reports a third step as well. The attacker opened a further connection to try to plant Ebury on the destination. In kaba's honeypot, the attacker's client identified itself as paramiko, checked the user ID and passwordless sudo, then ran a base64-encoded Perl command to install Ebury.

Detection was harder than the warning suggests. Only about a dozen exits served a fake host key. The other 300 or so redirected traffic through the same servers without changing the key. A user reaching a server through one of those exits would see nothing unusual, but the server would see a connection from an interceptor's address rather than the exit's.

Mail. The mail change is subtler than Ars's shorthand suggests, because not every blocked port is encrypted-only. The operator's analysis lists 25, 587 and the 110/143 pair as "TLS optional". Only 465, 993 and 995 are implicit-TLS ports. The final policy blocked mail submission and encrypted mail reading but left plaintext POP3 (110) and IMAP (143) open. The operator also notes that the first policy the attacker tried was the reverse. It blocked plaintext POP3 and IMAP and was replaced by the one that went live.

The inference is that clients configured to try TLS and fall back would be pushed to cleartext. An exit relay reads whatever leaves in cleartext, and it can also strip STARTTLS negotiation. On most relays the change also opened plaintext POP3 and IMAP. Whether any mail client actually downgraded is unknown, as Ars notes.

03Scale, duration and cleanup

Ars puts the hijack at October 2 to 5. Other accounts count the policy window differently. The Switzerland2 policy ran for about 52 hours on two Guard+Exit relays moving roughly 3.4 TiB a day. Ebury itself dates to well before the campaign. ESET estimated in 2024 that it had infected around 400,000 Linux servers since 2009.

• Share of network: At the peak, on October 4 at 01:00 UTC, the hijacked relays carried 7.46% of Tor's usable exit weight.
• Broader policy match: A directory-data analysis counted 377 relays run by 59 operators that adopted the attacker's exit policy between October 1 and 4. The analysis itself calls this a policy match, not proof of compromise.
• Response: Kaba reported on the evening of October 2. Directory authorities began applying BadExit on the evening of October 4, and by 17:00 UTC on October 5 no relay with the attacker's policy remained in the consensus. When the attackers restarted many relays on October 5, the flags limited them to middle-relay duty.

Kaba says the Tor network health team told him it had not seen an attack like this before.

04What this says about Tor's trust model

Tor separates who you are from what you send, and it does not protect the content once it leaves the exit. The Tor Project's long-standing advice is to use end-to-end encryption such as HTTPS, because the exit sees plain traffic. Exit abuse is not new. A 2014 Karlstad University study found 19 exit relays using self-signed certificates for man-in-the-middle attacks on HTTPS and SSH. In 2020 researcher nusenu reported attackers running 380 exit relays at their peak, giving users roughly a one-in-four chance of a malicious exit.

What is distinctive here is the mechanism. These were honest operators' relays, flipped through ordinary host compromise, and exit policy was the lever. The Network Health team described the attacker as editing torrc files to turn non-exit relays into exits. The defence that worked was external observation: exitmap scanning, directory data and a researcher who refused to click through a warning. The family-level view helps too. The operator's Onionoo query showed 168 relays on 57 IPs advertising the same near-open policy. The Tor network trusts volunteers' hosts to stay uncompromised, and a single leaked credential can scale into a network-level event.

05Detection and mitigation

For users and SSH administrators:

1. Treat a changed-host-key warning as an incident. Anyone who typed a password after accepting a new key should treat it as stolen, rotate it and check the target for Ebury.
2. Disable password authentication in favour of keys, as Ars recommends. A man-in-the-middle then captures nothing reusable. Pin host keys with strict checking, or use SSH certificates.
3. Where possible, reach administrative services over an onion service so no exit is involved. This is general practice rather than something the sources address.
4. Use implicit TLS (465, 993, 995) and configure clients to refuse cleartext instead of falling back.

For relay operators and network teams:

• Alert on any exit-policy change that your configuration management did not make. Compare the published descriptor with the intended one.
• Run canary probes through exits, as kaba did, checking both the key presented and the source address seen by the destination.
• Do not reuse operator passwords, and require key-only access for jump hosts.
• Assume a clean-looking host may not be clean. Ebury 1.8.3 is newer than ESET's public indicators, and the operator found no NAT redirect, new users or modified tor binary. Backdoor logins leave no login records or shell history. Experts advise taking relays down, snapshotting the disk and rebuilding from scratch rather than cleaning in place.

06What remains unproven

Several questions are open. These include how the other relays were accessed, why Switzerland2 accepted the unlisted key, and who is behind it. Kaba says the Ebury use and the sweep of unencrypted data point to a financially motivated group, but he flags that as speculation. Léveillé's view is that, given Ebury's reach, other compromised Tor relays are most likely out there. Nobody has shown how many passwords were captured or whether any mail was downgraded.