Ebury-infected Tor exit relays intercepted SSH logins across a tenth of the network

What happened

On October 2, 2026, at 09:35, 333 Tor exit relays began a coordinated campaign to intercept SSH connections and collect unencrypted traffic, according to a writeup by the researcher who uncovered the scheme, published on their blog at kaba.cx and later surfaced on Hacker News. Tor runs only about 3,000 exit relays in total, so close to a tenth of the network's exit capacity sat under a single attacker's control.

The compromise predated the attack. According to the post, the servers had been breached in August, two months earlier, and quietly seeded with Ebury 1.8.3, a long-lived OpenSSH backdoor and credential stealer for Linux.

How the interception worked

The writeup describes two goals: gathering as much unencrypted mail traffic as possible, and man-in-the-middling SSH sessions. The mail half was handled through relay configuration — certain ports were blocked so the infected exits would carry only unencrypted mail protocols, a side documented separately by a victim who is a veteran relay operator.

The SSH half worked by redirection. Encrypted web traffic passed through normally, but any connection to port 22 was silently rerouted to one of twelve interception servers. Because that swaps the host key the client sees, users who check fingerprints were greeted with the standard "REMOTE HOST IDENTIFICATION HAS CHANGED" warning — exactly what the author hit on Friday morning. Anyone who ignored it and logged in with a password handed the attacker three things at once: the password itself, a live relayed view of every command typed into the session, and a second connection used to plant Ebury on the victim's server.

A three-day takedown

The author alerted the Tor Project's network health team on Friday evening; as quoted in the post, the team said it had "not seen an attack like that before." Interception began October 2. On Sunday, October 4, the health team notified operators, who began shutting relays down, and the infected exits were flagged BadExit so clients would no longer route traffic out through them. On Monday, October 5, the attackers restarted many machines, but the flag confined them to middle-relay duty; by the end of the day every compromised server was offline, shut down partly by operators and partly by the attackers themselves. The author suspects the Friday launch was timed on the hope that nobody would want to spoil a weekend responding.

The health team's announcement, quoted in the writeup, describes the pattern: the attacker compromises Linux hosts and, on machines running non-exit relays, edits the torrc file to turn them into exits capable of the SSH attack. Tor's public metrics show the resulting dip in exit capacity on October 4, and the author notes it had not recovered.

How the infected relays were identified

The author built a scan on top of exitmap that pinned each of the roughly 3,000 exit relays in turn and opened an SSH connection from one controlled server to another. One end verified the host key received; the other recorded whether the connection arrived from the pinned exit or from one of the interception servers. Around a dozen relays served a fake fingerprint outright, and more than 300 simply redirected — enough on its own to confirm infection.

A honeypot built with sshesame filled in the tooling: the interception layer connects using paramiko, a Python SSH library, and tries to install Ebury via Perl, first probing the user's privileges and whether sudo is available, then executing a base64-encoded command.

Open questions

The biggest unknown is initial access. One theory discussed on the Tor Project mailing lists holds that a hosting provider was breached, but the author stresses it is unproven. Attribution is equally open; the use of Ebury and the appetite for bulk plaintext data suggest a financially motivated crime group, though this too is labelled speculation. Marc-Etienne M. Léveillé, quoted in the writeup, points out that Ebury infected some 400,000 servers between 2009 and 2023, which implies other compromised Tor relays probably remain on the network.

Why it matters

For Tor users this turned an abstract risk into a concrete number: at peak, roughly one circuit in ten exited through attacker-controlled hardware. The saving grace is that the attack cannot forge host keys, so fingerprint verification caught it — and sessions authenticated with SSH keys rather than passwords had no credentials to steal. For operators, the advice quoted from the thread is blunt: relays and bridges should be run as highly targeted production machines, not set-and-forget hobbyist boxes. With exit capacity still depressed, the author's closing ask is for more volunteers to run relays.