If you SSH into servers over Tor, this is worth five minutes of your attention. Between October 1 and October 5, 2026, attackers hijacked more than 300 Tor exit relays and used them to redirect SSH logins to servers built to steal passwords.
Anyone who used SSH over Tor with a password login between October 1 and the afternoon of October 5, 2026, and accepted a changed or unfamiliar host key, should treat that password as stolen. Key-based logins were not exposed the same way, because of how the SSH protocol signs sessions. The rest of this explainer covers what happened, how the interception worked, and what to change in your own setup starting today.
What Happened
Attackers took over more than 300 Tor exit relays in early October 2026 and used them to intercept SSH logins. The Tor Project pulled the affected relays from its network within days, but the campaign shows how much trust Tor’s exit relays quietly hold.
What Did kaba Find on October 2?
A researcher who publishes as kaba noticed the problem on October 2, when an SSH connection over Tor returned a warning that the destination server’s identity had changed. Using exitmap, a scanning tool also used by the Tor Project’s network health team, kaba tested Tor’s roughly 3,000 exit relays one at a time and found 333 redirecting SSH traffic to the same 12 interception servers, as detailed in kaba’s write-up. About a dozen of those exits presented a fake host key during testing, while the rest passed connections through the same infrastructure without altering the key. Kaba reported the findings to the Tor Project’s network health team that same evening and published the full account on October 20.
Why Do Reports Cite Both 333 and 377 Relays?
Two different counts describe this campaign, and they measure different things. Kaba’s scan found 333 relays actively redirecting SSH traffic to the interception servers. A separate directory-data analysis found 377 relays operated by 59 operators that switched to the attacker’s exit policy between October 1 and October 4. The analysis is explicit that matching the policy is not proof of compromise on every one of those relays. At the October 4 peak, the relays running the attacker’s policy made up about 7.46% of Tor’s exit capacity by consensus weight.
How Did the Tor Project Stop the Campaign?
Directory authorities began voting the BadExit and MiddleOnly flags onto the affected relays at 18:00 UTC on October 4, and those flags were in the consensus by 21:00 UTC, which tells Tor clients never to use a flagged relay as an exit. By 17:00 UTC on October 5, no relay carrying the attacker’s exit policy remained in the consensus, according to CyberInsider’s coverage of the removal. None had returned as of several days later. Tor Metrics’ count of exit-flagged relays dropped by about 370 between October 3 and October 5, matching the scale of the removal.
How the Attack Worked
The attackers rewrote each relay’s exit policy to open port 22, the standard SSH port, then routed that traffic to servers they controlled instead of its real destination. The mechanism relied entirely on users accepting a host key they should have rejected.
How Did Port 22 Traffic Reach the Interception Servers?
Each Tor exit relay runs an exit policy in its torrc configuration file that decides which destination ports it will carry. The attackers edited that policy on hundreds of relays to allow port 22, enabling SSH on relays that had previously blocked it, and turned 24 relays that had never been exits into exits. A Tor client builds its circuit and only selects an exit that allows the destination port it needs, so once port 22 was open on these relays, SSH connections through them went to one of the attacker’s 12 interception servers instead of the intended server. A honeypot run by kaba showed the interception servers using Python’s Paramiko SSH library to handle these redirected sessions.
Why Did Accepting a False Host Key Expose Passwords?
An SSH server proves its identity with a host key, and a client that has connected before stores that key and compares it on every later connection. When the interception server took over a session, it presented its own key instead of the real server’s key. A user connecting to a known server saw OpenSSH’s warning that the remote host identification had changed; a user connecting for the first time saw only the ordinary prompt to trust a new fingerprint. Anyone who accepted the false key and then typed a password handed that password straight to the interceptor, which then logged into the real server itself to keep the session working, a textbook man-in-the-middle attack.
Why Could SSH Key Signatures Not Be Replayed?
Key-based SSH logins survived this attack by design. Under the SSH authentication protocol, a client’s signature is bound to a unique identifier for that specific session, so a signature created for a session with the interceptor is worthless against the real server, as scworld’s brief on the campaign also notes. The interceptor could still fake a shell and let a key-based user log in to nothing, but it could not forward that login to the genuine server. A password typed later inside that fake session, for a sudo prompt, for example, could still be captured.
Did the Email Changes Force Connections into Plaintext?
The same configuration changes closed the encrypted mail ports IMAPS and POP3S on most affected relays, while leaving the plaintext-capable POP3 and IMAP ports open. This did not force any encrypted mail session into plaintext. Tor only routes a connection through an exit that allows the requested destination port, so this change only mattered to mail clients already configured to fetch mail without encryption. No report confirms that mail content was actually captured during the campaign.
How the Attacker Got In
The intrusion traces back to a single reused password on one operator’s management server, though how most of the other affected operators were compromised is unknown. The clearest account comes from the operator of the largest affected relay family.
What Is Known About Zimmer’s Management Server?
Zimmer, who ran the Quetzalcoatl relay family, the largest group of affected relays, posted a detailed account after the fact. The attacker logged into his management server, which served as the family’s VPN gateway and SSH jump host, on August 28, succeeding with the operator’s password on the first try and gaining root access within five minutes. About an hour later, the attacker reached a second server, which Zimmer calls Switzerland2, hosted at FranTech Solutions, reportedly using an RSA key that investigators could not find among that server’s authorized keys. Zimmer wrote that “the root cause was ours: 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,” as reported by The Hacker News.
How Did Ebury Help the Intrusion Persist?
On both servers, the attacker installed Ebury 1.8.3, a Linux backdoor and credential stealer for OpenSSH that has been active since 2009. Ebury hides as a single library file, replacing a symlink so that packaged binaries still pass standard integrity checks like dpkg -V, which let it sit undetected while the attacker rewrote exit policies on Switzerland2’s two relays. Version 1.8.3 is newer than the public indicators ESET had previously documented, which stopped at version 1.8.2, prompting ESET researcher Marc-Etienne Léveillé to publish an updated detection script, according to GBHackers’ reporting on the compromise. A routine reboot on October 4 killed the attacker’s active tools, but Ebury itself came straight back because it survives as a persistent backdoor rather than a running process.
What Remains Unknown About the Wider Compromise?
How the other 57 operators behind the 377 flagged relays were compromised has not been established. A hosting-provider compromise is one theory under consideration, but it remains unconfirmed. Who carried out the attack, and how the first password was obtained in Zimmer’s case, are also unknown.
Were You Affected?
You were only potentially exposed if you made an SSH connection over Tor, or an unencrypted email connection over Tor, between October 1 and the afternoon of October 5, 2026, and accepted an interception server’s host key. HTTPS web traffic through Tor was not reported as tampered with during this campaign.
Which Connections Were Potentially Exposed?
The tell for a server you had connected to before was OpenSSH’s warning that the remote host identification had changed. A first-time connection to a server showed only the normal prompt asking you to trust a new SSH fingerprint, with no warning that anything was wrong. If you clicked through either prompt and typed a password during that window, that password should be treated as compromised.
What Should You Do After Accepting an Unverified Host Key?
Change the password everywhere it was reused, since Zimmer’s own password reuse across SSH, sudo, and backup encryption is exactly what let the attacker escalate so quickly. Check the server for Ebury using ESET’s updated detection script; a clean result from a standard package integrity check does not prove the server is clean, since Ebury is built to pass those checks. If the server tests positive, rebuild it from scratch rather than trying to clean it, and rotate every credential that lived on it.
What Should Relay Operators Check and Report?
Relay operators should check Relay Search for exit settings on their own relays that they did not configure, particularly an exit policy that newly allows port 22. Suspicious findings should go to bad-relays@lists.torproject.org, the Tor Project’s reporting channel for mitigating malicious relays. Operators should also look for unfamiliar NAT rules redirecting port 22, unexpected changes to ExitRelay, ExitPolicy, or MyFamily settings in torrc, and systemd units they did not create.
How to Protect Yourself
Switching from password logins to SSH keys removes the one thing this entire campaign depended on. Pairing that with careful host-key verification and encrypted mail settings closes the remaining gaps.
How Do You Switch to SSH Keys and Disable Password Logins?
Generate a key pair and copy the public key to your server:
ssh-keygen -t ed25519
ssh-copy-id user@your-server
A hardware security key adds another layer of protection for the private key itself. Once key-based login works, disable password authentication in /etc/ssh/sshd_config:
PasswordAuthentication no
KbdInteractiveAuthentication no
Check for a cloud-init file under /etc/ssh/sshd_config.d/, since it can silently switch password logins back on after you have disabled them. Confirm the active setting with sudo sshd -T | grep -i passwordauthentication, reload SSH, and keep your current session open until a fresh key-based login succeeds, so you are not locked out if something is misconfigured.
How Do You Verify a Host Key Before Trusting It?
Verify a server’s host key out of band before trusting it, even on the very first connection. Run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub on the server itself over a trusted connection, such as its cloud console, and compare the fingerprint against what your client shows. Never click through a warning that a host key has changed; treat it as a sign of possible interception until you confirm otherwise.
How Can You Keep Passwords and Email Connections Safer?
Use a unique password for every login, sudo included, so a single stolen credential cannot cascade the way it did on Zimmer’s management server. For email, require SSL/TLS: IMAPS on port 993, POP3S on port 995, or mandatory STARTTLS rather than letting a client silently fall back to an unencrypted port.
Tor vs. VPN: Would a VPN Have Stopped This?
A VPN would have kept your traffic off these particular hijacked relays, but it would not have removed the underlying exposure. Using a VPN still means your unencrypted traffic leaves through somebody’s server rather than nobody’s; what changes is who runs that server and whether you chose them.
What Changes When You Use a VPN Instead of a Tor Exit?
Tor’s roughly 3,000 exit relays are run by volunteers you cannot vet, and this campaign proved that even relays with established operator histories can be quietly taken over. A VPN routes your traffic through servers run by a provider you selected rather than an anonymous volunteer. That does not make the server trustworthy by default; it only shifts who is accountable for keeping it that way, and in this very campaign, the attacker’s first foothold was a VPN gateway used to jump between the Quetzalcoatl family’s servers.
Why Do Host Verification and Encryption Still Matter?
A VPN encrypts the path to its own server, but it does not verify the identity of whatever server your SSH client connects to afterward. Host-key verification and key-based authentication still carry the entire weight of protecting an SSH login, VPN or no VPN, because they protect the session at the application layer rather than the network layer. VPNSoEasy runs on WireGuard® for $5 a month with no long-term contract, covering up to 10 devices, and pairs well with key-only SSH and encrypted email as part of a layered setup rather than a substitute for either.
Can an Onion Service Avoid Exit Relays for SSH?
Running an SSH server as a Tor onion service avoids exit relays entirely, since onion services connect client to server without ever routing traffic through an exit. For administrators who need to reach servers over Tor specifically for anonymity, that setup sidesteps this entire class of attack, because there is no exit relay in the circuit to hijack.
Frequently Asked Questions
Is Tor still safe to use?
Tor remains safe for the anonymity it is built to provide, and this campaign was removed from the network within days of detection. The incident is a reminder that exit relays are run by volunteers and can be compromised, so protocols like SSH and HTTPS need their own verification to stay safe regardless of which relays carry them.
Does a VPN protect SSH logins?
A VPN protects the network path to its own server, not the identity of the SSH server you connect to afterward. Protecting an SSH login against a man-in-the-middle attack still depends on host-key verification and key-based authentication, not on whether a VPN is in the path.
How do I know if my SSH password was stolen?
If you connected to an SSH server over Tor between October 1 and the afternoon of October 5, 2026, and your client showed a changed host-key warning or a new-key prompt that you accepted, and you then typed a password, treat that password as stolen. Check your known_hosts file for entries added during that window as a starting point.
Were encrypted email and HTTPS traffic exposed?
HTTPS web traffic was not reported as tampered with during this campaign. The configuration changes closed encrypted mail ports on most affected relays while leaving unencrypted mail ports open, but this only exposed mail clients already configured to fetch mail without encryption, and no report confirms that any mail content was actually captured.
Can SSH keys protect me from a fake server?
Yes. An SSH key signature is bound to the unique identifier of the session it was created for, so it cannot be replayed by an interceptor to a real server, unlike a password, which the interceptor can read and reuse directly.
