logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·27.10.26
← Back to news

How I got over 300 Tor exit nodes removed

Original article
kaba.cx|183 points|53 comments|by kabakabakaba|Oct 20, 2026

Case Study: The Removal of 300+ Compromised Tor Exit Nodes

On Friday, October 2, 2026, at approximately 09:35 am, a coordinated strike was launched using 333 infected Tor exit nodes. The objective was clear: intercept SSH traffic and harvest as much unencrypted data as possible.

To put this in perspective, the total number of Tor exit relays is roughly 3,000. This means the attackers controlled approximately: 3333000≈11.1% of the exit capacity\frac{333}{3000} \approx 11.1\% \text{ of the exit capacity}3000333​≈11.1% of the exit capacity

The breach actually began in August, two months prior, when attackers silently installed the Ebury 1.8.3 payload—a notorious Linux credential stealer and OpenSSH backdoor.


🎯 The Nature of the Attack

The campaign focused on two primary objectives:

  1. Mail Harvesting: Capturing unencrypted email traffic.
  2. SSH Man-in-the-Middle (MITM): Intercepting secure shell connections.

To prioritize mail traffic, the attackers blocked specific ports, forcing the infected nodes to handle only unencrypted mail. For a deeper dive into the mail aspect, a veteran operator provided a detailed account at lists.torproject.org/mailman3.

The SSH Interception Flow

If your Tor circuit happened to route through one of these 333 nodes, standard HTTPS traffic remained unaffected. However, any attempt to connect via Port 22 triggered a redirection to one of 12 specialized interception servers.

When my own connection was hijacked, I received the following critical alert:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

The fingerprint for the ED25519 key sent by the remote host is SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.

If a user ignores this warning, the attacker can:

  • Securely connect →\rightarrow→ Steal the user's password.
  • Monitor every command typed in real-time via MITM.
  • Deploy the Ebury malware onto the target server.

🛡️ The Takedown Process

I alerted the Tor Project's network health team on Friday evening. Their reaction was immediate, as they had never encountered an attack of this specific nature.

Timeline of Events

DateEventAction/Result
Oct 2 (Fri)Attack CommencementInterception begins.
Oct 4 (Sun)Official AnnouncementHealth team notifies operators; nodes begin shutting down.
Oct 4 (Sun)Network FlaggingRelays marked as BadExit to prevent client usage.
Oct 5 (Mon)Attacker ResponseAttackers restart relays, but they only function as middle relays.
Oct 5 (Mon)Final CleanupAll infected servers are taken offline by operators or attackers.

The health team noted a specific pattern: attackers compromised Linux hosts and, if the machine wasn't already an exit node, they edited the torrc file to force it to become one.

Tor Network Dip A visible drop in active exit nodes can be seen on metrics.torproject.org starting October 4th.


🛠️ Technical Analysis: Detection Method

To identify the compromised nodes, I developed a script utilizing exitmap. The logic followed this workflow:

  • Pin a specific exit node.
  • Establish an SSH connection from Server A →\rightarrow→ Server B.
  • Server A verifies if the SSH fingerprint from Server B is authentic.
  • Server B checks if the incoming connection is from the pinned exit or one of the 12 known interception servers.

I tested all ∼3000\sim 3000∼3000 relays. While only a dozen provided a fake fingerprint, over 300 were found to be redirecting traffic through the interception servers—which was sufficient proof of infection.

The Payload

By tricking the MITM into connecting to a honeypot, I discovered they used the paramiko Python library and a Perl script to install Ebury. The execution string looked like this:

echo "U=$(id -u) S=$(command -v sudo /dev/null 2 1 (sudo -n true 2 /dev/null echo nopass || echo maybe) || echo none)" sudo bash -c 'echo base64 | base64 -d | perl'

The script checks for sudo permissions before executing a base64-encoded command via Perl.


❓ Unresolved Questions & Conclusions

The primary mystery remains: How did they gain access to so many servers? One prevailing theory is that a specific hosting provider was breached. Given the use of Ebury and the focus on unencrypted data, this appears to be the work of a financially motivated criminal organization.

"Given how many servers had Ebury between 2009 and 2023 (400 000!) there are most likely other compromised Tor relays out there." — Marc-Etienne M. Léveillé

I also suspect the Friday launch was a tactical choice to exploit the "weekend lull" in security responses.

Final Takeaway

The core lesson is that basic security is never enough for high-visibility infrastructure.

"At the end of the day, relays/bridges need to be treated as highly targeted production machines." — George

If you are interested in helping the network, consider setting up a relay at community.torproject.org/relay/setup/.