How I got over 300 Tor exit nodes removed

How I got over 300 Tor exit nodes removed October 20, 2026

我是如何移除超过 300 个 Tor 出口节点的 2026 年 10 月 20 日

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. To give you a sense of scale, all of Tor has around 3000 exit relays, so roughly 10% were under their control. 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).

10 月 2 日星期五上午 9:35，333 个受感染的出口节点发起了一场协同行动，旨在拦截 SSH 连接并尽可能多地收集未加密数据。为了让你了解其规模，整个 Tor 网络大约有 3000 个出口中继，这意味着约 10% 的节点处于攻击者的控制之下。攻击者在两个月前的 8 月就已获得这些服务器的访问权限，并悄悄部署了 Ebury 1.8.3 有效载荷（一种针对 Linux 的 OpenSSH 后门和凭据窃取程序）。

The Attack The attack appears to have had two primary goals: Gather as much unencrypted mail traffic as possible Intercept SSH connections (MITM) By blocking certain ports, they made their exit nodes handle only unencrypted mail traffic. An interesting writeup by one of the victims (a veteran Tor operator) goes into great detail about that: lists.torproject.org/mailman3

攻击方式 此次攻击似乎有两个主要目标： 尽可能多地收集未加密的邮件流量； 拦截 SSH 连接（中间人攻击）。 通过封锁特定端口，他们使出口节点仅处理未加密的邮件流量。其中一位受害者（一位资深的 Tor 运营者）撰写了一篇有趣的报告，详细介绍了相关情况：lists.torproject.org/mailman3

In this post I’ll focus on the second attack, the SSH MITM. If you happen to get a circuit that exits over one of those 333 infected exit nodes, you won’t notice anything at first. Encrypted 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. That’s exactly what happened to me on Friday morning. My SSH connection got redirected, and I was greeted with this warning:

在这篇文章中，我将重点讨论第二种攻击，即 SSH 中间人攻击。如果你恰好使用了一条通过这 333 个受感染出口节点之一的链路，起初你不会察觉到任何异常。加密的网页流量会照常转发，但如果你尝试通过 22 端口进行 SSH 连接，你会在不知情的情况下被重定向到 12 台 SSH 拦截服务器中的一台。周五早上我遇到的正是这种情况。我的 SSH 连接被重定向，并收到了以下警告：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. Please contact your system administrator.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 警告：远程主机标识已更改！ @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 可能有人正在进行恶意操作！现在可能有人正在窃听你（中间人攻击）！也有可能是主机密钥刚刚发生了更改。远程主机发送的 ED25519 密钥指纹为 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E。请联系您的系统管理员。

But if you ignore the warning and go ahead with the login, the attacker does three things: Steals your password Opens a connection to your server and observes each command you type (MITM) Opens a second connection to your server and infects it with Ebury

但如果你忽略警告并继续登录，攻击者会执行三项操作： 窃取你的密码； 建立到你服务器的连接并观察你输入的每一条命令（中间人攻击）； 建立第二个到你服务器的连接，并用 Ebury 感染它。

Getting them taken down On Friday evening I contacted the Tor Project’s network health team with my findings. They confirmed this was something new and got to work by contacting the affected relay operators. “We’ve not seen an attack like that before.” - Tor Network Health Team

移除这些节点 周五晚上，我将我的发现告知了 Tor 项目的网络健康团队。他们确认这是一种新型攻击，并立即着手联系受影响的中继运营者。 “我们以前从未见过这样的攻击。”——Tor 网络健康团队

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

10 月 2 日星期五：拦截开始。 10 月 4 日星期日：Tor 网络健康团队向运营者发布公告，运营者开始关闭其出口节点。 10 月 4 日星期日：这些中继被标记为“BadExit”，因此客户端不再使用它们来出口流量。 10 月 5 日星期一：攻击者重启了许多中继，但由于它们已被标记，它们只能作为中间中继运行。 10 月 5 日星期一：所有受感染的服务器均被关闭，部分由运营者关闭，部分由攻击者关闭。

In their announcement, the health team described the pattern: “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.” - Tor Network Health in the announcement

健康团队在公告中描述了这种模式： “攻击者似乎正在获取基于 Linux 的主机的访问权限，当这些机器运行非出口节点时，他们会编辑 torrc 文件并将其转变为出口节点，以便实施 SSH 攻击。”——Tor 网络健康团队公告

You can see the impact of those 333 exit nodes being shut down. On metrics.torproject.org a clear dip is visible on October 4th and has not recovered since. Consider running a relay: community.torproject.org/relay/setup/

你可以看到这 333 个出口节点被关闭后的影响。在 metrics.torproject.org 上，10 月 4 日出现了明显的下降，且此后一直未恢复。考虑运行一个中继：community.torproject.org/relay/setup/

The technical part: how I found them In this part I’ll go into detail about how I found all the infected exit nodes. Using exitmap, I built a simple script that did the following: it pinned an exit node, then opened an SSH connection from my server A to my server B. Server A checked whether it received the correct SSH fingerprint from server B. Server B checked whether the connection came from the pinned exit node or from one of the 12 SSH interception servers.

技术部分：我是如何发现它们的 在这一部分，我将详细介绍我是如何找到所有受感染出口节点的。我使用 exitmap 构建了一个简单的脚本，其功能如下：它锁定一个出口节点，然后从我的服务器 A 打开一个到服务器 B 的 SSH 连接。服务器 A 检查它是否从服务器 B 收到了正确的 SSH 指纹。服务器 B 检查连接是来自锁定的出口节点，还是来自 12 台 SSH 拦截服务器之一。

I ran the script against every single one of the ~3000 exit relays. Around a dozen served a fake fingerprint, and over 300 didn’t intercept anything but redirected through those same interception servers. Redirecting alone was enough to confirm the exit was infected. In some further analysis I used sshesame as a honeypot. Tricking 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.

我针对大约 3000 个出口中继中的每一个都运行了该脚本。大约有十几个提供了虚假的指纹，而 300 多个虽然没有拦截任何内容，但通过相同的拦截服务器进行了重定向。仅重定向这一行为就足以确认该出口节点已受感染。在进一步分析中，我使用了 sshesame 作为蜜罐。诱骗中间人登录蜜罐显示，他们使用了 paramiko（一个 Python SSH 库），并展示了他们如何尝试使用 Perl 安装 Ebury。

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 -d | perl’ Checking for permissions first, then executing a base64-encoded command.

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 -d | perl’ 先检查权限，然后执行 base64 编码的命令。

Open Questions The biggest question is still how they got into all those servers in the first place. One theory is that the hosting company itself was hacked (discussed here: lists.torproject.org). But that’s just a theory floating around. In truth, no one really knows. Another is who’s behind it. The use of Ebury and the broad collection of unencrypted data point to a financially motivated crime group. Though this too is just speculation.

悬而未决的问题 最大的问题仍然是他们最初是如何进入所有这些服务器的。一种理论是托管公司本身遭到了黑客攻击（在此处讨论：lists.torproject.org）。但这只是流传的一种理论。事实上，没有人真正知道。另一个问题是谁在幕后操纵。使用 Ebury 和大规模收集未加密数据表明这是一个以经济利益为动机的犯罪集团。尽管这也只是猜测。

“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é (lists.torproject.org) I also suspect they deliberately launched their attack on a Friday, hoping that no one would want to ruin their weekend by responding. All the more credit to the Tor Team for acting so quickly!

“考虑到 2009 年至 2023 年间有多少服务器感染了 Ebury（40 万台！），很可能还有其他受损的 Tor 中继。”——Marc-Etienne M. Léveillé (lists.torproject.org) 我还怀疑他们故意在周五发动攻击，希望没人愿意为了应对攻击而破坏自己的周末。Tor 团队行动如此迅速，更值得称赞！

Takeaway The lesson is the same as always: extra security is a worthwhile investment. Disable password authentication in favor of ssh keys. I for one am going to buy myself some hardware keys today. :) “At the end of the day, relays/bridges need to be treated as highly targeted production machines.” - George (lists.torproject.org)

总结 教训一如既往：额外的安全措施是值得的投资。禁用密码验证，改用 SSH 密钥。我个人今天就要去买一些硬件密钥。:) “归根结底，中继/网桥需要被视为高价值的生产机器来对待。”——George (lists.torproject.org)