Attackers Hijack 333 Tor Exit Nodes With Ebury
A Large Tor Exit Node Attack
An unknown attacker took over 333 Tor exit nodes. That gave the intruder a way to intercept SSH connections and unencrypted correspondence. The hijacked relays made up about 10 percent of the network’s exit relays. Defenders stopped the campaign only after several days.
A Swiss security engineer who goes by KABA revealed the details on October 20.
Timeline of the Intrusion
According to KABA, the coordinated attack began on October 2 at 09:35. At that moment, 333 infected nodes changed how they handled network traffic at the same time.
The intruder, however, got into the servers much earlier, back in August. There, the attacker installed the Ebury 1.8.3 malware.
What the Attacker Wanted
The infrastructure points to two prizes: SSH passwords and the content of unencrypted email connections.
SSH Interception
The compromised servers redirected SSH traffic through 12 systems that the attacker controlled. Those systems impersonated the remote server and tried to capture credentials.
KABA found the mechanism on his own connection. His client received a warning that the remote host key had changed, instead of the server he expected. If a user ignored the warning and typed a password, the fake server could grab it. It could then connect to the real system and watch the commands the user typed. The researcher says the attacker also tried to install Ebury on his server.
This is a man-in-the-middle attack, in which an outsider slips unseen into a link between two parties. Here, the SSH host key check played the key role. An unexpected key change warning could stop the attack if the user refused to continue. KABA gives no confirmed count of stolen passwords.
Pushing Email Toward Plaintext
For email, the attacker used a different tactic. Instead of breaking encryption, the attacker changed the connection rules on the exit nodes. They blocked ports 465, 587, 993, and 995, which carry secure mail connections. Meanwhile, the ports for mail without TLS stayed open.
As a result, some mail clients might fall back to an insecure connection, if their settings allowed it.
Why Exit Nodes Matter
User traffic passes through several relays before the last server sends the request to the open internet. On the middle hops, Tor protects the connection with its own encryption. An exit node, however, can potentially see data that an application sends without extra protection.
HTTPS and correctly configured TLS keep traffic encrypted between the client and the final server.
Config Changes on Hijacked Servers
To widen its control, the attacker edited the torrc configuration file on servers it had already captured. Some relays that once served only as middle nodes started handling exit traffic after the change.
The Tor security team confirmed unauthorized configuration changes and SSH interception. Still, the exact first point of entry on all affected servers remains unknown.
Ebury: The Attacker’s Main Tool
Ebury is a long-known malware family for Linux and other Unix-like servers. It hooks into SSH authentication, steals credentials, and opens a hidden access channel. In a May 2024 ESET study, researchers said attackers had compromised almost 400,000 servers over the years. More than 100,000 remained infected at the end of 2023.
The Quetzalcoatl Case
One affected Tor operator published a detailed timeline for the Quetzalcoatl infrastructure. On August 28, the attacker logged into a management server with the correct password on the first try. The attacker gained administrator rights and installed Ebury 1.8.3. Next, the attacker reached another server that hosted two exit relays. The operator could not find out where the attacker first got the password.
How Ebury Hid
On infected machines, Ebury posed as the system library libkeyutils. It left the original SSH binaries untouched. Therefore, ordinary integrity checks of installed packages missed it.
The malware also bypassed standard login logs and captured passwords inside the SSH process itself. Researchers found that version 1.8.3 evaded some previously published Ebury detection tools.
The Scale of the Damage
After the incident, the Quetzalcoatl operator found 168 relays on 57 IP addresses that had stopped working. They all published the same suspicious exit policies.
Even so, forensic checks covered only two servers. No one has independently confirmed Ebury on each of the others. The operator retired the infrastructure and dropped the old relay identities.
How the Campaign Was Stopped
KABA’s accidental SSH connection exposed the campaign. On the evening of October 2, he passed his findings to the Tor Network Health team, which guards the network’s security.
On October 4, the team began tagging suspicious servers with the BadExit flag, which bars a node from serving as an exit. Operators also received warnings and shut down compromised machines on their own.
The next day, the attacker tried to restart some relays. The BadExit tag blocked the old interception, though. By October 5, all 333 identified nodes had stopped. Operators shut down some, while others, in KABA’s view, may have stopped at the attacker’s choice. The Tor metrics show a sharp drop in available exit relays after October 4.
Guidance for Relay Operators
The Tor team urges Linux server operators to check these items:
- The torrc configuration.
- SSH traffic redirection rules.
- Unknown processes.
- Suspicious changes to system services.
If a server shows signs of a breach, deleting the malware file is not enough. Reinstall the server, replace all keys and passwords, and create a new relay identity. Treat the old keys as compromised.
What This Does Not Mean
This is one of the largest known incidents involving Tor exit nodes. Even so, 333 infected relays do not mean the attacker saw all network traffic. Nor can the attacker automatically unmask users.
The main risk fell on connections that passed through the controlled exit nodes and allowed interception at the application level. The scale of actual data theft remains unknown.
A Different Kind of Threat Than 2023
Tor has faced mass relay removals before. In November 2023, developers removed many nodes tied to a commercial crypto scheme. That scheme created risks for users and for the network’s independence.
That case involved an unsafe server management model, not confirmed SSH interception. The October 2026 incident shows another problem. Even volunteer-run relays can become surveillance tools when attackers take control of operators’ hardware.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
