Over 300 Tor exit relays were hijacked to intercept SSH logins

More than 300 Tor exit relays were redirected to interception servers in early October, creating a narrow but serious risk for people who used password-based SSH logins through the network. The incident was uncovered by researcher kaba and documented by The Hacker News, the Tor Project and a separate analysis of public relay-directory data.¹²³

How the Tor attack worked

Tor exit relays are the final hop before traffic leaves the Tor network for its destination. In this case, the affected machines had their relay policies changed so they would accept SSH traffic on port 22. Some relays had not previously been exits at all, while others had been altered to allow ports their operators had not intended to expose.¹

Kaba scanned roughly 3,000 Tor exits on 2 October and found 333 redirecting SSH connections to the same 12 interception servers. The directory-data analysis found 377 relays operated by 59 operators that switched to the attacker's policy between 1 and 4 October, although it stressed that a policy match alone is not proof that every machine was compromised.²³

A connection routed through one of the relays could be sent to an interception server instead of the intended SSH host. The interceptor presented its own host key. Users who already knew the genuine key would see an OpenSSH warning; first-time users would see the normal prompt asking whether to accept the new key. Anyone who accepted the unfamiliar key and then typed a password could have handed that password to the attacker.¹

The attack did not work in the same way against ordinary SSH public-key authentication. A key-based login signs data unique to the session, so a signature created for the interceptor cannot simply be replayed against the real server. Passwords, however, are supplied inside the encrypted connection and could be read by the endpoint that received them.¹

The relay compromise behind the redirection

The Tor Project began flagging suspicious relays on 4 October. Directory authorities added BadExit and MiddleOnly flags, and by 5 October no relay carrying the attacker's policy remained in the consensus list used by Tor clients.¹³

The clearest account of how at least part of the operation began came from Zimmer, operator of the Quetzalcoatl relay family. He said two servers had been infected with Ebury, an OpenSSH backdoor and credential stealer. The initial compromise used a reused password on an internet-facing management server, where password authentication remained enabled; the same password was also used for sudo and a backup passphrase.¹

The incident shows why a relay disappearing from the public consensus is not the same as proving every affected host is clean. Zimmer said Ebury survived a reboot, and the Tor Project's guidance calls for operators to preserve evidence, take compromised relays offline, reinstall rather than attempting a superficial cleanup, rotate credentials and generate new relay identities.¹

Who needs to act

The exposure window was limited. A user generally needed to connect to an SSH server over Tor between 1 October and the afternoon of 5 October, land on an affected exit, have the session intercepted, accept the replacement host key and authenticate with a password. There is no published count of victims.¹

Anyone who accepted an unfamiliar or changed SSH host key during that period should treat the password as compromised, change it from a trusted device and inspect the server for signs of intrusion. Operators should also review relay policies, torrc files, NAT rules, unknown processes, new users, unexpected SSH keys, cron jobs and systemd units. The Tor Project and relay operators have published indicators for the Ebury implant, but a clean package check alone may not be enough.¹

Our opinion

This was not a reason to abandon Tor, but it is a sharp reminder that anonymity networks do not remove the need for endpoint security. The most important practical lesson is familiar: use SSH keys rather than passwords, verify host keys instead of clicking through warnings, and treat a surprising connection as an incident rather than an inconvenience. For relay operators, monitoring policy changes matters just as much as monitoring whether a server is reachable.

The incident also underlines the difference between a network-level warning and a confirmed victim list. The public data supports a clear account of what the relays were configured to do, while the number of compromised operators and intercepted logins remains unknown. That distinction is worth preserving as investigations continue.

Hero image: photo by panumas nikhomkhai on Pexels, used as a generic server-infrastructure illustration rather than a depiction of the incident.⁴