How I got over 300 Tor exit nodes removed

On October 2, 333 Tor exit relays began intercepting traffic after being infected with Ebury 1.8.3, representing roughly 10% of all exits. Operators had gained control of those Linux hosts earlier and reconfigured many into exits; they filtered ports to siphon unencrypted mail and redirected SSH (port 22) sessions through a set of 12 interception servers. Victims saw changed SSH host keys; if they logged in anyway, attackers captured passwords, performed man‑in‑the‑middle observation of commands, and used captured access to install Ebury on target servers. The Tor Network Health Team flagged the relays BadExit on October 4 and coordinated shutdowns; attackers attempted restarts but the relays could only function as non‑exits after being marked, producing a visible dip in exit counts.

Detection relied on active probing: each exit was pinned with exitmap and an SSH session was launched between two controlled servers to verify the expected host fingerprint and the origin of the connection. Scanning ~3,000 exits found about a dozen serving forged fingerprints and more than 300 redirecting through the interception infrastructure. A honeypot interaction revealed the MITM used Paramiko and a base64‑encoded Perl install pathway for Ebury. The initial compromise vector remains unknown (one hypothesis points at a hosting provider breach) and attribution is unresolved, though the tooling and data collection indicate financially motivated actors. Practical takeaways: disable password auth, use SSH keys or hardware tokens, and treat relays as high‑security production servers.