Large-Scale Tor Exit Relay Takeover Exposes SSH Connections to Interception Risks

Security researchers have uncovered a large-scale attack against the Tor network in which threat actors gained control of hundreds of Tor exit relays and leveraged them to intercept SSH traffic, potentially exposing user credentials and enabling further compromise of targeted systems.

Hundreds of Tor Relays Weaponized

In early October, attackers manipulated more than 300 Tor exit relays, the final nodes through which traffic exits the Tor network and reaches its intended destination. By altering relay configurations, the operators redirected SSH connections to attacker-controlled servers designed to capture login credentials.

The attack window lasted between October 1 and October 5. Users were only at risk if they initiated SSH connections through Tor during that period, connected through one of the compromised exit relays, accepted a spoofed host key, and authenticated using a password rather than SSH keys.

After discovering the activity, the Tor Project moved quickly to identify and remove the malicious relays. By October 5, all affected relays had been eliminated from the Tor consensus, preventing Tor clients from selecting them for network traffic.

How the SSH Interception Worked

The attackers modified exit relay configurations to permit outbound traffic on port 22, the standard SSH port. Many of the impacted relays had previously blocked SSH traffic or had not functioned as exit relays at all.

Researchers observed that compromised systems had their Tor configuration files altered to:

• Enable SSH traffic through port 22
• Convert non-exit relays into exit relays
• Disable encrypted email ports such as IMAPS and POP3S
• Redirect traffic toward attacker-controlled infrastructure

This manipulation ensured the relays would attract SSH traffic while reducing support for encrypted email services.

When victims attempted SSH connections through these relays, traffic was silently diverted to one of twelve interception servers controlled by the attackers. These servers presented fraudulent SSH host keys, triggering warnings that many users may have ignored or accepted.

If a user approved the rogue host key and entered a password, the attackers could capture the credentials while transparently proxying the session to the legitimate destination server. As a result, victims often experienced a seemingly normal login while their passwords were being harvested in real time.

Password Logins Were the Primary Target

The interception method was particularly effective against password-based SSH authentication.

SSH key authentication remained largely protected because SSH signatures are uniquely tied to each session. An attacker positioned between the user and the target server cannot reuse those signatures to authenticate to the actual host.

Password authentication, however, provided a direct opportunity for credential theft because the interception server could read the password before forwarding the connection to the intended destination.

Researchers noted that attackers also monitored sessions after successful logins and attempted to determine whether compromised accounts possessed administrative privileges.

Discovery of the Campaign

The operation came to light when security researcher kaba encountered an unexpected SSH host-key warning while using Tor.

To investigate, the researcher scanned roughly 3,000 Tor exit nodes using the Exitmap testing framework and discovered hundreds of relays redirecting SSH traffic to the same attacker-controlled infrastructure.

Further analysis revealed:

• 333 relays actively redirecting SSH traffic
• 377 relays associated with the malicious exit policy
• 59 separate relay operators impacted
• Up to 7.46% of Tor's exit-node capacity affected at the peak of the campaign

While matching exit policies do not conclusively prove every relay was compromised, the scale of the activity strongly pointed to coordinated unauthorized access.

Tor Project's Response

The Tor Project's network health team identified unusual relay policy changes and began flagging suspicious nodes on October 4.

Working alongside relay operators, directory authorities quickly applied special BadExit designations, ordering Tor clients to avoid the compromised relays entirely.

Some relay operators confirmed the modifications were unauthorized and immediately shut down affected systems. By the evening of October 5, all known malicious exit relays had been removed from active service.

Links to the Ebury Backdoor

Investigation into several compromised relay servers uncovered traces of Ebury, a long-running Linux malware family known for targeting OpenSSH.

Ebury functions as both a backdoor and credential-stealing platform. Once installed, it can:

• Capture SSH credentials
• Conceal attacker logins
• Maintain persistent unauthorized access
• Evade traditional system auditing mechanisms

One heavily affected relay operator discovered Ebury on a management server and an associated relay host. The attackers reportedly gained access using valid credentials, escalated privileges, and deployed the malware before modifying Tor configurations.

The compromise highlighted several operational security weaknesses, including password reuse, plaintext credential storage, and internet-exposed SSH password authentication.

Signs of Compromise

Affected systems may display indicators such as:

• Unauthorized changes to Tor exit policies
• Unexpected SSH port redirections
• Unknown scheduled tasks or services
• Suspicious NAT rules targeting port 22
• Unrecognized user accounts or SSH keys
• Hidden processes masquerading as legitimate system services
• Presence of modified libkeyutils libraries associated with Ebury

Security researchers also identified attacker-controlled infrastructure, rogue SSH keys, and malicious host-key fingerprints connected to the operation.

Who Was at Risk?

Exposure was limited to users who:

1. Connected to an SSH server via Tor between October 1 and October 5.
2. Traversed one of the compromised exit relays.
3. Accepted a changed or unfamiliar SSH host key.
4. Logged in using a password.

Users who met those conditions should assume their credentials were compromised, immediately change passwords, review server access logs, and inspect affected systems for signs of malware deployment.

Recommended Actions for Relay Operators

The Tor Project advises relay operators to:

• Take potentially compromised relays offline.
• Preserve forensic evidence and logs.
• Reinstall operating systems rather than attempting cleanup.
• Generate new relay identities and cryptographic keys.
• Rotate all credentials stored on affected systems.
• Review exit-policy settings for unauthorized modifications.
• Scan for Ebury and other SSH-focused malware.

Researchers caution that Ebury infections can survive routine remediation efforts and may remain hidden even after system reboots, making full reinstallation the safest recovery option.

Key Takeaway

The incident demonstrates how compromising a relatively small percentage of Tor's exit infrastructure can create significant opportunities for credential theft. By targeting SSH traffic and relying on users to trust unfamiliar host keys, attackers were able to transform hundreds of relays into an espionage platform aimed at harvesting passwords and potentially deploying persistent Linux malware on downstream systems.