Tor Exit Relays Misconfigured to Intercept SSH Credentials and Email
Attackers reconfigured over 300 Tor exit nodes to redirect SSH sessions and capture plaintext login details from users.
Key points
- More than 300 Tor exit relays were compromised to intercept SSH traffic between October 1 and 5.
- Attackers redirected connections to 12 servers to steal passwords from users who accepted host key warnings.
- The campaign also blocked encrypted email ports while allowing plaintext protocols for potential data theft.
Attackers gained the ability to capture SSH login credentials by hijacking Tor exit relays, according to a researcher known as kaba. The threat actors needed users to connect to SSH servers through the Tor network during a specific window in early October. By redirecting traffic to their own infrastructure, they could present false host keys and harvest passwords from clients that accepted the interception.
How it unfolded
- In late August, attackers used a reused password to access a Tor management server, according to Ars Technica.
- They installed the Ebury backdoor and moved laterally to a second server named Switzerland2 using an RSA key.
- Between October 1 and 4, 377 relays run by 59 operators switched to the attacker's exit policy, according to directory data.
- On October 4, the Tor Project flagged the malicious relays, removing them from the consensus by October 5.
Who is affected
Only users who established SSH connections through Tor between October 1 and 5 are potentially impacted, according to the research. The exposure occurred specifically when a client accepted the host key presented by the interception server. If a user ignored the warning that the host key had changed and proceeded with the login, their password could have been captured.
The fix
The compromised relays were removed from the network consensus by October 5, meaning they no longer route traffic, according to the source material. Users should assume their credentials were compromised if they used SSH over Tor during the attack window. No specific software patch was mentioned in the reports.
What made it possible
This incident illustrates the risk of trusting network intermediaries without verifying their identity at every hop. Teams usually implement strict host-key verification policies to prevent man-in-the-middle attacks during remote sessions. Check whether your security protocols require manual confirmation of new host keys. Relying on default trust models for exit nodes can expose sensitive authentication data to interception if the node is compromised.
What to do and how to stay safe: Tor Project
- Rotate SSH passwords immediately if you connected to servers via Tor between October 1 and 5.
- Review your SSH client configuration to ensure it rejects unknown host keys rather than prompting or accepting them.
- Monitor server logs for successful login attempts from unexpected IP addresses during the attack window.
- Audit your Tor exit relay configurations to ensure they do not allow unnecessary ports like SSH or plaintext email.
Step-by-step guide: DDoS Attack Mechanics: Answers to 10 Critical Questions
General security guidance from the RedTeam Tribune newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Did the attackers successfully steal any data?
The source material does not confirm whether any specific credentials or emails were successfully stolen, only that the interception infrastructure was in place.
How many Tor relays were involved in this attack?
A researcher found 333 relays redirecting SSH traffic, while directory data analysis identified 377 relays run by 59 operators switching to the attacker's policy.
What backdoor did the attackers install on the servers?
According to Ars Technica, the attackers installed Ebury, a Linux backdoor that was discovered 12 years ago, on the compromised management and exit servers.
