Attackers Hijacked 300+ Tor Exit Relays to Steal SSH Credentials

Attackers Hijacked 300+ Tor Exit Relays to Steal SSH Credentials

A researcher has uncovered a coordinated campaign in which attackers seized control of more than 300 Tor exit relays and used them to intercept SSH connections, redirecting victims to rogue servers designed to harvest login passwords. The activity, reported by The Hacker News, took place during a narrow window in early October and highlights a long-standing but often overlooked risk in relying on anonymity networks for security rather than privacy.

What exit relays do — and why they matter here

Tor routes traffic through a circuit of relays so that no single node knows both who the user is and where they are going. The exit relay is the final hop, where traffic leaves the anonymity network and reaches its destination on the open internet. Because the exit node handles traffic in the clear at that boundary, anyone who controls it can observe or manipulate unencrypted protocol metadata — and, in some cases, redirect connections entirely.

That is precisely what happened here. Rather than passively snooping, the operators of the malicious relays actively rerouted SSH sessions to infrastructure they controlled.

How the interception worked

According to the findings, the attackers positioned their relays so that SSH connections passing through them were redirected to attacker-operated servers impersonating the intended destination. Those fake servers then presented login prompts to capture usernames and passwords. Because the scheme targeted password-based authentication, users who connected to SSH servers over Tor and typed credentials into the spoofed prompt effectively handed them over.

The campaign was tightly time-boxed. The malicious activity is reported to have occurred between October 1 and 5, and the interception is described as affecting connections made after a user accepted the connection — a reminder that the familiar host-key verification prompt is a security control, not a formality.

Why SSH over Tor is a tempting target

SSH is the backbone of remote administration for servers, network devices, and cloud infrastructure. Administrators sometimes route SSH through Tor to hide the source of their connections, to reach hosts from restrictive networks, or to add a layer of obfuscation. But anonymity and confidentiality are different properties. Tor protects who is connecting; it does not, by itself, guarantee what server you are actually talking to.

SSH does provide that guarantee through host-key verification. When a client connects to a server for the first time, it records the server's public key fingerprint; on subsequent connections it compares the presented key against the stored one. If an attacker substitutes their own server, the key will not match — unless the user ignores the warning or is connecting to a host for the first time and accepts an unfamiliar fingerprint without validating it out of band.

Practical lessons for defenders

• Prefer key-based authentication. Password logins are the commodity the attackers were after. Disabling password authentication in favor of SSH keys removes the payoff from this class of interception.
• Verify host keys out of band. Confirm fingerprints through a trusted channel — documentation, a configuration management system, or a direct conversation — rather than trusting whatever prompt appears.
• Treat host-key warnings as incidents. A changed key on a known host can indicate interception, a rebuild, or a compromise. Investigate before proceeding.
• Consider whether Tor is the right tool. If the goal is reaching internal hosts, a VPN or bastion/jump host with strong authentication is usually a better fit than an anonymity network whose exit nodes are operated by unknown parties.
• Audit for exposure. Organizations should determine whether any administrative access paths depend on Tor exit traffic, and rotate credentials for any SSH accounts that may have been used over the network during the affected window.

The bigger picture

The incident underscores a structural reality of Tor: exit relays are run by volunteers and other unknown operators, and the network's threat model explicitly accounts for the possibility that an exit node is hostile. Tor provides anonymity, not end-to-end integrity against a malicious exit. Protocols that encrypt end to end — such as SSH with proper host-key verification, or HTTPS with certificate validation — are designed to survive a compromised exit, but only if users and tooling actually enforce those checks.

For security teams, the takeaway is straightforward: the strength of a connection depends on the weakest link in its authentication chain, and a password typed into an unverified prompt is only as trustworthy as the relay that carried it.

Source: The Hacker News — Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections