Attackers hijacked 333 Tor exit relays in early October 2026, redirecting Secure Shell (SSH) connections through 12 interception servers to steal passwords and potentially deploy malware. Researcher kaba discovered the operation on October 2, while separate analysis identified 377 relays operated by 59 operators that had adopted the attackers' exit policy. The malicious configuration represented 7.46% of Tor's exit capacity at its October 4 peak.
Attackers Modified Relay Configurations
Tor exit relays forward traffic to destinations outside the network. Attackers modified the relays' "torrc" configuration files to permit connections over port 22, enabling SSH on 342 relays that previously blocked it and converting another 24 non-exit relays into exits.
The changes also blocked encrypted email ports while permitting plaintext-capable IMAP and POP3 connections on most affected relays. This potentially exposed unencrypted email retrieval, although investigators have not established whether attackers successfully captured messages.
Kaba discovered the campaign after an SSH connection through Tor triggered a warning that the remote host's identity had changed. Using exitmap, the researcher tested approximately 3,000 exit relays by routing SSH connections between controlled servers. The investigation identified 333 relays redirecting connections to the same 12 interception servers. Around a dozen presented fraudulent host keys directly, while the others redirected traffic without altering the key themselves.
The interception servers presented their own SSH host keys before connecting to the legitimate destinations. Users who accepted unfamiliar keys and entered passwords exposed their credentials. Attackers could then observe commands, check administrative privileges and attempt to install a Base64-encoded Perl payload.
Public-key authentication could not be transparently relayed in the same way because SSH authentication signatures are tied to individual sessions. However, users who accepted a malicious key could still be deceived into interacting with an attacker-controlled shell.
Ebury Backdoor Reveals an Earlier Intrusion
The Tor Project's Network Health team warned relay operators on October 5 that attackers appeared to be compromising Linux hosts and changing their configurations.
In an October 7 post-mortem, operator Zimmer confirmed Ebury version 1.8.3 on two Quetzalcoatl relay-family servers. The attacker had accessed a management server on August 28 using the operator's password, obtained root privileges within five minutes and installed Ebury. Approximately an hour later, the attacker compromised a second server, Switzerland2.
Zimmer attributed the initial intrusion to password reuse across SSH, "sudo" and backup encryption, with the password also stored in plaintext. SSH password authentication remained enabled on the internet-facing management server.
Ebury is a Linux backdoor and credential stealer associated with OpenSSH compromises since 2009. ESET estimated in 2024 that it had infected approximately 400,000 servers, with more than 100,000 still infected in late 2023.
The implant masqueraded as "/usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2", with "libkeyutils.so.1" pointing to the malicious file. Because the packaged library remained untouched, conventional integrity checks such as "dpkg -V" and "debsums" could miss it. ESET researcher Marc-Etienne Léveillé subsequently confirmed that version 1.8.3 had existed since at least June 2026 and published an updated detection script.
Investigation Leaves Unresolved Questions
On October 4, Tor directory authorities began applying BadExit and MiddleOnly flags to affected relays. BadExit prevents clients from selecting a relay to exit the network. By 17:00 UTC on October 5, no relay carrying the malicious policy remained in the consensus used by Tor clients.
A scripted restart subsequently affected 55 Quetzalcoatl hosts, but authorities rejected affected relays attempting to rejoin. Tor Metrics recorded approximately 370 fewer exit-flagged relays between October 3 and 5.
Investigators have not established how attackers accessed the other 58 operators' systems. Directory analysis found that 71 of 101 affected relays hosted by FranTech Solutions, associated with BuyVM, adopted the malicious policy, compared with 13 of 9,054 hosted elsewhere. This concentration raises questions about hosting-level access but does not prove the provider was compromised.
The campaign's attribution, the number of infected hosts and the number of exposed users remain unknown.
Indicators and Remediation
Operators should inspect "torrc" and included files for unauthorized changes to "ExitRelay", "ExitPolicy", "ContactInfo", "MyFamily" and "Nickname". Other indicators include unfamiliar listening processes, outbound connections, NAT rules redirecting port 22, unauthorized SSH keys, unexpected scheduled tasks and suspicious system services.
Additional Ebury indicators include the abstract UNIX socket "@event-0YsOG9WSOE", a disguised "/sbin/rsyslogd" process and the IP address "185.225.226[.]62", associated with the initial intrusion into Zimmer's management server.
Anyone who accepted an unfamiliar SSH host key and entered a password through Tor between October 1 and October 5 should treat that credential as compromised, change it and investigate the destination server.
Suspected infected hosts should be taken offline, forensic evidence preserved and systems reinstalled rather than merely cleaned. Operators should replace exposed credentials, generate new relay identities and report findings to the Tor Project's bad-relays mailing list.
The incident demonstrates that Tor's traffic-routing protections cannot guarantee the authenticity of a destination connection when a malicious exit intercepts it. Verifying SSH host keys, disabling password authentication where practical and maintaining unique credentials are essential defenses.
