The host key warning on 333 hijacked Tor relays

On Friday, October 2 at 09:35, 333 infected Tor exit relays began a coordinated campaign to intercept SSH connections and gather as much unencrypted data as they could. Tor runs around 3,000 exit relays, so roughly 10% of them were under the attackers’ control.

The foothold was two months old. Whoever ran this had gotten onto the servers back in August, installed Ebury 1.8.3, an OpenSSH backdoor and credential stealer for Linux, and sat on the access until October.

The campaign had two aims: collect as much unencrypted mail traffic as possible, and intercept SSH connections. Blocking certain ports left the exit nodes handling only unencrypted mail.

The SSH interception

When a circuit happened to exit through an infected relay, ordinary encrypted web traffic passed through untouched. An SSH connection on port 22 did not. It was rerouted to one of 12 interception servers. The researcher who found this hit exactly that on Friday morning and got the standard host key warning:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
The fingerprint for the ED25519 key sent by the remote host is
SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.

Stopping at the warning cost nothing. Proceeding past it, typing the password and continuing, let the attacker do three things: record the password, open its own session to the real server and watch every command the user ran, and open a second session to install Ebury on the target.

Finding all of them

Detection ran on exitmap. The script pinned one exit relay at a time, then opened an SSH connection from one of the researcher’s servers (A) to another (B). Server A checked whether B returned the correct SSH fingerprint; server B checked whether the incoming connection arrived from the pinned exit or from one of the 12 interception servers. Across all 3,000 or so exits, about a dozen served a forged fingerprint and over 300 forwarded the connection through the interception servers without touching the fingerprint. The redirect by itself was enough to flag the relay as infected.

A honeypot filled in the method. Running sshesame and letting the MITM log into it showed the client side driven by paramiko, Python’s SSH library, and an Ebury install attempt written in Perl. The payload read its privileges first, checking id -u and whether sudo would run without a password, before piping a base64-decoded blob into perl:

echo "U=$(id -u) S=$(command -v sudo >/dev/null 2>&1 && (sudo -n true 2>/dev/null && echo nopass || echo maybe) || echo none)"
sudo bash -c 'echo <base64> | base64 -d | perl'

The takedown

The researcher reported the findings to the Tor Project’s network health team on Friday evening. Their response: “We’ve not seen an attack like that before.” From there it moved fast.

• Oct 2: interception starts.
• Oct 4: the health team notifies operators, who begin shutting exits down; the relays are marked BadExit, so clients stop exiting through them.
• Oct 5: the attackers restart many of the relays, but since they are already flagged they can only serve as middle relays.
• Oct 5: every infected server is down, taken offline partly by operators and partly by the attackers themselves.

The drop in exit capacity visible on metrics.torproject.org from October 4 has not recovered.

The health team described the pattern plainly: the attacker gets onto Linux hosts, and where a host is already running as a non-exit relay, edits its torrc to convert it into an exit so it can run the SSH attack.

What’s still unknown, and what to do

How the attacker reached so many servers in the first place is unresolved. One theory in the Tor mailing list discussion is that the hosting provider itself was compromised, but no one has confirmed it. The use of Ebury and the bulk harvesting of cleartext point toward a financially motivated group, though that is inference rather than attribution. Marc-Etienne M. Léveillé noted that 400,000 servers had Ebury between 2009 and 2023 and that other compromised relays most likely exist.

For anyone running a relay, George’s operating assumption from the mailing list is the right one: treat relays and bridges as highly targeted production machines. Disable password authentication, use keys, and hardware-backed keys where you can manage them.

For anyone using SSH over Tor, the host key change warning was what distinguished a normal session from a stolen credential and a backdoored server. Clients that honored it walked away clean; the ones that clicked through lost their password and their host.