333 Tor exit relays — according to one researcher’s scan on October 2 — were redirecting SSH traffic to the same 12 interception servers, part of a wider campaign that rewrote exit policies on hundreds of relays between October 1 and October 5 and captured passwords when users accepted forged host keys.
How the attackers changed Tor exits
Between October 1 and October 4, operators or configuration files on hundreds of relays were altered so those relays would carry traffic to port 22. A directory-data analysis posted to the tor-relays mailing list counted 377 relays, run by 59 operators, that switched to the attacker’s exit policy during that window (the analysis calls this a "policy match, not proof of compromise"). In kaba’s active scan of roughly 3,000 exits on October 2, 333 relays were redirecting SSH to the same 12 interception servers.
The attackers rewrote torrc files to permit port 22 on 342 relays that previously blocked it; another 24 hosts that had not been exits became exits. The policy change also closed encrypted mail ports (IMAPS and POP3S) on many relays and opened plaintext-capable ports (POP3 and IMAP) on most of them. At the peak on October 4, relays carrying the attacker's exit policy represented 7.46% of Tor’s exit capacity by consensus weight.
How SSH sessions were intercepted
With port 22 opened, an SSH connection routed through an affected exit could be steered to one of the interception servers. When that happened, the interceptor presented its own host key. A returning-user who already had the real server’s key would see OpenSSH’s warning about a changed host identification; a first-time connector would see the standard prompt to accept a new key. If the user accepted and then supplied a password, the interceptor received it.
In kaba’s October 2 scan about a dozen exits served a fake host key directly; the other ~300 redirected through the same interception servers without altering the key. The interception server used on kaba’s session presented an ED25519 key with fingerprint SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. A key-based SSH login could not be relayed because the SSH protocol ties a client signature to a single session; by contrast, a password travels inside the authenticated session and is visible to the server at the far end.
The interceptor connected onward to the real server so the interactive session worked; commands could be watched, and operators of the interception servers could separately log in with a stolen password to check for sudo and execute installers. Kaba’s honeypot recorded a base64-encoded Perl installer identical to the command that earlier deployed the Ebury backdoor on a relay operator’s hosts.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildThe Ebury backdoor and the Quetzalcoatl compromise
Zimmer, who ran the Quetzalcoatl relay family, reported that two of his servers were running Ebury version 1.8.3. A Contabo-hosted management server functioned as the family’s VPN gateway and SSH jump host; a FranTech VPS named Switzerland2 ran two of the exits. According to Zimmer’s post-mortem, an attacker logged into the management server on August 28 using the operator account’s password on the first try, escalated to root within five minutes, installed Ebury, then reached Switzerland2 a little over an hour later and installed it there as well.
Zimmer attributed the root cause to internal operational failures: one password reused across SSH login, sudo and a backup passphrase stored in plaintext on both servers, plus SSH password authentication left enabled on the internet-facing management server. Ebury on these hosts is a single setuid library file, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, with an accompanying symlink. The implant survived reboots on Zimmer’s machines; routine reboot killed the attacker’s hidden tools briefly on October 4, but Ebury “came straight back.”
Marc-Etienne M. Léveillé, who co-wrote ESET’s 2014 Ebury paper and authored its 2024 report, wrote that version 1.8.3 has been around since at least June 2026 and posted an updated detection script. Léveillé observed that, given prior infection counts, many other compromised Tor relays could exist.
What relay operators should check
- Look for Exit flag or exit policy changes in Relay Search and inspect torrc and any included files for unexpected ExitRelay, ExitPolicy, ContactInfo, MyFamily, or Nickname lines.
- Look for NAT rules redirecting port 22, unknown listening processes or outbound connections, new users, unexpected authorized_keys entries, cron jobs and systemd units, and a tor binary that fails package checks.
- Specific signs from Zimmer’s analysis: the setuid file /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 (unowned by any package), a symlink libkeyutils.so.1 pointing to it, an abstract UNIX socket named @event-0YsOG9WSOE, a fake /sbin/rsyslogd process in the ssh.service cgroup, the IP 185.225.226.62 as a source of the August 28 login, and several SSH key fingerprints embedded in the implant.
- If you suspect compromise, check from rescue media or an offline image; on a live system, log in with a key and avoid entering passwords. Start a shell with H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash to bypass the userland rootkit before running detection scripts.
- If infected, the Tor Project advises taking the relay offline, preserving disk and logs, reinstalling rather than attempting to clean up, generating a new relay identity, rotating any credentials on the host, and reporting to bad-relays@lists.torproject.org. Georg Koppen added that if your IP was blocked during the incident, write to the same address after cleanup to request lifting the block.
What this means for Relay operators, Tor users, and Technologists
- Relay operators: verify exit policies, search for the Ebury indicators above, and assume that a changed exit policy can be a sign of an implanted backdoor that survives reboots; reinstallation and key rotation are recommended if found.
- Tor users connecting to SSH over Tor: if you accepted an unfamiliar or changed host key between October 1 and the afternoon of October 5, treat any password you typed as stolen, change it, and check the server for Ebury indicators; OpenSSH saved the accepted key in known_hosts.
- Security teams and researchers: the incident underscores how a host-level implant (Ebury 1.8.3, here) can be used to alter Tor behavior; updated detection scripts such as Léveillé’s should be run against suspect hosts, and directory-data analysis can reveal broad policy changes even where host-level evidence is uneven.
Directory authorities applied BadExit and MiddleOnly flags beginning at 18:00 UTC on October 4 and included them in the consensus by 21:00; by 17:00 UTC on October 5 no relay with the attacker’s policy remained in the consensus. Tor Metrics showed the count of relays carrying the Exit flag fall by about 370 between October 3 and October 5 and not recover by October 18. But key questions remain: how broadly Ebury has spread among relays beyond the Quetzalcoatl family, which hosts exactly ran the interception servers, and whether a common actor or multiple actors carried out the policy changes across diverse providers.
Original reporting: https://thehackernews.com/2026/10/attackers-hijacked-over-300-tor-exit.html
