Hackers Hijack Hundreds of Tor Exit Relays to Steal SSH Passwords

Attackers took over hundreds of Tor exit relays in early October. Then they used those relays to steal passwords from people logging in to remote servers. A researcher who goes by “kaba” spotted the attack on October 2. By October 5, the Tor Project had removed the affected relays. Risky Bulletin called it one of Tor’s largest security incidents.

Using Tor Nodes Made the Campaign Stealthy

Tor hides your location by passing traffic through several relays. The last one, the exit relay, sends your data to its destination.

First, the attackers broke into Linux servers that host relays, the Tor network health team wrote in an October 5 notice to node operators. Next, they changed each relay’s settings to open port 22, the port SSH uses. SSH is a tool for logging in to remote computers. The change opened SSH on 342 relays that had blocked it. Meanwhile, 24 relays that were not exits became exits.

As a result, Tor began sending SSH traffic through these relays. Each relay then redirected it to one of 12 attacker servers. Kaba tested about 3,000 exits on October 2. He found 333 doing this. On most relays, the change also swapped encrypted email ports for plain ones.

How the Theft Worked

The fake servers showed their own digital ID, called a host key. Returning users saw a warning that the key had changed. First-time users saw a normal prompt. However, anyone who accepted the key and typed a password handed it to the attacker.

Then the attacker passed the connection to the real server. The login worked, so victims had little reason to worry. Meanwhile, the attacker watched every command. Later, the attacker could log in again with the stolen password. In kaba’s test, the attacker ran an installer matching the one that planted a backdoor called Ebury elsewhere.

Key-based logins were safer. A key’s signature works for one session only. Therefore, the attacker could not reuse it.

Several things had to happen for a person to lose a password. They had to connect over Tor between October 1 and the afternoon of October 5. Their traffic had to land on a hijacked exit. After that, they had to accept the fake key and log in with a password. Nobody knows how many people met all four conditions. If that was you, change your password and check that server for Ebury.

The Tor Team’s Response

Kaba reported his findings to Tor’s network health team that evening. The team had also spotted the changes on its own, according to their October 9 report. On October 4, the servers that manage Tor’s relay list began voting to label the affected relays as bad exits. The labels took effect by 9 p.m. UTC.

By 5 p.m. UTC on October 5, no relay with the attacker’s settings remained on the list. At the peak on October 4, those relays carried 7.46% of Tor’s exit capacity. A separate review of public data counted 377 relays from 59 operators with the same settings. However, it calls that a match in settings, not proof of a hack.

How the Attackers Gained Access

The largest group of affected relays belonged to an operator named Zimmer. He later found Ebury on two of his servers. The attacker had logged in on August 28 with a password on the first try. Root access followed within five minutes.

Zimmer took the blame. He had reused one password for several tasks and stored it in plain text. He had also left password logins on for a server open to the internet. Still, nobody knows where the attacker got that password.

Ebury is not new. Security firm ESET estimated in 2024 that it had infected 400,000 servers. Marc-Etienne Léveillé, a former ESET researcher, said this version has circulated since at least June 2026. Because of that, he believes other relays are probably infected.

Another recent server-security threat involves Carbonato malware, which uses an AI agent to hijack exposed Docker servers, highlighting the risks posed by malware targeting vulnerable infrastructure.

The other operators remain a puzzle. Among their relays, 71 of 101 hosted at FranTech Solutions switched to the attacker’s settings. Only 13 of 9,054 hosted elsewhere did. Meanwhile, 40 relays from 21 operators changed within about five minutes on October 1. Kaba asked whether the hosting provider itself was breached. The question remains open. Likewise, nobody knows who is behind the campaign.

Risky Bulletin called it one of the largest security incidents in Tor’s history.

What to Do Now

SSH users should switch to keys and turn off password logins. Also, never accept a changed host key without checking it first.

Relay operators should look for exit settings they did not choose. If they find Ebury, the Tor Project says to take the relay offline and save the logs. Next, reinstall the server instead of cleaning it. Finally, create a new relay identity and change every password on the host. A reboot is not enough, because Ebury survived one on Zimmer’s server.