The SSH Warning That Exposed 333 Tor Nodes

On October 2, 333 compromised Tor exit relays began redirecting SSH connections through 12 interception servers, representing roughly 10% of the network’s exit relays. Though a smaller share of its total bandwidth, this coordinated campaign effectively weaponized a significant portion of the anonymity network.

The trap was insidious: normal web traffic passed through untouched, but SSH traffic on Port 22 was altered. Users attempting an SSH connection would unknowingly be funneled to one of the 12 interception servers, triggering a critical warning: “Remote host identification has changed.”

Many developers, accustomed to dismissing such prompts, likely clicked through. But ignoring this alert and proceeding with password authentication exposed their credentials, logged every command typed, and facilitated the deployment of Ebury, an OpenSSH backdoor and credential stealer, onto their servers.

The warning itself is the linchpin. SSH host keys allow a client to verify a server’s identity; a mismatch can signal benign events, like a legitimate server rebuild. However, it is an equally potent indicator of an active man-in-the-middle attack. This incident unequivocally demonstrated that this prompt should never be treated as routine or clicked through without rigorous investigation.

Attackers laid their trap well in advance, compromising relay hosts in August and installing Ebury, a Linux backdoor and credential stealer. They then modified torrc policies on 342 relays to explicitly allow port 22, converting at least 24 non-exit relays into exit nodes. This allowed SSH traffic to exit through relays that would not ordinarily carry it, rerouting connections to one of 12 dedicated SSH interception servers.

When a victim encountered the Remote host identification has changed warning and accepted the substituted SSH key, the consequences were swift and severe. Logging in with a password triggered a multi-pronged attack:

• Credential theft
• Comprehensive command monitoring
• An automated attempt to open a second SSH session to the destination server and install Ebury, often via base64-encoded installers with sudo privileges.

This incident did not imply Tor encrypted or exposed every connection; the network provides routing anonymity, not end-to-end protection. Tor routes standard web traffic (ports 80/443) untouched. SSH host verification remains the critical safeguard against an exit relay impersonating the destination, a defense that 333 compromised relays—representing 10% of Tor’s exit nodes and 7.46% of its total exit bandwidth—exploiters subverted.

That SSH warning, "Remote host identification has changed," usually gets a shrug and a click. This time, one researcher, kaba, saw it as a call to action. Instead of dismissing the unexpected fingerprint, kaba leveraged ExitMap, a specialized Tor exit relay scanner, to systematically test the network.

Kaba’s methodology was elegant: connect between two controlled servers, routing traffic through each Tor exit relay, and check for altered SSH fingerprints. This systematic approach proved critical. It allowed kaba to distinguish a coordinated, widespread interception campaign from isolated server rebuilds or simple misconfigurations, confirming the attack's unprecedented scale. For those interested in network analysis, Exitmap: Fast and Modular Tor Exit Relay Scanner offers a deeper dive into this powerful tool.

By October 4, Tor’s network health team had flagged the malicious relays as BadExit. They were swiftly removed from the active network consensus by October 5. The Tor team assessed this as an unprecedented attack, a testament to its sophistication, rather than a fundamental flaw in Tor’s architecture. The incident highlights the critical role independent researchers play in maintaining network integrity.

That "Remote host identification has changed" warning is not a suggestion; it is an alarm. When an SSH host key changes, stop. Verify the new fingerprint through an out-of-band channel you trust, then—and only then—update your known_hosts file. Never blindly delete the old key or accept a replacement without confirmation; that’s precisely how the Ebury attackers harvested credentials.

Disable password-based SSH authentication wherever possible. Public-key authentication significantly reduces the risk of password theft, but it does not make host identity checks optional. Strong key management, ideally with hardware security modules, further hardens your posture, yet a compromised host key remains a critical threat.

Operators must integrate these lessons into their workflows. Review unexpected SSH access and authentication logs immediately. Check for unfamiliar processes or modified OpenSSH components—Ebury 1.8.3 can be stealthy. Investigate suspected Ebury infections using ESET’s research for indicators of compromise, and consult kaba’s write-up for deeper incident details.

This attack on 333 Tor nodes was a stark reminder: security is a chain, and user habits are often its weakest link. Make that SSH warning a stop sign, not a speed bump.

What happened in the Tor SSH attack?

Attackers used compromised Tor relays to redirect SSH connections through interception servers, where they could steal credentials from users who ignored host-key warnings.

Did the attack compromise all Tor traffic?

No. The reported campaign targeted SSH connections, while ordinary web traffic was passed through. Tor does not replace end-to-end encryption or SSH host verification.

What is Ebury?

Ebury is a Linux backdoor and credential-stealing malware family associated with OpenSSH tampering and the spread of infections across servers.

How can I protect SSH connections?

Reject unexpected host-key changes until verified through a trusted channel, use SSH keys, and disable password-based SSH authentication where possible.

What is ExitMap?

ExitMap is a tool for scanning Tor exit relays, used by researcher kaba to identify relays that altered SSH connections.