Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Passwords
A sophisticated attack saw over 300 Tor exit relays compromised in early October, redirecting SSH connections to malicious servers designed to steal user login credentials.
In a significant network security incident, malicious actors gained control of more than 300 Tor exit relays during the first week of October 2026. These compromised relays were then used to redirect Secure Shell (SSH) connections to attacker-controlled servers, with the primary objective of capturing user login passwords. The attack specifically targeted password-based SSH logins made through the Tor network between October 1st and October 5th.
Exit relays serve as the final point in a Tor circuit, facilitating the connection from the Tor network to the public internet. The attackers exploited this position by altering the exit relays' configuration files, specifically the torrc file. This modification allowed them to enable traffic on port 22, the standard port for SSH, on relays that had previously blocked it. In some instances, relays that were not previously acting as exits were also repurposed.
The scope of the attack was substantial. A researcher, operating under the pseudonym 'kaba', discovered that 333 relays were redirecting SSH traffic to the same 12 malicious interception servers. Analysis of public Tor directory data indicated that at its peak on October 4th, these compromised relays constituted approximately 7.46% of Tor's total exit capacity. The Tor Project's network health team noted that the attackers appeared to be gaining access to Linux-based hosts, modifying their torrc files to turn them into malicious exits.
Beyond enabling SSH traffic, the attackers also closed encrypted mail ports (IMAPS and POP3S) on most affected relays and, in many cases, opened plaintext ports for POP3 and IMAP. This change in traffic handling meant that encrypted mail traffic was no longer flowing through these relays, while SSH, Telnet, and unencrypted email traffic were redirected. The precise reasons for closing the encrypted mail ports remain unclear from the available data.
When an SSH connection was intercepted, the malicious server presented its own host key to the user. Users who had previously connected to the target server would receive an OpenSSH warning indicating that the remote host identification had changed. New users would see the standard prompt to accept a new host key. If a user proceeded to accept the presented key and entered their password, that credential was captured by the interception server. The attacker could then use the stolen password to log into the legitimate server and potentially execute commands, including running a Perl installer that, in at least one observed case, resembled the Ebury backdoor known to hide within OpenSSH.
Crucially, SSH connections authenticated using key pairs were not vulnerable to this specific interception method. The SSH authentication protocol includes a session-specific identifier in the client's signature, rendering a signature generated for the interceptor's session invalid for the actual server. While an attacker could still present a fake shell, they could not establish a legitimate connection to the real server using a stolen key.
The attack was detected on October 2nd when kaba encountered a changed-key warning during an SSH connection over Tor. Using a scanning tool called exitmap, kaba systematically tested each exit relay. His findings were reported to the Tor Project's network health team on the evening of October 2nd. The Tor Project's monitoring systems also flagged the unusual policy changes, and by October 4th, directory authorities began flagging the compromised relays with BadExit and MiddleOnly flags, effectively removing them from the Tor network's consensus by October 5th.
Users who accepted an unfamiliar or changed host key when connecting via SSH over Tor between October 1st and October 5th should treat any passwords entered during that period as compromised. It is recommended to change these passwords immediately and to thoroughly check the affected SSH servers for signs of compromise, such as the presence of the Ebury backdoor or suspicious processes.