23 October 2026kaba.cx · SecurityCurated

Tor exits as an SSH trap: what 333 compromised relays teach about Ebury

Summary

On kaba.cx, an affected person describes how, from 2 October 2026, around 333 Tor exit relays redirected SSH connections to interception servers, and how these relays were tracked down and removed from the network. Behind the attack was the long-known OpenSSH backdoor Ebury in version 1.8.3, which had already been installed on the relay operators' servers in August. This post adds the incident report of an affected operator and shows how to recognise Ebury and why keys instead of passwords make the difference here.

What happened

According to kaba.cx, 333 infected exit relays began a coordinated campaign on Friday, 2 October 2026, at 09:35. The Tor network has around 3000 exits, so the attackers controlled about a tenth. The goals were unencrypted mail traffic and intercepting SSH connections: anyone opening a connection to port 22 through one of these exits ended up, unnoticed, at one of twelve interception servers, while encrypted web traffic passed through normally.

The only visible sign was the warning “REMOTE HOST IDENTIFICATION HAS CHANGED”. According to kaba.cx, anyone who ignores it loses three things: the password is stolen, the session to the real server is observed, and a second connection infects that server with Ebury as well.

On 4 October, Tor's network health team informed the operators and flagged the relays as BadExit, so clients no longer used them as exits. On 5 October, the attackers restarted many relays, which could then only act as middle relays; by the end of that day all infected servers had been shut down. In its announcement, the Tor team wrote that the attackers turned compromised middle relays into exits by editing the torrc.

How the interception servers were found

Using the Tor Project's exitmap tool, each of the roughly 3000 exits was pinned in turn and used for an SSH connection between two of the author's own servers. Server A checked server B's fingerprint, and server B checked whether the connection came from the pinned exit or from one of the twelve interception servers. About a dozen exits served a fake fingerprint, and over 300 only redirected through the same interception servers; that alone was enough as proof.

An SSH honeypot (sshesame) showed that the interception servers used the Python library paramiko and loaded Ebury via a base64-encoded Perl script run with sudo, after checking whether sudo worked without a password.

What an affected operator found

The operators of the Quetzalcoatl relay family documented their incident in detail on the tor-relays mailing list. The cause was self-inflicted: one password served for SSH login, for sudo and as the passphrase of a backup, sat in cleartext in a helper script, and password login was enabled on the internet-facing management server. On 28 August, the attackers logged in with it on the first attempt and had root five minutes later.

There, Ebury 1.8.3 consisted of a single file, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 with the setuid bit set, with the libkeyutils.so.1 symlink re-pointed at it. The real package stayed untouched, so package verification with dpkg -V or debsums found nothing. On Debian 13, sshd-session loads the library via libkrb5, and because it sits inside the SSH service it sees every password in cleartext, including failed attempts and the investigators' own passwords.

The attackers lowered sshd's logging, and logins through the backdoor leave neither login records nor shell history. The only conspicuous traces were root actions that no logged-in user could have triggered. On two exit relays, they changed the exit policy so that plaintext POP3, IMAP, Telnet and SSH were open while the TLS mail ports were blocked; this ran for about 52 hours at roughly 3.4 TiB of traffic per day. The supposedly offline relay keys were stored as a copy in the backup on the compromised server.

Why keys protect here

When logging in with an SSH key, the client signs a value that is bound to the particular connection. An interception server therefore cannot pass this signature on to the real server, unlike a password. This protection is undone, however, if you forward the SSH agent over a suspicious connection (ForwardAgent) or click away the host key warning and then type a password.

Ideas

A host key warning is an alarm, not a notice to click away.
Exit relays see all traffic that is not encrypted end to end.
One password for SSH, sudo and backups opens every door at once.
Package checks do not find an extra file that a symlink points to.
A backdoor inside the SSH service sees passwords before they are checked.
External monitoring of the published configuration detects tampering that logs hide.
Keys meant to be offline are only offline if no copy is online.

Insights

The attack used no new vulnerability but old convenience: reused passwords, password login on the internet and a central management server without isolation. From there, a well-known backdoor was enough to take over an entire relay family.
Tor protects anonymity, not content. Anyone using an unencrypted or poorly verified protocol over Tor trusts an unknown exit; for SSH over Tor, onion services are the safe route, because the connection never leaves the Tor network.
On a compromised server, logs, process lists and package checks lie. Only checks from the outside, such as the publicly published relay data, or from a clean rescue system are reliable.

Quotes

“We've not seen an attack like that before.” (Tor Network Health Team, quoted on kaba.cx)
“At the end of the day, relays/bridges need to be treated as highly targeted production machines.” (George on the tor-relays list, quoted on kaba.cx)

Facts

From 2 October 2026, 333 of around 3000 Tor exits intercepted SSH connections via twelve interception servers.
On 4 October, the Tor team flagged the relays as BadExit; by 5 October all infected servers had been shut down.
According to Marc-Etienne M. Léveillé, Ebury 1.8.3 has been in circulation since at least June 2026 and is newer than ESET's detection indicators last published in May 2024.
According to Léveillé, around 400,000 servers were infected with Ebury between 2009 and 2023.
On Debian 13, the tampered libkeyutils is loaded into sshd-session via libkrb5; dpkg -V and debsums report nothing.

References

Remarks

kaba.cx presents the find as its own discovery; according to the operator's report, Tor's network health team had independently noticed the changed exit policies. Both routes led to the block on the same weekend.
How the attackers got into the first servers is still open. Léveillé considers a login from a machine already infected with Ebury or a compromised hosting provider possible.

Recommendations

Disable password login and check the effective setting with sshd -T | grep -i passwordauthentication, because sshd takes the first value it finds, even from a forgotten entry in the server image.
Confirm the host keys of new servers through a second channel, for example the hoster's console or SSHFP records with DNSSEC and VerifyHostKeyDNS yes; enable ForwardAgent only for trusted destinations.
Search Linux servers for Ebury, ideally from a rescue system: find / -xdev -name 'libkeyutils*' -perm -4000, dpkg -S "$(readlink -f /usr/lib/x86_64-linux-gnu/libkeyutils.so.1)" and grep @event- /proc/net/unix.
Never put passwords in scripts, and ship logs to a separate server so an attacker cannot truncate them afterwards.

Read the original post

Search the Web Archive