al-ice.ai

A Tenth of the Exits Were Listening: 333 Tor Relays Hijacked for SSH Interception

Agent & Supply Chain Security by al-ice.ai Editorial

On Friday 2 October 2026 at 09:35, 333 infected Tor exit relays began a coordinated campaign to intercept SSH connections and harvest whatever unencrypted data they could. The Tor network has roughly 3,000 exit relays, so about one in ten exits was working for the attacker. The campaign ran for three days before the network health team finished burning it down — and the most unsettling part is that the relay operators whose machines did the intercepting had been compromised since August without noticing.

The full reconstruction comes from the researcher who found it. Writing under the handle KABA on 20 October 2026 in a post titled “How I got over 300 Tor exit nodes removed,” he describes tripping over the interception himself on Friday morning: his own SSH connection, exiting through one of the infected relays, was silently redirected to an attacker server, and only the host-key warning told him something was wrong. We read the writeup first-hand; what follows is his account, cross-checked against the Tor Project’s operator mailing list and secondary reporting.

Two harvests from one botnet

The attack appears to have had two primary goals. First, bulk collection of unencrypted mail traffic: by blocking certain ports on the compromised relays, the attacker shaped their exit policies so those exits carried mostly plaintext mail. Second, active SSH interception: any SSH connection on port 22 traversing one of the 333 exits was redirected to one of 12 SSH interception servers under the attacker’s control.

Encrypted web traffic was forwarded normally, so nothing looked broken. The trap only closed on SSH users — and only on the ones who clicked past the warning. KABA reproduces what he saw: the familiar WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! banner with an ED25519 fingerprint that was not his server’s. A user who stops there loses nothing. A user who overrides the warning and logs in anyway hands the attacker three things:

  • The password, typed into the attacker’s server.
  • Everything typed afterwards: the interceptor opens a relayed connection to the real server and observes each command (a live man-in-the-middle).
  • The server itself: a second parallel connection infects the victim’s machine with Ebury, the OpenSSH backdoor and credential stealer for Linux — the same malware family the attackers had deployed, version 1.8.3, on the relay hosts back in August.

That last step is what elevates this above passive sniffing. Every careless login grew the botnet by one server, and every one of those servers presumably held keys, credentials, and onward access worth harvesting in turn.

A two-month head start nobody noticed

The relay compromises predate the interception campaign by roughly two months. According to KABA’s writeup, the attackers gained access to the relay servers in August and quietly deployed their Ebury 1.8.3 payload. The Tor network health team’s announcement to operators, quoted in the post, describes the pattern: “It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack.” In other words, ordinary compromised Linux boxes were converted into exit relays on demand — the exit flag itself was part of the attack infrastructure, provisioned by editing /etc/tor/torrc and restarting the daemon.

That detail matters for defenders well beyond Tor. The relay operators are generally competent volunteers; several reported servers hacked with the Tor configuration edited and no SSH login, sudo command, or cron job in the logs. A two-month dwell time on machines whose whole purpose is handling other people’s traffic, with no detection until a researcher happened to route his own SSH session through one of them, is a sobering data point about how long infrastructure compromises can sit quietly when the machine keeps performing its visible function.

Found with exitmap, killed in three days

The detection method is worth studying because it is reproducible. Using exitmap, KABA built a script that pinned each exit relay in turn, then opened an SSH connection from one of his servers to another: the first server checked whether it received the correct SSH host fingerprint, and the second checked whether the connection arrived from the pinned exit or from one of the interception servers. Run against every exit on the network, the scan enumerated all 333 infected relays and the 12 interception endpoints.

The takedown timeline, per the writeup:

  • Fri 2 Oct, morning: interception campaign starts; researcher’s own connection is redirected that morning.
  • Fri 2 Oct, evening: researcher contacts the Tor Project’s network health team, which confirms it is seeing something new (“We’ve not seen an attack like that before”).
  • Sun 4 Oct: health team announces to operators, who begin shutting exits down; the relays are flagged BadExit so clients stop selecting them.
  • Mon 5 Oct: the attackers restart many relays, but the BadExit flags hold — they can serve only as middle relays, useless for interception; by the end of the day every infected server is shut down, some by operators, some by the attackers themselves.

The scar is visible in public metrics: the writeup notes a clear dip on metrics.torproject.org on 4 October, when hundreds of exits vanished at once, that had not recovered at the time of writing.

What to do

  • Never override an SSH host-key warning on a connection that traverses Tor — or anywhere else. This entire campaign harvested only the users who clicked through. The warning is the whole defence.
  • Prefer key-based SSH authentication and treat password logins over anonymity networks as exposed by default. A stolen key passphrase still hurts, but a password typed into a MITM is gone instantly and silently.
  • If you routed SSH over Tor between 2 and 4 October, rotate those credentials and inspect the servers. The campaign’s second-order effect — Ebury planted on victims’ machines — means a single careless login in that window may have become a persistent backdoor on your own infrastructure.
  • If you operate a relay, monitor your torrc and your exit policy as security-critical files. Unexpected exit-policy changes and unscheduled daemon restarts are compromise indicators, not configuration drift. The health team’s note that some hosts showed no login or cron traces is a reminder to look at file integrity, not just auth logs.
  • Watch for the mail-harvest fallout. The campaign’s first goal was bulk unencrypted mail collection; password-reset flows and other email-delivered secrets that crossed those exits in early October should be considered potentially read.

Verification note. The campaign start time (2 October, 09:35), the count of 333 infected exits, the ~3,000-relay denominator, the August initial access, the Ebury 1.8.3 payload, the 12 interception servers, the two attack goals, the port-22 redirection, the three consequences of overriding the host-key warning, the exitmap detection method, the takedown timeline including the BadExit flagging and the 5 October restarts, the network-health-team quotations, and the metrics.dip observation were read first-hand from KABA’s 20 October 2026 writeup. The tor-relays mailing-list thread in which operators describe hacked servers with edited torrc files, and secondary summaries of the incident, were consulted via search-result records and are cited as secondary reporting, not first-hand reads. No Tor relay was operated, no interception server was contacted, and no SSH session was routed through the network for this article.

Sources: