Attackers gained control of more than 300 **Tor** exit relays in early October, leveraging them to redirect SSH connections and harvest login passwords. This infiltration, discovered by researcher **kaba**, underscores a significant security event within the **Tor** network. Exit relays represent the final hop in a **Tor** circuit, where encrypted traffic exits the anonymous network for its intended destination. The compromise specifically targeted SSH connections made through **Tor** between October 1 and 5, impacting users who accepted the interception server's fraudulent host key. **The Tor Project** initiated flagging these malicious relays on October 4. By October 5, none of the compromised relays remained in the consensus – the authoritative list of relays used by **Tor** clients. At its peak on October 4, the attacker-controlled relays constituted 7.46% of **Tor**'s total exit capacity, as detailed in an [analysis of public Tor directory data](https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/message/Z2B6XYKJZBBQADU77MSNL6FJP7MHZHIV/) posted to the tor-relays mailing list. **kaba**'s independent scan of approximately 3,000 **Tor** exits on October 2 identified 333 relays redirecting SSH traffic to the same 12 interception servers. The directory data analysis further indicated 377 relays, operated by 59 distinct entities, switched to the attacker's exit policy between October 1 and 4. ## How the Hijacked Exits Intercepted SSH An exit relay's traffic handling is governed by its exit policy. The attackers manipulated this policy within the relays' `torrc` configuration files, specifically opening port 22 (the standard SSH port) on 342 relays that previously blocked it. Additionally, 24 relays that were not previously exits were reconfigured to act as such. > "It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack," the **Tor Project**'s network health team stated in their [October 5 notice](https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/) to relay operators. Coinciding with the SSH port opening, the attackers also closed encrypted mail ports (IMAPS and POP3S) and, on most affected relays, opened their plaintext counterparts (POP3 and IMAP). This shift meant these relays ceased carrying encrypted mail traffic and began facilitating SSH, Telnet, and often plaintext mail connections. When an SSH connection passed through one of these compromised exits, it was routed to one of the 12 interception servers instead of its legitimate destination. Users attempting to connect would be presented with the interceptor's own host key. Those familiar with the real server's key would receive an **OpenSSH** warning about a changed host identification, while first-time users would see a prompt to accept a new key. In **kaba**'s October 2 scan, a dozen exits were serving fake host keys, while the remaining 300-plus redirected through the same servers without altering the key. A user who accepted the fraudulent key and entered their password effectively handed their credentials to the interceptor. The interceptor would then establish a connection to the real server, making the session appear legitimate. This allowed the attackers to monitor commands, and potentially use the stolen password to gain further access, including deploying a base64-encoded Perl installer, similar to the method used to install **Ebury** – a known **OpenSSH** backdoor – on one of the affected relay operator's servers. It's important to note that key-based SSH logins were not vulnerable to this interception method. The **SSH authentication protocol** ([RFC4252](https://datatracker.ietf.org/doc/rfc4252/)) ensures that a client's signature includes a unique session identifier, rendering a signature generated for the interceptor's session useless against the real server. However, passwords, transmitted within the encrypted session, could be read by the intercepting server.  ## Who Was Exposed, and What to Do If You Were Exposure to this attack required a specific chain of events: connecting to an SSH server over **Tor** between October 1 and the afternoon of October 5, being routed through one of the hijacked exits, having the connection intercepted, accepting the interceptor's host key, and logging in with a password. The total number of victims remains unknown. If you accepted an unfamiliar or changed host key over **Tor** during the specified period, it is crucial to assume your password has been compromised. Immediately change the affected password and thoroughly inspect the server for signs of the **Ebury** backdoor (detailed below). An **OpenSSH** client that accepted the malicious key would have saved it in its `known_hosts` file. The interception server encountered by **kaba** utilized an **ED25519** key with the fingerprint `SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E`, though other interception servers may have used different keys. ## How It Was Found and Stopped **Kaba** discovered the attack on the morning of October 2 when an SSH connection over **Tor** triggered a changed-key warning. He then used `exitmap`, a scanning tool also employed by **The Tor Project**'s network health team, to systematically test SSH connections through each **Tor** exit. His findings were reported to the health team that same evening. **The Tor Project**'s health team also independently detected the policy changes through their monitoring. On October 4, they contacted **Zimmer**, operator of the **Quetzalcoatl** relay family – the largest group of affected relays. **Zimmer** confirmed the unauthorized changes, requested the relays be marked as bad, and subsequently shut down **Tor** on the compromised servers. Directory authorities began voting the `BadExit` and `MiddleOnly` flags on affected relays at 18:00 UTC on October 4, with these flags integrated into the consensus by 21:00 UTC. The `BadExit` flag instructs **Tor** clients never to use a relay as an exit. On the morning of October 5, a scripted restart re-enabled **Tor** with the malicious policy on 55 of **Quetzalcoatl**'s hosts; the perpetrator of this restart is unknown. By this point, directory authorities were rejecting affected relays from the network. The two relays **Zimmer** had stopped were subsequently refused reconnection, he reported. By 17:00 UTC on October 5, no relay with the attacker's policy remained in the consensus, and this status held as of October 9, according to the directory-data analysis. Forty-one relays, including nine from **Quetzalcoatl**, were still publishing the malicious policy but were no longer listed in the consensus. **Tor Metrics** show a drop of approximately 370 relays carrying the `Exit` flag between October 3 and 5, aligning with the number of affected relays, a number that had not recovered by October 18. ## Ebury, and How the Attackers Got In **Zimmer** provided a [post-mortem](https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/QHRD6YOX6RZRDR7NCHNDO7GLCEA6VFM6/) on October 7, detailing his experience. Two of his servers, a management server at **Contabo** acting as a VPN gateway and SSH jump host, and a **FranTech VPS** named **Switzerland2** running two exits, were found to be running **Ebury** version 1.8.3. **Ebury** is a long-standing backdoor and credential stealer for **OpenSSH**, active since 2009. **ESET** estimated in 2024 that **Ebury** had infected [400,000 servers](https://thehackernews.com/2024/05/ebury-botnet-malware-compromises-400000.html), with over 100,000 still compromised in late 2023. Attackers gained initial access to the management server on August 28, successfully logging in with the operator account's password on the first attempt. They achieved root access within five minutes, installed **Ebury**, and then proceeded to install it on **Switzerland2** roughly an hour later. **Zimmer** attributed the root cause to his own operational security: "one password reused for SSH login, sudo and the backup passphrase, stored in plaintext on both servers, plus SSH password authentication left enabled on the internet-facing management server." The method by which the attackers obtained this password remains unknown. **Ebury**'s backdoor logins are designed to leave no trace in system logs. On October 2, the configuration files of the compromised exits were rewritten without any recorded login or `sudo` commands, indicating the stealthy nature of the attack.