{"article":{"slug":"how-i-got-over-300-tor-exit-nodes-removed","title":"How I got over 300 Tor exit nodes removed","subtitle":null,"summary":"The author of KABA.CX describes discovering that 333 compromised Tor exit relays, about 10% of all exits, were redirecting SSH connections to interception servers to steal passwords and spread the Ebury backdoor. They explain how an exitmap script and an sshesame honeypot exposed the relays, and how the Tor network health team got them flagged and shut down within days.","content_type":"blog_post","language":"en","canonical_url":"https://kaba.cx/posts/20261020_Tor/","author":{"name":null,"url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"KABA.CX","url":"https://kaba.cx/","listing_slug":null,"listing":null},"topics":[{"name":"Security","slug":"security","url":"https://listedarticles.com/topics/security"},{"name":"Tor","slug":"tor","url":"https://listedarticles.com/topics/tor"},{"name":"SSH","slug":"ssh","url":"https://listedarticles.com/topics/ssh"},{"name":"Privacy","slug":"privacy","url":"https://listedarticles.com/topics/privacy"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":965,"reading_minutes":4,"published_at":"2026-10-20T00:00:00.000Z","added_at":"2026-10-20T17:06:39.402Z","updated_at":"2026-10-20T17:06:39.402Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/how-i-got-over-300-tor-exit-nodes-removed","markdown_url":"https://listedarticles.com/articles/how-i-got-over-300-tor-exit-nodes-removed.md","example":false,"citation":"KABA.CX. \"How I got over 300 Tor exit nodes removed.\" 20 Oct 2026. https://kaba.cx/posts/20261020_Tor/ (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://kaba.cx/posts/20261020_Tor/"},"body_markdown":"# How I got over 300 Tor exit nodes removed\n\nKABA.CX | October 20, 2026\n\n![Overview Malicious Tor Exit nodes disappearing](https://kaba.cx/img/tor/relays_offline_hero.svg)\n\nOn Friday Oct 2, 09:35am, 333 infected exit nodes started a coordinated campaign to intercept SSH connections and gather as much unencrypted data as possible.\n\nTo give you a sense of scale, all of Tor has around 3000 exit relays, so roughly 10% were under their control.\n\nThe attackers had gained access to the servers two months earlier, in August, and quietly deployed their Ebury 1.8.3 payload (an OpenSSH backdoor and credential stealer for Linux).\n\n## The Attack\n\nThe attack appears to have had two primary goals:\n\n1. Gather as much unencrypted mail traffic as possible\n2. Intercept SSH connections (MITM)\n\nBy blocking certain ports, they made their exit nodes handle only unencrypted mail traffic.\nAn interesting writeup by one of the victims (a veteran Tor operator) goes into great detail about that:\n[lists.torproject.org/mailman3](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/QHRD6YOX6RZRDR7NCHNDO7GLCEA6VFM6/)\n\nIn this post I'll focus on the second attack, the SSH MITM.\nIf you happen to get a circuit that exits over one of those 333 infected exit nodes, you won't notice anything at first.\nEncrypted web traffic is forwarded as usual, but if you attempt an SSH connection over Port 22, you're unknowingly redirected to one of 12 SSH interception servers.\n\n![Attacker Infrastructure](https://kaba.cx/img/tor/tor-ssh-incident.svg)\n\nThat's exactly what happened to me on Friday morning.\nMy SSH connection got redirected, and I was greeted with this warning:\n\n```\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\nIt is also possible that a host key has just been changed.\nThe fingerprint for the ED25519 key sent by the remote host is\nSHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.\nPlease contact your system administrator.\n```\n\nBut if you ignore the warning and go ahead with the login, the attacker does three things:\n\n1. Steals your password\n2. Opens a connection to your server and observes each command you type (MITM)\n3. Opens a second connection to your server and infects it with Ebury\n\n## Getting them taken down\n\nOn Friday evening I contacted the [Tor Project's network health team](https://community.torproject.org/relay/community-resources/bad-relays/) with my findings.\nThey confirmed this was something new and got to work by contacting the affected relay operators.\n\n> *\"We've not seen an attack like that before.\"* \n> - Tor Network Health Team\n\n![Malicious Tor exit nodes going offline](https://kaba.cx/img/tor/relays_offline_detail.svg)\n\n1. **Fri Oct 2**: Interception started.\n2. **Sun Oct 4**: The Tor network health team [made an announcement to the operators](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/), who began shutting their exit nodes down.\n3. **Sun Oct 4**: The relays were marked BadExit, so clients would no longer use them to exit traffic.\n4. **Mon Oct 5**: The attackers restarted many of the relays, but since they were already flagged they could only serve as middle relays.\n5. **Mon Oct 5**: All infected servers were shut down, partly by the operators and partly by the attackers.\n\nIn their announcement, the health team described the pattern:\n\n> *\"It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack.\"* \n> - Tor Network Health [in the announcement](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/)\n\nYou can see the impact of those 333 exit nodes being shut down.\nOn [metrics.torproject.org](https://metrics.torproject.org/relayflags.html?start=2026-09-02&end=2026-10-19&flag=Exit) a clear dip is visible on October 4th and has not recovered since.\n\n![Tor exit node count dipping](https://kaba.cx/img/tor/relayflags-Exit-2026-09-02-2026-10-19.png)\n\n*Consider running a relay: [community.torproject.org/relay/setup/](https://community.torproject.org/relay/setup/)*\n\n---\n\n## The technical part: how I found them\n\nIn this part I'll go into detail about how I found all the infected exit nodes.\n\nUsing [exitmap](https://gitlab.torproject.org/tpo/network-health/exitmap), I built a simple script that did the following:\nit pinned an exit node, then opened an SSH connection from my server A to my server B.\n\n- Server A checked whether it received the correct SSH fingerprint from server B.\n- Server B checked whether the connection came from the pinned exit node or from one of the 12 SSH interception servers.\n\nI ran the script against every single one of the ~3000 exit relays.\nAround a dozen served a fake fingerprint, and over 300 didn't intercept anything but redirected through those same interception servers.\nRedirecting alone was enough to confirm the exit was infected.\n\nIn some further analysis I used [sshesame](https://github.com/jaksi/sshesame) as a honeypot.\nTricking the MITM into logging into the honeypot showed that they used paramiko (a Python SSH library) and also how they attempted to install Ebury using Perl.\n\n```\n> echo \"U=$(id -u) S=$(command -v sudo >/dev/null 2>&1 && (sudo -n true 2>/dev/null && echo nopass || echo maybe) || echo none)\"\n> sudo bash -c 'echo | base64 -d | perl'\n```\n\nChecking for permissions first, then executing a base64-encoded command.\n\n## Open Questions\n\nThe biggest question is still how they got into all those servers in the first place.\nOne theory is that the hosting company itself was hacked\n(discussed here: [lists.torproject.org](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/RXWGWYYYKBDEBNXC2C3NYIQ2HHHWXL7O/)).\nBut that's just a theory floating around. In truth, no one really knows.\n\nAnother is who's behind it.\nThe use of Ebury and the broad collection of unencrypted data point to a financially motivated crime group.\nThough this too is just speculation.\n\n> *\"Given how many servers had Ebury between 2009 and 2023 (400 000!) there are most likely other compromised Tor relays out there.\"* \n> - Marc-Etienne M. Léveillé\n> ([lists.torproject.org](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/RXWGWYYYKBDEBNXC2C3NYIQ2HHHWXL7O/))\n\nI also suspect they deliberately launched their attack on a Friday, hoping that no one would want to ruin their weekend by responding.\nAll the more credit to the Tor Team for acting so quickly!\n\n## Takeaway\n\nThe lesson is the same as always: extra security is a worthwhile investment.\nDisable password authentication in favor of ssh keys.\nI for one am going to buy myself some hardware keys today. :)\n\n> *\"At the end of the day, relays/bridges need to be treated as highly targeted production machines.\"* \n> - George\n> ([lists.torproject.org](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/RXWGWYYYKBDEBNXC2C3NYIQ2HHHWXL7O/))\n","body_html":"

How I got over 300 Tor exit nodes removed

\n

KABA.CX | October 20, 2026

\n
\"Overview
\n

On Friday Oct 2, 09:35am, 333 infected exit nodes started a coordinated campaign to intercept SSH connections and gather as much unencrypted data as possible.

\n

To give you a sense of scale, all of Tor has around 3000 exit relays, so roughly 10% were under their control.

\n

The attackers had gained access to the servers two months earlier, in August, and quietly deployed their Ebury 1.8.3 payload (an OpenSSH backdoor and credential stealer for Linux).

\n

The Attack

\n

The attack appears to have had two primary goals:

\n
  1. Gather as much unencrypted mail traffic as possible
  2. Intercept SSH connections (MITM)
\n

By blocking certain ports, they made their exit nodes handle only unencrypted mail traffic.\nAn interesting writeup by one of the victims (a veteran Tor operator) goes into great detail about that:\nlists.torproject.org/mailman3

\n

In this post I'll focus on the second attack, the SSH MITM.\nIf you happen to get a circuit that exits over one of those 333 infected exit nodes, you won't notice anything at first.\nEncrypted web traffic is forwarded as usual, but if you attempt an SSH connection over Port 22, you're unknowingly redirected to one of 12 SSH interception servers.

\n
\"Attacker
\n

That's exactly what happened to me on Friday morning.\nMy SSH connection got redirected, and I was greeted with this warning:

\n
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\nIt is also possible that a host key has just been changed.\nThe fingerprint for the ED25519 key sent by the remote host is\nSHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.\nPlease contact your system administrator.
\n

But if you ignore the warning and go ahead with the login, the attacker does three things:

\n
  1. Steals your password
  2. Opens a connection to your server and observes each command you type (MITM)
  3. Opens a second connection to your server and infects it with Ebury
\n

Getting them taken down

\n

On Friday evening I contacted the Tor Project's network health team with my findings.\nThey confirmed this was something new and got to work by contacting the affected relay operators.

\n

"We've not seen an attack like that before."

\n
\n
\"Malicious
\n
  1. Fri Oct 2: Interception started.
  2. Sun Oct 4: The Tor network health team made an announcement to the operators, who began shutting their exit nodes down.
  3. Sun Oct 4: The relays were marked BadExit, so clients would no longer use them to exit traffic.
  4. Mon Oct 5: The attackers restarted many of the relays, but since they were already flagged they could only serve as middle relays.
  5. Mon Oct 5: All infected servers were shut down, partly by the operators and partly by the attackers.
\n

In their announcement, the health team described the pattern:

\n

"It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack."

\n
\n

You can see the impact of those 333 exit nodes being shut down.\nOn metrics.torproject.org a clear dip is visible on October 4th and has not recovered since.

\n
\"Tor
\n

Consider running a relay: community.torproject.org/relay/setup/

\n
\n

The technical part: how I found them

\n

In this part I'll go into detail about how I found all the infected exit nodes.

\n

Using exitmap, I built a simple script that did the following:\nit pinned an exit node, then opened an SSH connection from my server A to my server B.

\n\n

I ran the script against every single one of the ~3000 exit relays.\nAround a dozen served a fake fingerprint, and over 300 didn't intercept anything but redirected through those same interception servers.\nRedirecting alone was enough to confirm the exit was infected.

\n

In some further analysis I used sshesame as a honeypot.\nTricking the MITM into logging into the honeypot showed that they used paramiko (a Python SSH library) and also how they attempted to install Ebury using Perl.

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

Checking for permissions first, then executing a base64-encoded command.

\n

Open Questions

\n

The biggest question is still how they got into all those servers in the first place.\nOne theory is that the hosting company itself was hacked\n(discussed here: lists.torproject.org).\nBut that's just a theory floating around. In truth, no one really knows.

\n

Another is who's behind it.\nThe use of Ebury and the broad collection of unencrypted data point to a financially motivated crime group.\nThough this too is just speculation.

\n

"Given how many servers had Ebury between 2009 and 2023 (400 000!) there are most likely other compromised Tor relays out there."

\n
\n

I also suspect they deliberately launched their attack on a Friday, hoping that no one would want to ruin their weekend by responding.\nAll the more credit to the Tor Team for acting so quickly!

\n

Takeaway

\n

The lesson is the same as always: extra security is a worthwhile investment.\nDisable password authentication in favor of ssh keys.\nI for one am going to buy myself some hardware keys today. :)

\n

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

\n
","headings":[{"level":1,"text":"How I got over 300 Tor exit nodes removed","id":"how-i-got-over-300-tor-exit-nodes-removed"},{"level":2,"text":"The Attack","id":"the-attack"},{"level":2,"text":"Getting them taken down","id":"getting-them-taken-down"},{"level":2,"text":"The technical part: how I found them","id":"the-technical-part-how-i-found-them"},{"level":2,"text":"Open Questions","id":"open-questions"},{"level":2,"text":"Takeaway","id":"takeaway"}]}}