Tor Removes Malicious Exit Relays That Redirected SSH Logins
Attackers controlled more than 300 Tor exit relays in early October and used them to redirect SSH connections to 12 interception servers designed to capture passwords. A scan by researcher kaba found 333 relays redirecting SSH on October 2, while an analysis of public Tor directory data identified 377 relays operated by 59 operators that adopted the malicious exit policy between October 1 and 4.
At the October 4 peak, relays using that policy accounted for 7.46% of Tor’s exit capacity by consensus weight. The Tor Project began flagging the affected relays that day, and by 17:00 UTC on October 5 none remained in the consensus used by Tor clients.
How the SSH interception worked
Tor exit relays are the final hop in a circuit and connect to the destination service. The attackers altered relay torrc configurations to allow port 22 on 342 relays that had previously blocked SSH. They also converted 24 relays that had not been exits into exits. At the same time, the changed policies closed encrypted IMAPS and POP3S ports and, on most affected relays, enabled plaintext-capable POP3 and IMAP.
When a user’s SSH connection selected one of these exits, it could be sent to an interception server rather than the intended host. The server presented its own host key. Existing users should have received an OpenSSH warning that the remote host identification had changed, while first-time users saw the standard prompt to accept a key. A user who accepted the key and logged in with a password supplied that password to the interceptor.
The interception server could then connect to the genuine server, making the session appear to work while allowing commands to be observed. Key-based SSH logins could not be relayed in the same way because each client signature is bound to a session-specific identifier. The exposure window was limited to password logins over Tor from October 1 through the afternoon of October 5 that landed on an affected exit, were redirected, and accepted the host key.
Detection, removal and Ebury findings
Kaba reported the findings after seeing a changed-key warning and scanning Tor exits with exitmap. The Tor Project’s network health team also detected the policy changes. Directory authorities applied the BadExit and MiddleOnly flags on October 4; BadExit instructs clients not to use a relay as an exit. The authorities subsequently rejected affected relays from the network.
Zimmer, operator of the Quetzalcoatl relay family, found Ebury version 1.8.3 on two servers: a Contabo management server and a FranTech VPS. He said an attacker logged in to the management server on August 28 using a reused operator password, obtained root access within five minutes, and installed Ebury before reaching the second host. Ebury is an OpenSSH backdoor and credential stealer that can leave backdoor logins without records.
The wider initial-access route remains unresolved. Directory data showed that 71 of 101 relays hosted on FranTech Solutions switched to the malicious policy, compared with 13 of 9,054 elsewhere. That pattern is not proof of a hosting-provider compromise, and the data alone cannot establish how every affected host was accessed.
What administrators should do
Anyone who accepted an unfamiliar or changed SSH host key while connecting over Tor during the incident window should regard the password entered as stolen, rotate it, and inspect the destination server for compromise. The Tor Project advises relay operators to review unexpected exit policies and configuration changes, as well as port-22 NAT rules, unfamiliar processes, new users, SSH keys, cron jobs, systemd units and package-check failures.
Zimmer warned that a clean live-host check may not exclude Ebury. The Tor Project recommends taking a compromised relay offline, preserving disk and logs, reinstalling rather than cleaning the system, generating a new relay identity and treating credentials on the host as compromised. For businesses, the incident reinforces the need to disable internet-facing SSH password authentication, avoid credential reuse, and treat unexpected host-key changes as a stop signal rather than a routine prompt.