← Home

333 Tor exit nodes hijacked in massive SSH interception campaign

The Largest Espionage Campaign Ever Launched Against the Tor Network

In the first half of October, more than 300 Tor network exit nodes were compromised and reconfigured to intercept SSH connections and capture plaintext credentials. The attack, discovered by researcher "kaba" on October 2, turned out to be a sophisticated, long-running operation with the initial infrastructure already compromised since August 2026.

The discovery

It all began when researcher kaba noticed, on October 2, that an SSH connection established through a Tor exit node returned a host key change alert — a warning every system administrator recognizes as a sign that something is wrong. Instead of ignoring the alert and proceeding, kaba investigated. Using exitmap, a tool developed by the Tor Project itself to monitor network health, they scanned the approximately 3,000 active exit nodes and found a disturbing pattern: more than 300 of them were routing SSH connections to the same set of 12 attacker-controlled interception servers.

The discovery was not accidental. Kaba had built a script that pinned an exit node, opened an SSH connection between two of their own servers, and checked both the presented fingerprint and the connection's source address. The results were unequivocal: about a dozen nodes served a fake key, and more than 300 forwarded connections through the same interception infrastructure.

How the attack worked

The attack was built in two phases. The first — and most critical — occurred in August 2026, when attackers gained initial access to a management server hosted by a family of Tor relay operators. According to a post-mortem published by one operator (Zimmer, on the tor-relays mailing list), the breach occurred through a single reused password: the same password was used for SSH login, sudo, and backup. The server also functioned as a VPN gateway and SSH jump host, accessible from the internet, with password authentication enabled.

Within five minutes, the attacker had root access. In less than an hour, the Ebury malware — a Linux backdoor discovered 12 years ago — was already installed on the servers. Ebury hides within the libkeyutils library itself, replacing the legitimate binary and posing as an unauthorized library, which allows the backdoor to pass integrity checks that would normally detect tampering.

The second phase occurred on October 1. Attackers rewrote the exit policies of the compromised relays, opening port 22 (SSH) on 342 relays that previously blocked it, and converting 24 relays that were not exits into active exit nodes. At the same time, they closed the encrypted ports (IMAPS and POP3S) and, on most relays, opened plaintext email ports (POP3 and IMAP).

When a Tor client connected to one of these relays, the SSH connection was redirected to one of the 12 interception servers. The fake server presented its own host key. If the user accepted the changed key and typed a password, the credential was captured. From there, the interceptor did two things simultaneously: it kept the SSH session alive, relaying commands between the client and the legitimate server (so the user noticed nothing), and opened a second connection to attempt installing Ebury on the target server.

Kaba's honeypot revealed that the attackers used Paramiko (Python's SSH library) and executed a base64-encoded Perl installer that checked privileges before attempting installation. The pattern matched the Ebury deploy exactly, meaning that if successful, it would infect the target server with the same backdoor.

Who was exposed

The exposure window was narrow and the attack scenario specific: to be a victim, one needed to connect to an SSH server through Tor between October 1 and 5, land on a hijacked relay, accept the changed host key, and authenticate with a password. Key-based SSH login was not vulnerable to this technique, because the SSH authentication protocol (RFC 4252) is session-specific.

No victim count was confirmed. The absence of a count does not mean absence of impact — server operators who used passwords to access remote machines via Tor during those dates should treat their credentials as compromised and investigate their servers for Ebury artifacts.

Artifacts include: tampered OpenSSH binaries, modified PAM modules, suspicious shared libraries in /usr/lib and /usr/local/lib, and the presence of unsigned libkeyutils alongside legitimate versions. Updated detection tools were published on the Tor Project mailing list.

The post-mortem: "The root cause was ours"

What makes this incident particularly instructive is not the sophistication of the attack — which is indeed high — but the human vulnerability that enabled it. Operator Zimmer wrote a remarkably candid post-mortem, without seeking scapegoats. "The root cause was ours," he wrote. The same password on everything. Password authentication on an internet-facing server. Master keys that should have been offline, but were in a backup encrypted with the already-compromised password.

The Ebury version 1.8.3 found in this attack has been circulating since at least June 2026. Léveillé, who wrote ESET's 2024 report on Ebury (which compromised nearly 400,000 servers), confirmed on the mailing list that the version found on Tor's servers is consistent with active campaigns. "There are most likely other Ebury-compromised Tor relays out there," he warned.

What remains

This attack raises two lessons that transcend the Tor ecosystem. First, layered security that collapses into a single credential — what audit incidents frequently call "a single point of failure across all layers" — remains the root cause of most unauthorized accesses. Second, 12-year-old backdoors, when deployed in critical infrastructure, remain a real and actively exploited threat.

The Tor network lost 370 exit nodes between October 3 and 5. As of October 18, the number had not recovered. The question is: how many other Tor relays are infected with Ebury today, and how many administrators continue to use passwords to access servers over the internet, unaware that their credentials were already captured months ago?

Sources: The Hacker News, Kaba, SecureWorld

✓ Independent sources cross-checked and verified before publishing