Skip to content
Hacker Posts

Attackers hijack 300+ Tor exit relays to intercept SSH

A campaign rewrote the exit policy on hundreds of Tor relays to redirect SSH to 12 interception servers and capture passwords. Compromised hosts ran the Ebury backdoor.

Published 3 min read
threat-inteltoreburyssh

Between 1 and 5 October 2026, attackers rewrote the exit policy on hundreds of Tor exit relays so that SSH traffic leaving them was redirected to 12 interception servers that captured passwords. The relays carried the Ebury OpenSSH backdoor. If you SSH'd to a server over Tor in that window and accepted an unfamiliar or changed host key, treat any password you typed as compromised.

What happened

Researcher kaba scanned Tor's roughly 3,000 exits on 2 October and found 333 redirecting port 22 to the same set of interception servers (writeup). A separate analysis of Tor directory data counted 377 relays run by 59 operators that switched to the attacker's exit policy between 1 and 4 October — "a policy match, not proof of compromise." At the 4 October peak, those relays made up 7.46% of Tor's exit capacity by consensus weight. The Tor Project network health team flagged the relays on 4 October and voted them BadExit / MiddleOnly; by 17:00 UTC on 5 October none with the policy remained in the consensus.

How the interception worked

Attackers with access to the Linux hosts edited torrc to allow port 22, turning relays that previously blocked SSH into SSH exits. SSH sessions exiting those relays were sent to an interceptor that presented its own host key. A user who had connected before saw a changed-key warning; a first-time user got the normal accept-key prompt. Accept the key and type a password, and the interceptor logged it, then relayed the session to the real server so it still worked. A key-based login could not be relayed this way — the signature is bound to a per-session identifier.

Zimmer, operator of the largest affected relay family (Quetzalcoatl), published a post-mortem to the tor-relays list on 7 October. Two of his servers ran Ebury 1.8.3; the attacker had logged into the management server on 28 August with a reused operator password. His stated root cause: "one password reused for SSH login, sudo and the backup passphrase," stored in plaintext, with password authentication left on. How the other 58 operators were compromised is unresolved. ESET's Marc-Etienne Léveillé, who co-authored the firm's Ebury research, posted an updated detection script covering 1.8.3.

Indicators from Zimmer's post-mortem, verbatim:

File:        /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 (setuid, owned by no package)
Symlink:     libkeyutils.so.1 -> that file
UNIX socket: @event-0YsOG9WSOE (abstract)
Process:     fake /sbin/rsyslogd inside the ssh.service cgroup
IP:          185.225.226[.]62
Host key:    ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E

Action checklist

  1. If you accepted an unfamiliar or changed SSH host key over Tor between 1 and 5 October, rotate any password typed in that session and check the destination server for the Ebury indicators above.
  2. Disable SSH password authentication on internet-facing hosts; use key-based logins only.
  3. Stop reusing one secret across SSH, sudo and backup encryption.
  4. Relay operators: review torrc for ExitPolicy lines you did not set, check Relay Search for unexpected Exit flags, and run Léveillé's updated Ebury script. A clean host check does not clear the implant — Zimmer's servers showed none of the usual host signs.

Context

This is the same playbook ESET documented in 2024, when it estimated Ebury had touched 400,000 servers over 15 years and specifically redirected SSH inside data centers to harvest credentials. The new wrinkle is scale against Tor: a single reused password on one operator's jump host put 7% of the network's exit capacity into an interception posture for four days.

Related stories