On 2 October, a researcher using the handle KABA noticed something most people dismiss: an SSH session over Tor produced a changed host-key warning.

Rather than click through, they scanned roughly 3,000 Tor exit relays with exitmap, opening SSH connections between two servers they controlled. 333 relays were redirecting those connections to twelve shared interception servers, each presenting a fake host key.

How it was done

The attackers edited the relays' configuration to permit outbound port 22. Many exits deliberately block SSH; the change switched it on for relays that had refused it, so traffic that would previously have been rejected was now accepted and forwarded to the interception servers.

That is a configuration change on somebody else's machine, which means the machines were already theirs. The relays had been compromised earlier and running the Ebury OpenSSH backdoor for roughly two months before the exit policies changed.

So the sequence is the opposite of how it reads in headlines. The compromise was old. The interception was the last step, switched on when enough relays were in hand.

What was actually exposed

Only password logins were at risk, and only between 1 and 5 October. Key-based authentication was never exposed, because an interception server cannot complete a key exchange for a key it does not hold. A password was captured only if the user accepted the unknown or changed host key their own client had warned them about. Both conditions had to be true.

That narrows the affected population to a very specific person: someone who connected over Tor to a server that still accepts passwords, in a five-day window, and clicked past a warning designed to stop exactly this.

The host-key warning is one of the few security controls in wide deployment that works, costs nothing and is universally ignored. Here it was the whole defence, and it held for everybody who read it.

Eleven percent of the exits

333 relays out of roughly 3,000 scanned is about eleven percent of the exit nodes a connection might be routed through. Tor weights exit selection by capacity rather than picking at random, so that is not the same as an eleven percent chance of interception on any given circuit, and nobody has published the weighted figure.

What it does establish is that one operator held a double-digit share of the exits long enough to reconfigure them in a batch. The Ebury infections were in place for two months before the exit policies changed, so the share was accumulated quietly and then switched on at once.

The response

KABA reported the findings to the Tor Project's network health team on a Friday evening. The team notified operators, who began shutting relays down. The relays were flagged BadExit, and by 17:00 UTC on 5 October none running the attacker's policy remained in the network consensus.

Three days from a researcher's warning dialogue to removal from the consensus is a good outcome for a volunteer-run network, and it happened because somebody treated an alert as information rather than an obstacle.

The counts disagree

Reports give 300-plus, 333 and 342 relays. One analysis counts 377 relays run by 59 operators that switched to the attacker's exit policy between 1 and 4 October, and is careful to describe that as a policy match rather than proof of compromise.

The distinction matters: a relay adopting a particular exit policy is evidence, not a verdict, and a count of policy matches will be larger than a count of confirmed interceptions. We have no way to reconcile them here and neither, so far, does anybody else.

What to do

  • Use key-based SSH authentication. It was the difference between affected and unaffected in this incident, and it is the difference in most.
  • Treat host-key warnings as a stop, not a prompt. If you cannot explain why the key changed, do not type the password.
  • Pin known host keys where you can, so a change is an error rather than a question.
  • If you SSHed over Tor with a password between 1 and 5 October and accepted a key warning, rotate that password and look at what the account could reach.
  • If you operate a Tor relay, check for Ebury. The exit-policy change was the symptom; the backdoor was the condition.

What is not established

  • Who did it. No attribution has been offered.
  • How the relays were compromised two months earlier.
  • How many credentials were actually captured.
  • The exact relay count, which varies across every account of this.
  • Whether the same operator is behind the Ebury infections and the exit-policy change, though the overlap is hard to read any other way.
  • Whether anything was done with the credentials.