Tor Exit Node Policy Flaws Enabled SSH Redirects and Plaintext Email Exposure

Adversaries compromised more than 300 Tor exit relays in early October to intercept SSH connections and potentially capture plaintext email credentials. Security researchers found that the attackers altered relay configurations to redirect traffic to servers under their control, targeting users who accepted altered host keys.

What happened

According to The Hacker News, a researcher identified 333 Tor exit relays redirecting SSH traffic to 12 interception servers on 2 October. Directory data analysis posted to the tor-relays mailing list indicates 377 relays operated by 59 operators switched to the attacker’s exit policy between 1 and 4 October. The Tor Project flagged these relays on 4 October, removing them from the client consensus by 5 October. At peak capacity on 4 October, these relays represented 7.46% of Tor’s exit weight, according to the directory analysis.

Why it matters

The attackers rewrote torrc configuration files on the compromised relays to allow port 22, enabling SSH access on 342 nodes that previously blocked it. Another 24 relays were converted from non-exit status to exit status, as noted by the Tor Project’s network health team on 5 October. Ars Technica reports that the intrusion began in late August when an attacker reused a password to access a Tor management server and installed the Ebury Linux backdoor.

Next steps

• Monitor for unexpected changes in SSH host keys when connecting through Tor circuits.
• Review relay exit policies for unauthorized openings of port 22 or plaintext email ports.
• Verify that encrypted email ports (IMAPS/POP3S) remain active and are not blocked on managed relays.
• Audit access logs on management servers for reused credentials or unusual SSH authentication attempts.

Detection notes

Security operations teams should monitor for anomalous host key presentations during SSH sessions, particularly when users report warnings about key mismatches. Check network logs for traffic redirection patterns where expected destinations are replaced by unknown IP addresses. Inspect configuration files for unauthorized modifications to exit policies, specifically looking for newly opened ports that were previously blocked. Review authentication logs on internal servers for failed login attempts originating from unexpected geographic locations or IP ranges associated with known interception infrastructure.

What to do and how to stay safe: Tor

• Rotate SSH passwords for any accounts accessed via Tor between 1 and 5 October if host key warnings were accepted.
• Enforce key-based authentication for SSH services to mitigate risks from password interception.
• Monitor email servers for connection attempts from known Tor exit IPs using plaintext protocols.
• Verify the integrity of torrc files on any servers acting as Tor relays or management nodes.

Step-by-step guide: How to Prevent Account Takeover: The Technical Controls That Actually Work

General security guidance from the Packet Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which ports were affected by the relay misconfigurations?

Attackers opened port 22 for SSH and plaintext email ports (POP3, IMAP), while blocking encrypted email ports 25, 465, 587, 993, and 995.

How did the attackers initially gain access?

According to Ars Technica, the attacker reused a valid password to access a Tor management server and installed the Ebury backdoor.

Are the compromised relays still active in the Tor network?

No, the Tor Project removed all affected relays from the consensus list by 5 October, according to the source material.