Threat intel

In early October attackers took control of more than 300 Tor exit relays, the servers where Tor traffic leaves the network for its destination, and used them to send SSH (Secure Shell) connections to servers of their own. Anyone who logged in to an SSH server over Tor between October 1 and the afternoon of October 5, accepted the wrong host key and typed a password should treat that password as stolen. Logins with SSH keys could not be replayed against the real server.

The Tor Project flagged the relays on October 4, and none were left in the network by 17:00 UTC on October 5. It also concerns teams that never use Tor: the relays were ordinary Linux servers, two of them ran an Ebury SSH backdoor build that ESET's public detection script misses, and how most hosts were entered is unknown.

How it works

A Tor client only exits through a relay whose exit policy, the list of allowed ports in the relay's torrc file, allows the destination port. The attackers rewrote that policy on hosts they already controlled. An analysis of public Tor directory data posted to the tor-relays list found the change opened port 22 (SSH) on 342 relays and turned 24 non-exits into exits. It also closed encrypted mail ports 993 and 995 while, on most relays, leaving plaintext POP3 and IMAP open.

SSH connections through these exits went to one of 12 interception servers, which answered with their own host key, the key a server uses to prove its identity. Returning users got OpenSSH's "REMOTE HOST IDENTIFICATION HAS CHANGED" warning. First-time users saw only the normal prompt to accept a new key.

SSH encrypts a password only as far as the server at the other end, which here was the interceptor. The interceptor then logged in to the real server, so the session worked and every command could be watched. In a honeypot, the researcher who found the attack, who publishes as kaba, saw it open a second login, run id -u and sudo -n true, then a base64-encoded Perl installer of the same form that put Ebury on a relay operator's server.

Key logins resist this. The client's signature covers the session identifier, unique to each connection, so a signature made for the interceptor's session is useless against the real server.

What the attackers did, and where the counts differ

The relay counts differ because the sources measure different things. Kaba scanned all of Tor's roughly 3,000 exits on October 2 and found 333 redirecting SSH to the same 12 servers. The directory-data analysis counts 377 relays from 59 operators that took the attacker's policy between October 1 and 4, "a policy match, not proof of compromise", 342 of them with port 22 newly opened. Tor Metrics shows about 370 fewer relays with the Exit flag between October 3 and 5.

Start times differ too. The first relays switched at 14:44 UTC on October 1; kaba dates the coordinated interception to 09:35 on October 2, when the largest family, Quetzalcoatl, switched. At 01:00 UTC on October 4 the affected relays held 7.46% of usable exit capacity by consensus weight. The BadExit flag, which stops clients using a relay as an exit, reached the consensus at 21:00 that day.

Quetzalcoatl's operator published a post-mortem on October 7. On August 28 the attacker logged in to the family's management server from 185.225.226[.]62 with the operator's password on the first try, had root within five minutes, and installed Ebury 1.8.3, an OpenSSH backdoor and credential stealer, there and on a relay server an hour later. That password was reused for SSH, sudo and backups and stored in plaintext; where the attacker got it is unknown.

Some reports say Ebury 1.8.3 went onto all the relay servers in August; the primary sources confirm it only on those two. For the other 58 operators, initial access is unknown. Of their relays, 71 of 101 at FranTech (BuyVM) switched policy against 13 of 9,054 elsewhere, which hints at the hosting provider without proving it. Nobody has attributed the campaign or counted victims.

What to do

Ask who on your team uses SSH over Tor, through torsocks or a ProxyCommand. For anyone who did between October 1 and 5, check ~/.ssh/known_hosts. Kaba's interceptor used the ED25519 key SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E (ssh-keygen -lf ~/.ssh/known_hosts | grep 6baCZCPsl), but other interceptors may have used other keys, so compare each saved key with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub on the real server. If a password went in after a mismatched key, change it wherever it was reused and check that server for Ebury.

Stop trusting keys on first use for remote access:

• Set StrictHostKeyChecking yes for Tor and other untrusted paths, and ship known host keys to clients through configuration management.
• Use OpenSSH host certificates: sign host keys with a certificate authority (CA), set HostCertificate in sshd_config, and add one @cert-authority *.example.com ssh-ed25519 ... line to clients' known_hosts.
• Publish SSHFP records (generate them with ssh-keygen -r <hostname>) and set VerifyHostKeyDNS yes. This only helps if the zone is signed with DNSSEC and the resolver validates it.

Turn off password login on servers reachable from the internet: PasswordAuthentication no and KbdInteractiveAuthentication no. Then check the setting in force with sshd -T | grep -Ei 'passwordauth|kbdinteractive', because sshd uses the first value it reads. On one of the hijacked hosts, a PermitRootLogin yes left near the top of the file by the VPS image silently beat the PermitRootLogin no added later.

In the auth logs (/var/log/auth.log, /var/log/secure, or journalctl -u ssh) look for Accepted password lines from October 1 to 5. The interceptor logged in from its own address, so the pattern is a password login from an unfamiliar host, then a second session from it running id, sudo -n true or base64 -d | perl. October's Tor exit addresses are in the CollecTor archive (exit-list-2026-10.tar.xz).

Relay operators, and anyone whose password may have been taken, should check for this Ebury build from a rescue system or disk image where possible, or log in with a key, never a password. Signs from the post-mortem:

1. A setuid file /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 owned by no package, with libkeyutils.so.1 pointing to it. Find it with find / -xdev -name 'libkeyutils*' -perm -4000. Package checks such as dpkg -V and debsums pass, and the hash differs on each server.
2. The abstract socket @event-0YsOG9WSOE in /proc/net/unix.
3. A fake /sbin/rsyslogd (earlier systemd-udevd or arpd) inside the ssh.service cgroup.
4. Sudo log entries running base64 -d | perl, and apt history entries with no Requested-By: line.

ESET's detect_ebury.sh does not flag version 1.8.3; Marc-Etienne Léveillé, author of ESET's 2024 Ebury report, has posted an updated copy. If you find it, rebuild the host rather than clean it, and rotate every SSH key, password and relay identity key it held. The Tor Project's notice also asks operators to check torrc and included files for changed ExitPolicy, ExitRelay, MyFamily, ContactInfo or Nickname lines, and for NAT rules on port 22 (nft list ruleset, iptables -t nat -S).

The wider lesson

The Tor Project's network health team spotted the attack by watching the exit policies the relays published. On the Quetzalcoatl server examined in the post-mortem, the logs showed no login, sudo command or cron job behind the edit, because Ebury's backdoor logins leave no record. Comparing what a host publishes with what you deployed, and alerting on the difference, works for any internet-facing server.

Our safeguarding and hardening work covers SSH host key trust and password login settings, and security operations can hunt for the Ebury signs above. If you want to know whether any of your servers were affected, open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: kaba.cx, Tor Project notice to relay operators, Quetzalcoatl post-mortem, directory-data analysis, Marc-Etienne Léveillé on the tor-relays list, The Hacker News, GBHackers, Cyber Security News, Covert Access Team.