Attackers Hijacked 300+ Tor Exit Relays to Steal SSH Credentials
Researcher kaba found that compromised relays redirected SSH traffic to interception servers between October 1 and 5, capturing passwords from users who accepted unknown host keys.
Key points
- Attackers controlled over 300 Tor exit relays to intercept SSH connections and steal login credentials.
- The Tor Project flagged the malicious relays on October 4, removing them from the network consensus by October 5.
- The attack required users to accept a fraudulent host key presented by the interception servers during the connection.
A researcher identified that attackers hijacked more than 300 Tor exit relays in early October to intercept SSH connections and steal login passwords. According to The Hacker News, the campaign occurred between October 1 and 5, targeting users who connected to SSH servers through the compromised network infrastructure during this specific window.
The attacker gained control of 333 relays that redirected SSH traffic to 12 specific interception servers, as discovered by researcher kaba on October 2. Analysis of public Tor directory data indicates that 377 relays operated by 59 operators switched to the attacker’s exit policy between October 1 and 4. This data represents a policy match rather than definitive proof of compromise for every single relay involved in the redirection scheme.
Technical Mechanics of the Relay Hijack
Exit relays serve as the final hop in a Tor circuit, where encrypted traffic leaves the anonymity network to reach its final destination on the internet. The attackers modified the torrc configuration files on the compromised hosts to rewrite their exit policies. These changes allowed port 22, used for SSH, on 342 relays that had previously blocked it, while also converting 24 non-exit nodes into active exit relays to facilitate the attack.
The configuration changes also closed encrypted mail ports, including IMAPS and POP3S, while opening plaintext-capable ports for POP3 and IMAP on most relays. Tor clients select exit nodes based on whether they allow the destination port, causing traffic to shift away from encrypted mail services toward SSH, Telnet, and plaintext mail through the compromised infrastructure.
Network Response and Impact
The Tor Project’s network health team issued a notice to relay operators on October 5, noting that attackers appeared to be gaining access to Linux-based hosts and editing configuration files to turn them into exits. The project began flagging the malicious relays on October 4, and by October 5, none of the compromised nodes remained in the consensus list used by Tor clients to build circuits.
At the peak of the incident on October 4, the relays carrying the attacker’s exit policy accounted for 7.46% of Tor’s total exit capacity, measured by consensus weight. When an SSH connection was routed through one of these exits, it was directed to an interception server instead of the intended destination, where the server presented its own host key to the user.
Who is affected
Only users who initiated a password login to an SSH server through Tor between October 1 and 5 were at risk of credential theft. The attack succeeded only if the user accepted the host key presented by the interception server, bypassing standard security warnings. Users who employed key-based authentication or who did not connect via the compromised relays during this period were not affected by this specific interception method.
What should you do?
Security professionals should monitor their systems for unusual SSH connection attempts or unexpected host key changes, particularly if their infrastructure relies on Tor for remote access. Organizations using Tor for administrative tasks should review logs for connections made between October 1 and 5 to identify any sessions where users accepted unknown host keys.
What to do and how to stay safe
- Review SSH server logs for connections originating from Tor exit nodes during the October 1-5 window to identify potential credential compromises.
- Enforce key-based authentication for all SSH services to prevent password theft, as this attack specifically targeted password logins.
- Monitor for unexpected changes in host keys when connecting to remote servers, especially through anonymization networks, and reject unknown keys immediately.
- Audit Tor relay configurations if you operate nodes, ensuring exit policies restrict unnecessary ports and that configuration files have not been tampered with.
Step-by-step guide: Social Engineering Warning Signs and How to Respond
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
