A researcher publishing as kaba reported on October 20 finding 333 Tor exit relays redirecting SSH connections in an October 2 scan. The attack stole passwords when users accepted an impostor server's identity.
Tor's network health team had already warned operators on October 5 that hacked Linux hosts were intercepting SSH traffic. It said directory authorities were rejecting affected relays from the network. The later researcher account explains the interception mechanism, while an operator's post-mortem documents a backdoor that survived routine checks. Neither account establishes how every affected host was breached.
What the scan actually found
Kaba used exitmap to connect between two controlled servers through each exit, checking the host fingerprint and connection origin. Traffic crossed 12 interception servers. Around a dozen exits returned fake fingerprints. More than 300 redirected traffic without changing the key during the scan.
The count doesn't establish how many passwords were stolen. Kaba's honeypot investigation found attempts to install the Ebury OpenSSH backdoor. The interceptor could use a stolen password to connect onward to the intended server and observe commands.
SSH encryption cannot protect a password from the server you hand it to. RFC 4252 defines password authentication inside the protected connection and assumes the server has already been authenticated. Accepting an attacker's host key defeats that assumption.
Public-key authentication has a different property. The same protocol specification binds its authentication signature to a unique session identifier. Our reading is that a signature made for an interceptor's session cannot simply authenticate a separate connection to the real server. That protection doesn't make a host with an installed backdoor trustworthy.
A clean package check missed the implant
In an October 7 post-mortem, Quetzalcoatl relay operator Zimmer reported Ebury 1.8.3 on two servers. The management server had allowed password logins, and one password was reused for SSH, sudo and a backup containing sensitive keys. Zimmer's logs put the initial management-server intrusion on August 28. Where the attacker obtained that password remained unresolved.
Package checks passed despite the infection. Zimmer reported an added library file and a redirected library symlink, while packaged files retained their expected checksums. Even the SSH daemon, sudo and PAM passed verification. A routine reboot killed other hidden tools, but Ebury returned, according to the same investigation.
For operators, those findings make external checks useful alongside local inspection. Zimmer recommends comparing published relay descriptors with deployed settings, since an attacker can rewrite local configuration. The post also warns against entering passwords on a suspected infected host and recommends investigating from a clean machine or an offline image.
Tor's incident notice asks operators to inspect exit policies they didn't authorize, configuration changes and port-22 redirection rules. For a suspected compromise, its instructions are to disconnect the relay, preserve evidence, reinstall, replace its identity and rotate credentials. Passing a package check alone doesn't resolve the failure Zimmer documented.
How the other hosts were breached remains unresolved. A verified common entry point would help operators assess whether the conditions in Zimmer's account apply to their own infrastructure.