How I got over 300 Tor exit nodes removed
- ID
- 37783
- Status
- summarized
- Published
- 20 Oct 2026, 9:39 PM
- Fetched
- 21 Oct 2026, 2:15 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://kaba.cx/posts/20261020_Tor/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 6.5
- Created
- 21 Oct 2026, 2:16 PM
- Tags
- Audience
- developersvibe_coders
What happened
On Friday 2 October at 09:35, 333 compromised Tor exit relays — roughly 10% of Tor's ~3000 exit relays — began a coordinated campaign to intercept SSH connections on port 22 and harvest unencrypted mail traffic. The servers had been breached two months earlier in August with an Ebury 1.8.3 payload (an OpenSSH backdoor and Linux credential stealer), and SSH sessions were silently redirected to one of 12 interception servers, which stole passwords, watched commands, and reinfected the connecting server. The author reported it to the Tor Project's network health team that evening; relays were marked BadExit on Sunday 4 October, and by Monday 5 October the attackers' restarted relays could only serve as middle relays before all infected servers were shut down.
Why it matters
The concrete lesson is that the SSH "REMOTE HOST IDENTIFICATION HAS CHANGED" prompt is not a formality — in this campaign, accepting it handed over your password and pushed Ebury onto your own box. If any of your tooling or CI connects over Tor, or if you have StrictHostKeyChecking disabled or set to accept-new in scripts, you would have sailed straight through this without seeing the warning at all. Decide now how your team handles a changed host key: verify the fingerprint out-of-band (the intercepted ED25519 key here was SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E) rather than clicking yes.
Discussion angle
Trust-on-first-use failed here at scale — should SSH clients default to hard-failing on a changed host key, and how many of your own deploy scripts would have blocked this attack versus silently reconnecting?