The Tor Project has blocked hundreds of compromised relays after attackers used them to redirect SSH connections through interception servers, steal passwords, and attempt to infect destination systems with the Ebury Linux backdoor.
Researcher Kaba disclosed the investigation on October 20, reporting 333 exit relays involved in the operation. The discovery began on October 2, when an SSH connection through Tor triggered a warning that the destination server’s identity had changed.
Tor routes connections through volunteer-operated relays to conceal users’ IP addresses. Exit relays connect to destinations on the public internet, where application-level encryption and server authentication remain essential.
SSH interception across hundreds of Tor relays
Kaba tested roughly 3,000 exits using exitmap, checking both the SSH host key presented to a client and the connection’s source address at a controlled destination. Around a dozen supplied an incorrect key, while more than 300 others forwarded connections through the same interception infrastructure.
The researcher identified 12 interception servers and notified Tor’s network health team that evening.
According to Kaba, users who accepted the substituted host key and authenticated with a password exposed their credentials to the attackers. The interception system could then relay commands to the real server while opening another connection to attempt an Ebury installation.
A honeypot revealed the use of Python’s Paramiko SSH library and an installation sequence that checked privileges before attempting to execute a base64-encoded Perl payload through sudo. Successful installation would depend on the access obtained.
The Tor Project’s October 5 advisory confirmed that hacked Linux hosts were intercepting SSH traffic. Attackers had also changed configurations to turn some non-exit relays into exits.
A separate analysis by Tor at 1AEO identified 377 relays across 147 IP addresses and 59 operator contact identities that published either of two suspicious exit policies. That broader count reflects policy matches, rather than independently confirmed infections.
The analysis found that 24 previously non-exit relays became exits. At their peak, relays carrying the suspicious policies represented about 7.46% of usable exits’ consensus weight, a network weighting measure rather than a count of intercepted connections.
Many affected relays allowed SSH and the POP3/IMAP ports used for potentially unencrypted mail retrieval while blocking dedicated TLS mail ports. This did not force encrypted mail sessions into plaintext: Tor selects an exit that permits the requested destination port, and POP3/IMAP connections can also upgrade to TLS.
By October 5 at 17:00 UTC, no relay still publishing either suspicious policy remained in the network consensus, according to the analysis, which covered data through October 9.
Ebury infections and unresolved entry points
Quetzalcoatl operator Zimmer’s investigation confirmed Ebury 1.8.3 on two servers. An attacker accessed the management host on August 28 using a password reused for sudo and an encrypted backup, and stored in a plaintext script.
The implant used an unowned libkeyutils library and a redirected symlink, allowing packaged binaries to pass integrity checks. How the wider group of operators was compromised remains unresolved; a hosting-provider breach is an unconfirmed theory.
Users should verify unexpected SSH host-key changes independently and use key-based authentication. Relay operators should audit published policies and port-22 redirection rules. Tor advises taking compromised hosts offline, preserving evidence, rebuilding, replacing relay identities, and rotating every credential held on the server.
Leave a Reply