For roughly four days in early October, anyone who connected to an SSH server over Tor had a meaningful chance of passing through an attacker's hands. More than 300 Tor exit relays were quietly reconfigured to send SSH traffic to interception servers built to harvest passwords. At the campaign's peak on October 4, the hijacked relays carried 7.46% of Tor's total exit capacity, according to an analysis of public Tor directory data posted to the tor-relays mailing list.
The scale makes for a striking headline, but security teams should focus elsewhere. One operator whose relays were hijacked published an unusually candid post-mortem, and the failures it describes have nothing to do with Tor. They can show up in almost any Linux environment.
An exit relay is the last hop in a Tor circuit, where traffic leaves the anonymity network for its destination, and each one has an exit policy that defines which ports it will carry. Starting October 1, attackers rewrote those policies to open port 22. That enabled SSH on 342 relays that had previously blocked it, and turned 24 relays that weren't exits at all into exits. The same change shut off the encrypted mail ports and, on most relays, opened plaintext POP3 and IMAP.
A researcher who publishes as "kaba" first noticed the activity on October 2, when an SSH connection over Tor returned a changed-host-key warning. A scan of Tor's roughly 3,000 exits found 333 of them routing SSH to the same 12 interception servers. The directory-data analysis counts 377 relays across 59 operators that adopted the attacker's policy, though it notes that a policy match is not proof of compromise.
Once it intercepted a connection, the attacker's server presented its own host key. A user that accepted that key and logged in with a password gave the interceptor the password. The interceptor then relayed the session to the real server so nothing looked wrong, and could log in separately to check for sudo rights and run an installer that matched the pattern used to deploy the Ebury backdoor.
Key-based logins could not be stolen this way. Under the SSH authentication protocol, the client's signature includes an identifier unique to each session, so a signature captured by the interceptor is useless against the real server. In practice, the host-key prompt was the only thing standing between password users and the attacker.
The exposure window was narrow, and no victim count exists. Anyone that connected over Tor between October 1 and the afternoon of October 5, accepted an unfamiliar or changed host key, and typed a password should treat that password as stolen and inspect the server it unlocks.
The Tor Project's network health team moved quickly after being alerted. Directory authorities began applying the BadExit flag to affected relays on the evening of October 4, and by 17:00 UTC on October 5 no relay with the attacker's policy remained in the consensus. The cleanup left a visible gap: Tor Metrics shows the count of exit-flagged relays fell by about 370 and had not recovered by October 18.
The largest group of affected relays belonged to the Quetzalcoatl family, which is run by an operator named Zimmer. His post-mortem blames no one else. "The root cause was ours," Zimmer wrote, and the details explain why.
On August 28, more than a month before any relay changed behavior, the attacker logged in to the family's management server on the first attempt using the operator account's password. That server also served as the family's VPN gateway and SSH jump host, and the attacker had root access within five minutes. Ebury was installed there and, a little over an hour later, on a second server running two of the exits.
According to Zimmer, the same password was used for SSH login, sudo, and the backup passphrase. It was stored in plaintext on both servers, and password authentication was left enabled on the internet-facing management host. The attacker's source for the password remains unknown.
The worst detail involves the relay family's master keys. They were supposed to be offline, but copies sat in a workstation backup on the compromised management server, encrypted with the password the attacker already had. Zimmer retired every relay in the family, along with its bridge, and deleted both servers.
Each of these failures is familiar from incident reports: a single credential that unlocks every layer, a jump host reachable by password from the internet, and "offline" secrets that were offline in name only. A security team that hasn't audited for these patterns recently should treat this post-mortem as a reminder.
The backdoor itself makes the lessons harder to act on. Ebury is an OpenSSH backdoor and credential stealer active since 2009. In 2024, ESET reported that it had been deployed to compromise almost 400,000 Linux, FreeBSD, and OpenBSD servers, with more than 100,000 still compromised as of late 2023.
The variant on Zimmer's servers, version 1.8.3, lives in a single setuid library file next to the legitimate libkeyutils package. Because the packaged library is untouched, integrity tools such as dpkg -V and debsums report nothing wrong, and sshd, sudo, and PAM all pass their package checks. Version 1.8.3 is also newer than ESET's public indicators, and ESET's published detection script does not cover it.
Ebury's backdoor logins leave no record. When the exits' configuration files were rewritten on October 2, the logs showed no login, sudo command, or cron job. A routine reboot on October 4 killed the attacker's hidden tooling, but Ebury itself came straight back.
Marc-Etienne M. Léveillé, who wrote ESET's 2024 Ebury report and has since left the company, replied on the list that version 1.8.3 has circulated since at least June 2026. He also posted an updated detection script that covers it. Given Ebury's footprint, he added, "there are most likely other compromised Tor relays out there."
The practical takeaway for defenders is to inspect suspect machines from a rescue system or an offline disk image, and to authenticate with keys rather than passwords if a live login is unavoidable. Any password typed into an Ebury-infected host is a password handed to the attacker.
How the other 58 operators' hosts were breached is the central unanswered question, and the data point toward one provider. Of the relays hosted on FranTech Solutions, the network behind the BuyVM brand, 71 of 101 switched to the attacker's policy, compared with just 13 of the more than 9,000 relays hosted elsewhere. Forty relays belonging to 21 different operators changed within a five-and-a-half-minute window on October 1, which the directory-data analysis reads as a single actor that already had access to all of them.
Kaba counted 26 of the 27 compromised servers outside the Quetzalcoatl family at FranTech/BuyVM and put the question to the list directly: "Could they have compromised those servers at the hoster level?"
There is precedent for that scenario. ESET's 2024 research found cases where Ebury operators compromised hosting providers and deployed the malware on servers rented out by those providers, with no warning to the lessees. Léveillé raised a compromised provider as one possibility here, alongside a login from a host already running Ebury.
The picture is not clean, though. Quetzalcoatl's compromise ran through a management server at a different provider, Contabo, and most of its affected relays sat on other networks. Other operators also reported indicators that Zimmer's servers did not show, including a fake uppercase CRON daemon and NAT rules redirecting port 22. Whether this was one campaign or several, and who is behind it, remains unknown.
Tor relay operators should follow the Tor Project's October 5 guidance. That means checking Relay Search for an exit flag or exit policy they did not set and reviewing their torrc files for unexpected changes. If they find Ebury, they should take the relay offline, preserve the disk and logs, reinstall rather than clean up, generate a new relay identity, and rotate every credential that lived on the host. Reinstalling matters because the implant survived a reboot. The Tor Project's Georg Koppen also asked that people report compromises to bad-relays@lists.torproject.org.
For everyone else, the lessons carry over directly. Disable SSH password authentication on internet-facing hosts, especially jump boxes and management servers. Keep the credentials for login, privilege escalation, and backup encryption separate. Verify that keys described as offline actually live off the network. Don't treat a passing package-integrity check as proof that a host is clean.
Finally, treat your hosting provider's management plane as part of your threat model. If the FranTech pattern holds up, dozens of operators did nothing differently from their peers on other networks and were compromised anyway.