On October 2, 2026, at around 9:35 AM, the researcher publishing under the pseudonym "Kaba" connected to one of his servers via SSH through the Tor network and received a warning that every system administrator knows well: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" Normally, this message means you are reconnecting to a server that has been reinstalled or had its cryptographic keys replaced. But in this case, something was deeply wrong. The key presented belonged to a server Kaba did not recognize — a server controlled by attackers.
What began as an isolated security alert escalated into the discovery of one of the most significant compromises ever recorded against the Tor network. Within hours, Kaba identified 333 compromised exit nodes — approximately 10% of the entire network's exit capacity — redirecting SSH connections to 12 attacker-controlled servers. For three days, these nodes intercepted user credentials, monitored active terminal sessions, and attempted to install an updated variant of the Ebury malware on victim servers.
The attack was notable not only for its scale but for its operational stealth, its deliberate choice of a 17-year-old backdoor, and the way attackers exploited security hygiene failures that remain alarmingly common in server infrastructure.
A two-layer attack architecture
To understand what happened, it is necessary to understand how the Tor network functions. Tor routes user traffic through several volunteer-operated relays to hide IP addresses. The last of these relays, called the exit node, is the point where user traffic leaves the Tor network and enters the public internet. Each exit node has an "exit policy" defining which ports and protocols it will allow traffic to use — typically HTTP, HTTPS, and for many, SSH.
Attackers rewrote the exit policies of the 333 compromised nodes to redirect all traffic on port 22 (SSH) to a pool of 12 interception servers. These servers operated as classic man-in-the-middle proxies: when a user connected via SSH, the malicious server presented its own cryptographic fingerprint, captured the password in plaintext when the user authenticated, and then re-established the connection to the legitimate server, forwarding all commands. To the victim, everything appeared to work normally — the attackers saw every keystroke.
The second layer of the attack was even more insidious. Simultaneously with SSH interception, the interception system attempted to establish a second connection to the victim server, trying to install Ebury — a Linux backdoor that embeds itself into OpenSSH and steals credentials from anyone who connects to the compromised machine.
Ebury: a digital fossil that comes back to life
Ebury is one of the most persistent and understated backdoors in cybersecurity history. First discovered in 2009, Ebury is specifically designed to compromise OpenSSH on Linux systems. Unlike modern malware utilizing sophisticated obfuscation or encrypted communications, Ebury operates with minimalist elegance: it injects a shared module into the sshd process using LD_PRELOAD, intercepting passwords at the moment the PAM system processes them.
The variant used in this attack, version 1.8.3, has a particular characteristic that makes it exceptionally difficult to detect. Instead of modifying files installed by the package manager, Ebury 1.8.3 leaves the official libkeyutils library intact and places a malicious fake file next to it. It then reconfigures the symbolic link to point to the fake version. Integrity verification tools like dpkg -V and debsums see only the original library — intact — and report everything as clean.
This is not speculation. Zimmer, the Quetzalcoatl relay operator whose relays were compromised, published a detailed forensic analysis showing that the packaged library remained unmodified on both affected servers. sshd, sudo, and PAM modules passed all package checks. The only way to detect Ebury is to directly inspect the filesystem for unusual setuid files or verify the hash of the running version in memory.
The timeline of the Quetzalcoatl relay compromise reveals the persistence of the attack. On August 28, 2026, attackers accessed the management server (a Contabo VPS) using a password that was also used for sudo and an encrypted backup — and that was stored in plaintext in a script. From there, they pivoted to the second server (Switzerland2), running two Quetzalcoatl relays on a FranTech Solutions VPS (BuyVM brand). On October 1, with no SSH login, sudo command, or cron entry logged, the attackers rewrote the Tor configuration files and restarted the service. When administrators restarted the servers on October 4 to clear the malware, Ebury simply reappeared — because the setuid file remained on disk, waiting for the next sshd boot.
Why 333? The hosted provider problem
One of the most intriguing questions raised by this incident is how the attackers managed to compromise more than 300 relays simultaneously. The most plausible theory, raised by Marc-Étienne M. Léveillé — the Ebury researcher who authored ESET's 2024 report — is that one or more hosting providers were compromised, allowing attackers to deploy Ebury on servers rented by operators without any notice.
Zimmer's data supports this hypothesis. Among relays hosted on FranTech Solutions, 71 of 101 adopted the attacker's policy, compared to just 13 of more than 9,000 relays hosted on other networks. This asymmetry strongly suggests that the entry point was not individual operator failures but rather a vulnerability in shared infrastructure offered by FranTech.
ESET documented this exact scenario in its 2024 research: Ebury operators compromise hosting providers and deploy malware on servers rented by legitimate clients, with no warning. In that scenario, the responsibility for the compromise does not rest with the relay operators but with the infrastructure provider that failed to adequately isolate tenants.
The community response
The detection was performed entirely by a volunteer researcher. Kaba used exitmap — an official Tor Project tool — to test each of the network's ~3,000 exit nodes, verifying whether the presented SSH fingerprint matched expectations and whether the connection came from the exit node or from one of the interception servers. Within hours, he identified the 333 compromised relays and notified the Tor Network Health team that same evening.
The Network Health team's response was remarkably swift. On October 4, all malicious relays were flagged with the BadExit marker, preventing Tor clients from using them as exit nodes. On October 5, operators of the compromised relays were contacted and began shutting down their servers.
"We've never seen an attack like this before," the Tor Network Health team told the researcher, as reported by Dan Goodin in Ars Technica. Subsequent analysis by Tor at 1AEO identified 377 additional relays across 147 IP addresses — though this broader count reflects exit policy matches rather than confirmed infections.
Lessons for the infrastructure community
This incident raises fundamental questions that extend far beyond the specific compromise of 333 relays. First, it demonstrates that the security of the Tor network — designed to provide anonymity against governments and high-capacity adversaries — is vulnerable to low-tech attacks against underlying infrastructure.
Second, the case exposes the chronic fragility of password-based authentication in corporate and infrastructure environments. Zimmer documented that he used the same password for SSH login, sudo, and encrypted backup — an engineering security mistake that virtually any modern DevOps team would recognize as a fundamental anti-pattern. The community's standard recommendation — use key authentication and disable password login on internet-facing hosts — would have been sufficient to completely prevent the initial exploitation.
Third, the episode reinforces a point the security community has been making for years: package-based integrity verification tools are insufficient for detecting sophisticated kernel-space or user-space backdoors. If malware can coexist with original package files without being detected by dpkg, the integrity test is providing a false sense of security.
The Ebury compromise of 333 Tor relays is a reminder that a security chain is only as strong as its weakest link. The Tor network, with its cryptographic protocols and decentralized architecture, was held vulnerable not by a flaw in Tor itself, but by operators who relied on reused passwords stored in plaintext — and by hosting providers whose security plans did not account for the risks of infrastructure sharing. In a world where digital anonymity is increasingly valued, perhaps the weakest link is not in the protocols, but in human engineering.
Sources: Kaba, SecureWorld, Tor Project Forum
✓ Independent sources cross-checked and verified before publishing
