A reused SSH password and Ebury 1.8.3 in the hijack of 333 Tor exit relays

On the morning of Friday 2 October 2026, the SSH client of someone who writes as kaba warned that the remote host identification had changed, although the server was the same. The connection was leaving the Tor network through an exit relay that was rerouting it. That same day kaba tested each of the roughly 3,000 exits in turn and, as set out in a write-up published on 20 October, found 333 of them sending SSH connections to the same 12 interception servers.

The attacker had broken into the Linux machines hosting the relays and changed their configuration. On the two servers examined in detail, those of the operator behind the Quetzalcoatl relay family, the implant was Ebury 1.8.3, a recent build of an OpenSSH backdoor active since 2009 that ESET's detection script does not recognise. There the way in was a reused password on a management server that still allowed password logins over SSH, although how the attacker obtained it is still unknown.

What happened on the Tor network between 1 and 5 October?

Between 1 and 4 October, 342 relays that had blocked port 22 began allowing it, most of them on the 2nd. The figures come from the analysis of public Tor directory data posted on the tor-relays list on 9 October by relay operator Tor at 1AEO, which also found that 24 of the affected relays had not been exits until then. At the peak, on 4 October, relays carrying that policy held 7.46% of the network's exit weight.

Tor's network health team heard from kaba on the evening of Friday 2 October and contacted the operators concerned on Sunday 4 October. From 18:00 UTC that day the directory authorities started voting the BadExit flag, which reached the consensus at 21:00.

The flag stops clients using a relay as their exit. By 17:00 UTC on 5 October no relay with the policy remained in the consensus. The count of exit-flagged relays fell by around 370 and, according to The Hacker News citing Tor Metrics, had not recovered by 18 October.

In its notice to relay operators on 5 October, the Tor Project said the attacker appeared to be getting into Linux hosts running non-exit relays and editing the relay configuration file, torrc, to turn them into exits. That same day, according to kaba, the attackers restarted many of the relays, which, already flagged, could only act as middle relays. On Switzerland2, according to Zimmer, the restart came from the backdoor and the directory authorities rejected the descriptors of its two relays.

How did the interception work?

Kaba found that SSH sessions leaving a compromised exit went through one of the 12 attacker servers, which relayed the session onward to the destination host. Around a dozen exits also served a fake host fingerprint. On the rest kaba saw no interception, although the connection still passed through an attacker server.

Why were passwords exposed while SSH keys held up?

Only users who accepted an unexpected host fingerprint, by deleting the old entry from known_hosts or on a first connection, and then entered a password were caught. A password travels encrypted to whichever server negotiated the session, which then sees it in clear, and here that server was the attacker's. Logins with SSH keys resisted the detour because, under RFC 4252, the client's signature covers the identifier of that session and cannot be replayed into a different one.

Which ports did the new exit policy open?

According to the directory analysis, the policy opened Telnet, IRC and RDP on most of the 366 affected relays and plaintext POP3 and IMAP on 309, while closing POP3S and IMAPS on 334. Kaba believes the attacker wanted to gather as much unencrypted mail traffic as possible. The author of the analysis notes, however, that the data do not explain why the encrypted ports were closed.

What was Ebury for once a password landed?

When a victim logged in with a password, the attacker kept it and opened two connections to the destination server. One was used to watch the commands typed and the other to install Ebury, which turned each victim into another foothold. Kaba confirmed the behaviour with an SSH honeypot, in which the intruder used Python's paramiko library and tried to drop the backdoor through a base64-encoded Perl installer.

How did the attacker get into Quetzalcoatl?

The attacker got in with one password reused for SSH login, for sudo and for the backup passphrase. The account comes from the post-incident review that the Quetzalcoatl operator, who signs as Zimmer, published on the tor-relays list on 7 October. In that unusually candid review Zimmer admits that "the root cause was ours" and explains that the password sat in plaintext in a helper script. Quetzalcoatl was the relay family most affected, with 277 relays adopting the new policy according to the directory analysis.

At 03:19 UTC on 28 August the attacker logged into a Contabo VPS with that password at the first attempt. The attacker had root by 03:24. The machine allowed password authentication over SSH and served as WireGuard VPN gateway, SSH jump host and obfs4 bridge, besides holding a backup of the administrator's workstation. At 04:38, according to the review, Switzerland2, a VPS hosted at FranTech, accepted a login with an RSA key that appeared in no authorized_keys file Zimmer could find on that machine. Ebury was in place one second later.

More than a month went by, with quiet activity such as installing nmap on 31 August and decrypting backup metadata on 6 September, before the exit policies were touched. The relay master keys Zimmer believed were offline had copies inside that workstation backup. A reboot of Switzerland2 on 4 October, for a kernel upgrade, killed the hidden tooling, yet Ebury loaded again at boot. Zimmer retired every relay in the family and its bridge, and deleted both servers.

Does the concentration of relays point at a hosting provider?

Leaving Quetzalcoatl aside, 71 of the 101 relays hosted with FranTech Solutions, the network behind BuyVM, changed policy, according to the directory analysis. Elsewhere on the network only 13 of 9,054 did. On 1 October, 40 relays belonging to 21 different operators changed in under five and a half minutes. In a message to the list on 8 October, kaba noted that in their 2 October data 26 of the 27 compromised relays outside Quetzalcoatl were hosted there. Kaba also asked whether access had been gained at hosting level.

No source has confirmed that hypothesis. The initial access to Quetzalcoatl came through a Contabo server, although Switzerland2, the other infected machine, sat at FranTech, as did 48 of its relays, and how the other hosts were entered remains unknown. The directory analysis also cautions that matching the policy does not prove compromise, since 377 relays run by 59 operators adopted it.

Why do dpkg and ESET's script miss Ebury 1.8.3?

Zimmer's review shows version 1.8.3 arriving as a single setuid file, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, owned by no package, with the libkeyutils.so.1 symlink repointed at it. The genuine packaged library is untouched. As a result, dpkg -V and debsums report a clean system, and sshd, sudo and PAM all match their package checksums.

• Each install carries its own victim identifier, so the file hash differs from server to server and a list of known hashes is useless.
• Infected processes cannot see the library in their own memory maps (/proc/self/maps).
• Backdoor logins bypass PAM, and the configuration the implant imposes (UsePAM no, LogLevel QUIET, HISTFILE=/dev/null) disables shell history and silences sshd logging.
• The credential collector records passwords as they are typed, failed attempts included.

Zimmer found that ESET's public indicators, last updated in May 2024, stop at version 1.8.2 and that its detect_ebury.sh script would not have flagged 1.8.3, although ESET's YARA rule libkeyutils_with_ctor still matches it. Marc-Etienne M. Léveillé, who co-authored ESET's Ebury research and has since left the company, wrote on the tor-relays list on 8 October that 1.8.3 has been around since at least June 2026 and that other relays are most likely compromised. He also published an updated version of his detection script, which he cautions is "not a silver bullet".

In its May 2024 report, ESET estimated that Ebury had compromised some 400,000 servers since 2009, with more than 100,000 still infected at the end of 2023. The same research describes hosting providers whose compromise led to infections on the servers rented to their customers, and SSH interception inside data centres using ARP spoofing from already infected machines on the same segment.

What behaviour should defenders hunt for?

When hashes and package checks come back clean, detection has to focus on what the implant does and leaves behind. The indicators described by Zimmer and the Tor Project's 5 October notice concern behaviour and configuration, and they belong in a threat hunting sweep that starts with the jump hosts.

• Setuid libraries in system directories that belong to no package, any libkeyutils variant above all, and symlinks that resolve to unexpected files.
• Abstract sockets named along the lines of @event-, and a process posing as /sbin/rsyslogd inside the ssh.service control group on Debian or init.scope on Ubuntu 24.04.
• An sshd log level below INFO, as on Switzerland2, where the attacker restarted sshd from inside the backdoor on 30 September and, with LogLevel at ERROR, accepted logins stopped being recorded.
• NAT rules redirecting port 22 (nft list ruleset, iptables -t nat -S), new users, unexpected authorized_keys entries, unknown cron jobs, systemd units or kernel modules, and a fake upper-case CRON daemon.
• Commands such as base64 -d | perl in sudo logs, and SSH logins accepted with keys that appear in no authorized_keys file, visible only if authentication logs leave the server before the attacker tampers with them.

On Linux hosts running Microsoft Defender for Endpoint, the following indicative query looks for libraries of that name created or modified in system directories by processes other than the Debian package managers.

DeviceFileEvents
| where ActionType != "FileDeleted"
| where FileName startswith "libkeyutils.so" and FolderPath matches regex @"^/(usr/)?lib"
| where InitiatingProcessFileName !in~ ("dpkg", "apt", "rpm", "dnf", "yum")
| project Timestamp, DeviceName, ActionType, FolderPath, SHA1, InitiatingProcessCommandLine

An empty result is not a clean bill of health. Defender advanced hunting keeps 30 days of data, so an August infection like Quetzalcoatl's would not show up. The Hacker News also notes that Zimmer's servers lacked several on-server signs other operators reported, such as the fake CRON daemon and the NAT rules, and whether the cases share one actor is unclear. Zimmer advises capturing memory before rebooting, investigating from an offline disk image or a known-good machine, and never typing a password into a suspect server, because Ebury would record it.

On-host checks need central logging behind them. A server that ships its authentication events to a SIEM keeps the trail even after local logs are wiped. An EDR agent helps little if the VPN gateway or jump host sits outside its coverage, the same gap we examined in EDR blind spots on network edge devices.

Which controls would have stopped each step?

Each phase of the attack exploited a missing control, from password logins over SSH to the mix of roles on the jump host.

Should SSH password logins be switched off?

With SSH restricted to keys, the attacker could not have entered Quetzalcoatl with the reused password or harvested passwords through the relays. Finding the servers that still accept passwords is a basic task in Linux systems hardening. Credentials bound to a FIDO2 token, OpenSSH's ed25519-sk type, also require a touch for every use by default. A single password should never unlock SSH, sudo and backup encryption at once, or sit in plaintext inside a script.

Why does host fingerprint verification matter?

Accepting an unknown or changed host fingerprint without checking it hands the password to whoever sits in the middle, which is what the relay victims did. Setting StrictHostKeyChecking yes and signing host keys with an in-house SSH certificate authority lets clients validate servers without trusting the first connection.

Where does the jump host risk lie?

The machine acting as VPN gateway, jump host, bridge and backup store was among the most valuable in the Quetzalcoatl estate, and poorly protected. Splitting those roles and treating the jump host as a top-tier asset curbs lateral movement, and proper internal network segmentation would have hampered the hop to Switzerland2, which came 74 minutes after the attacker gained root.

Léveillé's best guess is that the password was captured during a login from a host already infected with Ebury, which argues for watching the machines administrators work from before anything else. Material meant to stay offline cannot travel inside a workstation backup either.

Does finding Ebury mean a full rebuild?

The Tor Project notice advises that a compromised relay should be taken offline, its disk and logs preserved, the system reinstalled instead of cleaned, a fresh identity generated and every credential on the machine rotated. Switzerland2 shows why, since its persistence survived the reboot. A forensic examination of the preserved image helps establish which other systems the attacker could have reached.

How far does defence depend on the hosting provider?

If the FranTech hypothesis holds, neither SSH restricted to keys nor host fingerprint checking would have stopped access from the provider's own infrastructure. ESET documented that scenario in 2024. For an organisation renting virtual servers, that belongs in third-party risk management, which should establish what access the provider has to the machines, how it is logged and what the provider would disclose after a compromise. That dependency surfaced by another route in the Virtualizor BGP hijack.

Which questions remain open?

As of 26 October 2026 it is still unknown how the attacker obtained the Quetzalcoatl password or how the other hosts were entered. Nor is it known whether this was one campaign or several, or how many passwords were captured between 1 and 5 October. Anyone who typed an SSH password over Tor in that window should assume it is stolen.

The conditions behind this case also exist outside Tor, on internet-facing Linux servers that accept SSH passwords, share credentials across roles and rely on integrity tooling that cannot see this backdoor. Checking which servers still accept passwords and repeating the Ebury hunt wherever only the 2024 indicators were used are the two immediate tasks, starting with the jump hosts.

This analysis draws on information available on 26 October 2026. Its sources are kaba's research and messages to the tor-relays list, the Tor Project's notice to relay operators, the Quetzalcoatl operator's review, the directory analysis posted by Tor at 1AEO, Marc-Etienne M. Léveillé's message, ESET's 2024 Ebury report and coverage by The Hacker News.

The hosting-provider compromise hypothesis is unconfirmed and attribution of the campaign remains open. No mention of a hosting provider implies a confirmed security failure in its infrastructure. The query and checks cited are indicative, a negative result does not rule out infection, and they should be validated in a test environment before being automated.