Tor Exit Nodes Hijacked by Hackers to Steal SSH Credentials

Key Takeaways

• 333 Tor exit nodes were compromised by attackers to steal SSH credentials and intercept unencrypted email traffic.
• The attackers installed the Ebury 1.8.3 backdoor and credential stealer on the underlying Linux servers.
• The attack primarily relied on users ignoring SSH host key warnings, which indicated a man-in-the-middle attempt.
• Tor Project operators flagged the malicious relays as “BadExit” and shut them down within days of discovery.

Attackers Hijack Tor Exit Nodes to Steal Credentials

A sophisticated campaign has seen threat actors compromise 333 Tor exit nodes, redirecting Secure Shell (SSH) connections to malicious servers designed to harvest user credentials. The operation, which commenced on October 2, also targeted unencrypted email traffic, according to a detailed report published by researcher kaba on October 20, 2026.

The compromised nodes represent a significant portion of the Tor network, accounting for approximately one in ten of the roughly 3,000 exit relays in operation. Investigators believe the attackers initially gained control of the underlying Linux servers in August, subsequently installing Ebury version 1.8.3 – a known OpenSSH backdoor and credential-stealing malware.

How the Attack Unfolded

Tor exit relays are the final point where traffic exits the anonymized network and enters its destination. In this particular incident, the compromised relays allowed encrypted web traffic to pass through normally. However, any SSH connections made over port 22 were covertly rerouted to one of 12 designated interception servers controlled by the attackers.

The discovery of this activity was triggered when an SSH connection displayed a “REMOTE HOST IDENTIFICATION HAS CHANGED” warning. This critical message indicates that the cryptographic key presented by the server does not match the key previously trusted for that host, signaling a potential man-in-the-middle attack.

Users who disregarded this warning and proceeded to authenticate with their passwords inadvertently exposed their credentials to the attackers. Once compromised, the threat actors could then log into the intended server, monitor commands executed during the session, and potentially establish new connections to install further malicious software, including Ebury.

Crucially, this attack did not exploit weaknesses in SSH encryption itself but rather exploited a failure in host verification. The “changed host key” warning was the primary indicator that the connection might no longer be directed to the legitimate server.

The report further detailed modifications to allowed ports on the affected exit nodes. These changes were configured to steer unencrypted mail traffic through the compromised relays, providing the attackers with an additional stream of readable data.

Identifying the Malicious Nodes

To pinpoint the compromised exit nodes, the researcher developed a specialized test utilizing “exitmap,” a tool designed for analyzing Tor exit behavior. The test involved selecting an exit relay and initiating an SSH connection between two controlled servers. One server verified the SSH fingerprint, while the other determined if the incoming connection originated from the chosen exit relay or an interception server. The findings revealed approximately a dozen exits with incorrect fingerprints and over 300 relays routing connections through the same malicious interception infrastructure.

A separate honeypot experiment, employing the “sshesame” tool, reportedly identified Paramiko, a Python SSH library, being used on the attacker’s side. Captured commands revealed that the attackers were checking user privileges and sudo access before attempting to execute a Base64-encoded Perl installer. The presence and behavior of Ebury are consistent with its known capabilities, including credential theft and SSH traffic interception within hosting environments, as previously reported by Cyber Security News concerning infections on over 400,000 Linux servers.

Response and Mitigation

Researcher kaba reported the findings to Tor’s network health team on October 2. Swift action followed, with Tor operators flagging all affected relays with the “BadExit” attribute on October 4. Tor’s “bad-relay” guidelines ensure that any relay marked with “BadExit” is prevented from serving as an exit node, effectively removing it from the network’s exit pool. The Tor Project actively encourages reports of suspicious behavior, requesting relay identifiers and supporting evidence.

Although attackers reportedly attempted to restart several relays on October 5, the “BadExit” flags successfully prevented them from resuming their malicious function as exit nodes. The report concludes that all identified infected servers were shut down later that same day.

The initial method of compromise remains unconfirmed, with a breach at a hosting provider being a plausible, though unverified, theory. Attribution for the attack also remains unresolved. This incident underscores the critical importance of robust relay monitoring within the Tor network, a topic previously highlighted in Cyber Security News’ coverage of Tor’s network safety measures. For SSH users, the paramount lesson from this event is to never bypass host-key warnings and to prioritize the use of SSH keys over password-based logins.

What You Should Do

• Heed SSH Host Key Warnings: Never ignore “REMOTE HOST IDENTIFICATION HAS CHANGED” warnings. Investigate them immediately, as they are a strong indicator of a man-in-the-middle attack.
• Use SSH Keys for Authentication: Replace password-based SSH logins with SSH keys (public/private key pairs). This significantly reduces the risk of credential theft, as the private key never leaves your client.
• Implement Multi-Factor Authentication (MFA): Where possible, enable MFA for SSH access to add an extra layer of security.
• Regularly Audit Server Logs: Monitor SSH access logs for unusual activity, failed login attempts, or connections from unexpected IP addresses.
• Keep Systems Updated: Ensure all operating systems and software, especially OpenSSH and related components, are kept up-to-date with the latest security patches.
• Monitor Tor Relay Health: If you operate a Tor relay, regularly monitor its health and status, and promptly respond to any warnings or flags from the Tor Project.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.