333 Tor exit relays hijacked in Ebury campaign to intercept SSH passwords and plaintext mail

Roughly one in ten Tor exit relays was quietly turned against its users earlier this month. A coordinated campaign that began on 2 October 2026 used 333 compromised exit nodes to redirect SSH connections to attacker-run interception servers and to push mail traffic toward unencrypted ports, according to a Tor volunteer who found it and a separate incident write-up by relay operators. The relays were flagged and shut down by 5 October, but the open questions are significant: nobody has said how the attackers got into so many servers, or who they are.

Key points

• 333 Tor exit relays, about 10% of the network's roughly 3,000 exits, took part in an SSH interception and unencrypted-mail campaign that began on 2 October 2026 (researcher Kaba's post, 20 October).
• The servers had carried the Ebury 1.8.3 OpenSSH backdoor since August; operators of two affected servers date their own compromise to 28 August.
• SSH on port 22 through an infected exit was redirected to one of 12 interception servers; a user who ignored the host-key warning gave up their password and their server could be infected with Ebury.
• The Tor network health team marked the relays BadExit on 4 October, and all infected servers were offline by 5 October.
• The attack's origin and the way the servers were breached are still unknown.

What to do

• If you use SSH over Tor, never accept a changed host key. A "REMOTE HOST IDENTIFICATION HAS CHANGED" warning during that window was the visible sign of this attack. If you clicked through between 2 and 5 October, treat that password as stolen, change it and check the server for Ebury.
• Switch to SSH keys and disable password authentication, as both the researcher and Ars Technica recommend.
• Mail clients: configure accounts to accept only encrypted connections (ports 465, 587, 993, 995 or STARTTLS enforced) so a downgrade attempt fails instead of falling back to plaintext.
• Relay and server operators: the operators' timeline mentions an advisory checklist from the Tor Project to check against; treat relays as highly targeted production machines.

What happened

According to Kaba's post, on Friday 2 October at 09:35 the 333 infected exit nodes began a coordinated campaign. Two things changed on those relays. First, they blocked the encrypted mail ports (25, 465, 587, 993 and 995 as Ars Technica lists them) while leaving ports for unencrypted mail open, hoping mail software would fall back to plaintext. Whether any such downgrade succeeded is unclear, Ars notes.

Second, SSH traffic to port 22 passing through an infected exit was silently redirected to one of 12 attacker-controlled interception servers. Kaba noticed because his own connection triggered OpenSSH's changed-host-key warning. Using a honeypot, he saw that if a user ignored the warning the attacker stole the password, opened a connection to the real server to watch typed commands, and opened a second connection to install Ebury. The tooling used the Python SSH library paramiko and a base64-encoded Perl installer.

He reported to the Tor Project's network health team on Friday evening. Per his timeline: on Sunday 4 October the team told relay operators, who began shutting exits down, and the relays were marked BadExit so clients stopped using them to exit traffic; on Monday 5 October the attackers restarted many of them, but as they were already flagged they could only act as middle relays; by the end of 5 October all infected servers were shut down, some by operators and some by the attackers. The Tor team told him it had not seen this attack before.

Background

Ebury is not new. ESET describes it as an OpenSSH backdoor and credential stealer active since at least 2009, deployed on almost 400,000 Linux, FreeBSD and OpenBSD servers over the years, with more than 100,000 still compromised as of late 2023 (ESET, May 2024). Its operators have run spam, traffic redirection, credential theft and cryptocurrency theft. That scale is why one ESET researcher quoted by Kaba says there are probably other compromised Tor relays beyond these.

Tor's design makes exit relays a known soft spot: the last hop sees traffic to the destination, so a malicious exit can tamper with anything not protected end to end. SSH's host-key check and mail's TLS are exactly the end-to-end protections this attack tried to defeat or sidestep.

A relay-operator group, Quetzalcoatl, published a detailed timeline on the tor-relays mailing list on 7 October after a Tor Project security notice on 5 October. It says two of its servers were infected with Ebury 1.8.3: a VPS used as VPN gateway and SSH jump host, and a second host running two exit relays. Its account is that on 28 August an attacker logged in to the first server from one IP address using the operator account's password on the first try, gained root, and installed Ebury within minutes; about an hour later a login to the second server succeeded using an RSA key the operators could not find in any authorized_keys file. The operators also report that the same password doubled as the sudo password and the passphrase for an encrypted backup that held their SSH key and relay master keys. They say the attacker truncated logs, and that Ebury's logins leave no history, so parts of the timeline are inferred.

The operators say their review used several AI-assisted passes, cross-checked against logs and public Tor metrics; we have not independently verified their findings.

How it works

The attack chain, as described across the sources:

1. Gain access to a Linux host running Tor relays (how remains unknown at scale).
2. Install Ebury 1.8.3 for persistence and credential theft.
3. Per the Tor network health team, on hosts running non-exit relays, edit the torrc file to turn them into exits.
4. On 2 October, redirect port 22 traffic to 12 interception servers and block encrypted mail ports.
5. Harvest SSH passwords from users who ignore host-key warnings; infect their servers.

Kaba found the nodes by scripting a check against all roughly 3,000 exits with the exitmap tool: pin one exit, connect from his server A to his server B, and have A verify the SSH fingerprint and B verify whether the connection arrived from the pinned exit or from one of the 12 interception servers. Around a dozen served a fake fingerprint; over 300 more intercepted nothing themselves but redirected through the same servers, which was enough to confirm infection.

What it means

For Tor users the core risk was narrow but real: only SSH on port 22 and plaintext mail were targeted, and ordinary encrypted web browsing passed through untouched, Kaba writes. People who verify host keys were protected by the warning; people who click through are the ones the attack was built for.

For relay operators it is a reminder that password logins, reused passwords and stored backups with keys turn one compromised jump host into a fleet compromise. Tor volunteer George is quoted in the thread saying relays and bridges should be treated as highly targeted production machines.

For the network, Kaba reports a clear dip in exit capacity on Tor Metrics from 4 October that had not recovered at the time of writing, and appeals for more people to run relays.

What we don't know yet

• How the attackers reached all 333 hosts. A hosting-company breach is one theory, but the sources call it unproven.
• Who is behind it. Kaba says Ebury and the plaintext mail collection point to a financially motivated crime group, and adds that this is speculation.
• Whether any mail was actually read, or any SSH passwords stolen and used. The sources do not report confirmed victims.
• Why one server accepted an SSH key that investigators could not find on it.

What to watch next

Further Tor Project updates and the BadExit list; whether other hosting providers find Ebury; and whether the Tor Project changes how relays are monitored for unexpected exit-policy changes. Our recent coverage of other trust failures: eMudhra's eight compromised TLS intermediates.

Sources

• Kaba, "How I got over 300 Tor exit nodes removed", 20 October 2026
• Quetzalcoatl operators, "Ebury 1.8.3 on two relay servers: timeline, lessons, open questions", tor-relays, 7 October 2026
• Ars Technica, "333 Tor exit nodes hijacked to intercept SSH traffic and retrieve plaintext email"
• ESET Research, "Ebury botnet alive & growing", 15 May 2024