Research

Someone Turned 333 Tor Exits Into SSH Password Traps. Our Hourly Tor Snapshots Recorded It, and Nothing We Ran Noticed. Now Something Does.

Patrick Duggan · · 4 min read

Someone Turned 333 Tor Exits Into SSH Password Traps. Our Hourly Tor Snapshots Recorded It, and Nothing We Ran Noticed. Now Something Does.

If you connected to a server over SSH through Tor between October 1 and the afternoon of October 5, saw a new or changed host key, accepted it and typed a password, treat that password as stolen. Change it, and check the server for the Ebury backdoor (indicators below). If you logged in with a key, the interceptor could not reuse it.

That is the practical part. The rest of this post is about what our own data shows, and the thing it did not do.

Tor exits that left the network, by the day they were last seen, September 28 to October 15, 2026, from DugganUSA's hourly Tor consensus snapshots: most days between 3 and 31; September 29: 147, an unrelated departure; October 4: 84 and October 5: 327, the hijack being flagged and removed. The Quetzalcoatl relay family: 277 identities last seen October 4 and 5; back with 25 exits by October 23, all new identities first seen October 13 or later, none allowing port 22. What we ran: a mass abandonment check that waited for a relay marked not running, which a consensus snapshot never contains, so it could not fire. What runs now: an hourly sensor that compares each snapshot with the one a day earlier and alarms when 20 or more relays move to the same new exit policy or 20 or more exits newly open port 22. Seven day baseline: at most 2 and 1. First live reading October 23, 15:29 UTC: 1 relay of 2,700 exits.

What happened

A researcher who publishes as kaba scanned all of Tor's roughly 3,000 exit relays on October 2 and found 333 of them sending SSH traffic to the same 12 interception servers. The interceptor showed its own host key. A user who already knew the real key got OpenSSH's changed-key warning; a first-time user saw the ordinary prompt. Accept it and type a password, and the interceptor kept the password and relayed the session to the real server so nothing looked wrong.

The relays were not run by the attacker. Their operators' servers were broken into. The largest affected family, Quetzalcoatl, published a post-mortem: a reused password stored in plain text, with SSH password login enabled on an internet-facing management server. Someone logged in on August 28, had root within five minutes, and installed Ebury 1.8.3, an OpenSSH backdoor and credential stealer that has been around since 2009. On October 1 the attacker rewrote the relays' configuration to open port 22 and close the encrypted mail ports.

The directory data counts 377 relays from 59 operators switching to that exact policy between October 1 and 4, at a peak of 7.46% of Tor's exit capacity on October 4. The Tor Project's network health team spotted the change with its own monitoring, the directory authorities began flagging the relays as bad exits at 18:00 UTC on October 4, and by October 5 none were left in the consensus. Who did it is unknown. No victim count exists.

What our snapshots show

We collect Tor's consensus every hour and keep a lifecycle record of every relay we have ever seen. Read against October, it tells the same story from the outside:

  • 277 Quetzalcoatl relay identities were last seen on October 4 and 5 (55 and 222). The post-mortem counts 273 affected Quetzalcoatl relays.
  • 411 exit relays left the network on those two days, against 3 to 31 on most days around them. One other day, September 29, saw 147 departures with no connection to this, which is why departures alone cannot be an alarm.
  • Quetzalcoatl is back: 25 exits on October 23, every one a new identity first seen on October 13 or later, and none of them allowing port 22. That is exactly what the Tor Project asked operators to do: reinstall, generate a new relay identity, treat the old keys as stolen.

What we missed

Every hourly snapshot from October 1 to 5 held each relay's exit policy. 377 relays moving to one new policy is about the loudest signal that data can produce. Nothing we ran looked at it.

The only fleet-level check we had was a mass-abandonment detector that counted relays marked as not running. A consensus snapshot lists only running relays, so that count is always zero: it could never have fired, and nothing called it anyway. We also keep the detailed snapshots for only seven days, so the October policy rows themselves have aged out; only the lifecycle record above survived.

The Tor Project caught this, not us. We are not claiming any part of the detection.

What runs now

We built the check we should have had and deployed it today. Every hour it compares the newest snapshot with the one a day earlier, relay by relay, and asks two questions: how many relays moved to the same new exit policy, and how many exits newly allow port 22? Over the last seven days the answers were never above 2 and 1. It warns at 8 and alarms at 20. Its first live reading, at 15:29 UTC on October 23, was 1 relay of 2,700 exits. Departures are reported beside it but never trigger it.

Indicators

From the operator post-mortem and kaba's research, for hunting on your own servers. These are not ours.

  • Interceptor host key (one of 12 servers; others may differ): ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E
  • Ebury implant: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 (setuid, owned by no package), with libkeyutils.so.1 pointing to it
  • Abstract UNIX socket: @event-0YsOG9WSOE
  • Process: a fake /sbin/rsyslogd (earlier systemd-udevd or arpd) inside the ssh.service cgroup
  • Source of the August 28 login: 185.225.226.62, now in our feed at confidence 75 under source manual-batch-tor-exit-ssh-hijack. A single historical login source that may itself be a compromised host, which is why it sits below our own blocking floor of 80.

If you find Ebury, check from a rescue system, rotate every credential that was on the host, and disable SSH password login. Relay operators should report to [email protected].

Credit to kaba, the Quetzalcoatl operator and the Tor Project's network health team, via The Hacker News.

If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com

Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=someone-turned-333-tor-exits-into-ssh-password-traps-our-hourly-tor-snapshots-recorded-it-and-noth