News

A tenth of Tor's exit capacity was hijacked to steal SSH passwords

A researcher showed that 333 exit relays redirected SSH connections to criminal servers. The Tor Project removed the relays within three days.


Published on · 2 min read

Illustration of a layered onion connected to network nodes, one of them red, hooking the password from an SSH terminal.
Illustrative image.

The Tor network protects the anonymity of people browsing, but it depends on volunteer computers called relays. A researcher found that some of them were in criminal hands, redirecting SSH connections to steal passwords.

What happened

According to SecurityWeek, the discovery came from a researcher whose own SSH session was intercepted while using Tor. In all, 333 exit relays, about a tenth of all exits on the network, sent SSH connections to about a dozen attacker-run servers. Those servers captured the passwords of people who ignored SSH’s warning. The criminals then tried to infect the servers those users logged into with Ebury, a known malware.

The relays ran on machines already compromised with Ebury, and their exit policies were changed to block secure email retrieval ports and allow plaintext ones. The Tor Project removed the relays within three days, and the researcher’s post is dated October 20, 2026. The report says the Tor Project did not respond to a request for comment. One affected server operator traced their own breach to a reused password.

The warning that saved those who paid attention

The attack only worked on people who ignored an alert. SSH warns when a server’s identity has changed, and the attack depended on the user pressing on anyway. Stopping at that warning cuts the theft at the source.

Who is at risk

The main target is server administrators who reach machines over SSH through Tor. For people who only browse over Tor, the report does not describe a direct risk.

How to protect yourself

  1. Never ignore SSH’s changed-key warning. Check with whoever runs the server before continuing.
  2. Use an SSH key instead of a password. If you do not type a password, there is nothing to lose to this kind of interception.
  3. Do not reuse passwords across servers. That is how one of the affected operators was breached.
  4. Avoid reaching admin servers over networks you do not control, including exit points of anonymity networks.
  5. Turn on two-step verification wherever the service offers it.

Original source