Attackers took over hundreds of Tor exit relays in early October and used them to catch SSH passwords. A researcher who publishes as kaba spotted it on 2 October, when an SSH login made over Tor threw a changed host key warning. Scans showed 333 of Tor’s roughly 3,000 exit relays quietly sending port 22 traffic to 12 interception servers.
Table of Contents
How the hijacked Tor exit relays worked
An exit relay is the last hop in a Tor circuit. It passes your traffic on to its real destination, and it only carries the ports its operator allows. The attackers broke into Linux servers that ran relays and edited the Tor configuration file, known as torrc. Some relays that had blocked SSH now allowed it. A few that were not exits at all became exits.
The Tor Project’s network health team described the pattern in a notice on 5 October. In their words, the attacker was gaining access to Linux hosts and turning non-exits into exits to carry out the SSH attack. Most of the affected relays were exits already.
With port 22 open, a connection did not reach the server you asked for. It went to one of 12 interception servers. Encrypted web traffic passed through as normal, so nobody browsing would have noticed a thing.
What happened to your password
If you ignored the warning and carried on, kaba says the attacker did three things. They captured your password. They opened a second connection to the real server and watched every command you typed. And they opened a third to try to install a backdoor on that server.
That last step matters. The installer was a base64-encoded Perl command, and it matched how the Ebury backdoor was planted on a relay operator’s own server. Ebury hides inside OpenSSH and steals credentials. ESET estimated in 2024 that it had infected around 400,000 Linux servers since 2009.
Only a few of the Tor exit relays served a fake host key. Kaba found about a dozen doing that. The other 300 or so redirected traffic through the same servers without changing the key. So redirection itself became the giveaway, and it is how he identified the full set.
Who was exposed
The window was short, though. The Tor exit relays began intercepting on 2 October, and by 5 October none were left in the list of relays that Tor clients use. To lose a password, a user had to connect to an SSH server over Tor, land on one of those exits, accept an unfamiliar host key and then type a password. Nobody has published a count of victims.
If that sounds like something your team did that week, treat the password as stolen. Change it, then check the server for signs of Ebury.
How the attackers got in
One affected relay family has published a post-mortem. Two of its servers carried Ebury 1.8.3. The operator wrote that one password was used for SSH login, for sudo and for a backup passphrase, and that it sat in plain text on both servers. SSH password login was also left on for the internet-facing management server.
The attacker logged in on 28 August with that password at the first attempt, according to the same account, and reached root within five minutes. The attacker also truncated some logs and switched off login logging on one server. Ebury’s own backdoor logins leave no login records at all.
How the attacker learned the password in the first place is unknown. Marc-Etienne M. Léveillé, who wrote ESET’s 2024 Ebury report, suggested a login from a host already infected with Ebury, or a compromised hosting provider. He added that stolen credentials sit in memory until the attacker collects them, and that Ebury 1.8.3 has been around since at least June 2026.
What this means for your business
Few UK firms run SSH over Tor exit relays, so this is not a mass-exposure story. The lessons are broader.
- Switch off SSH password login on anything reachable from the internet. Use keys.
- Never click through a changed host key warning. Stop and ask why it changed.
- Do not reuse one password across SSH, sudo and backups, and never leave it in a script. Our guide to default credentials covers the wider habit.
- Keep logs somewhere an intruder on the server cannot edit them.
The Tor Project’s advice to relay operators applies to any server you care about. Audit configuration files for changes you did not make. Look for NAT rules that redirect port 22. If you suspect a compromise, rebuild the server rather than cleaning it, and rotate every credential that lived on it.
A penetration test is a good way to find the reused passwords and open password logins that made this possible. Aardwolf Security can scope a test around your administrative access, so get in touch if you want a second pair of eyes.
Sources
- kaba, “How I got over 300 Tor exit nodes removed”
- Tor Project network health notice to relay operators, 5 October 2026
- Relay operator post-mortem on the Ebury 1.8.3 compromise, tor-relays list
- Marc-Etienne M. Léveillé’s reply on Ebury, tor-relays list
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
