A researcher scanning Tor's exit relays found 333 of them quietly redirecting SSH connections to a dozen servers under his control. Password logins made through those exits between 1 and 5 October were captured in plain text.

What happened

The researcher, who publishes as kaba, scanned roughly 3,000 Tor exits on 2 October and found 333 pointing SSH traffic at 12 interception servers. Public Tor directory data shows 377 relays run by 59 operators switched to the attacker's exit policy between 1 and 4 October. At the peak on 4 October those relays carried 7.46% of Tor's exit capacity.

The attackers were editing the torrc configuration on compromised Linux hosts, turning ordinary relays and non-exits into exits that allowed port 22. On most of them the encrypted mail ports were closed and the plaintext ones opened. The Tor Project began flagging the relays on 4 October, and by 5 October none remained in the consensus.

When an exit intercepted the connection it presented its own host key. Anyone who accepted that key and then typed a password handed the password to the interceptor, which relayed the session to the real server so the login still worked. Every command could then be watched, and the stolen password reused separately to check for sudo and run a base64-encoded Perl installer. In kaba's honeypot that installer took the same form as the one used to plant Ebury, a backdoor that hides inside OpenSSH.

Who is affected

Exposure required a specific sequence: an SSH connection made over Tor between 1 October and the afternoon of 5 October, landing on one of the hijacked exits, getting intercepted, accepting the host key offered, and logging in with a password.

• Administrators and developers who reach servers through Tor, including jump hosts and VPS instances
• Any host where SSH still accepts password authentication
• Servers whose administrators clicked through an OpenSSH remote host identification warning in early October

Key-based logins could not be relayed this way: the client's signature covers a session identifier that differs on the interceptor's session, so a captured signature is useless against the real server.

What to do now

If anyone on your team accepted an unfamiliar or changed host key over Tor in that window, treat the password they typed as stolen and treat the server as suspect.

• Check known_hosts for an ED25519 key with fingerprint SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, seen on one of the interception servers
• Change the affected password, then change every credential that was stored on that host
• Turn off password authentication and require keys, with a passphrase on the key itself
• Hunt for Ebury signs on the host from a rescue system or offline image, logging in with a key only, never a password
• If Ebury is found, reinstall the host rather than cleaning it, and regenerate its keys

What this means for South African businesses

Few South African SMEs route server administration through Tor, so direct casualties here are likely to be small and concentrated among hosting and development teams. The more useful lesson is the mechanism: host-key prompts and password logins are the two things that made this work, and both are still common on the Linux servers behind local web shops and Odoo deployments. An interception does not need Tor to succeed if a server still accepts a typed password from an untrusted network.

The full technical write-up and the Tor Project's guidance for relay operators are covered in this report.