Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Line chart of malicious Tor exit relays falling from roughly 330 on Oct. 2 to near zero after BadExit flags on Oct. 5, from Kaba's research.
Chart: Kaba, count of the malicious Tor exit relays during the Oct. 2 to Oct. 5, 2026 interception window (fair use).

Response

A Tor Volunteer Says 333 Exit Relays Redirected SSH to Interception Servers Running Paramiko, Stole Passwords From Users Who Ignored Host-Key Warnings and Tried to Plant Ebury

Independent researcher Kaba says the relays, about a tenth of Tor's exit capacity, began the campaign on Oct. 2 after Ebury 1.8.3 had already been planted in August. Twelve interception servers sat behind the redirect. The Tor Project marked the set BadExit within three days. What to hunt on any host that accepted a changed SSH fingerprint through Tor.

Noah Park, ResponseNew York6 min read

NEW YORK - About a tenth of Tor's exit capacity spent three days in early October redirecting SSH connections to attacker-controlled servers, according to an investigation published Tuesday by an independent researcher writing as Kaba.

Kaba says that on Friday, Oct. 2, at 09:35, 333 infected exit relays began a coordinated campaign. Tor runs roughly 3,000 exit relays, so the set represented about 10 percent of that capacity. The attackers had already gained access to the underlying servers in August and quietly planted Ebury 1.8.3, an OpenSSH backdoor and credential stealer for Linux first documented more than a decade ago.

Two goals at the exit

Kaba says the campaign had two aims. The first was to gather as much unencrypted mail traffic as possible by rewriting exit policies so the compromised relays favored cleartext mail ports and closed encrypted ones. A detailed write-up by one of the affected operators, published on the Tor relays mailing list and covering two Quetzalcoatl family relays, describes that side of the intrusion.

The second aim, which Kaba focuses on, was SSH man-in-the-middle. Encrypted web traffic through the infected exits looked normal. An SSH connection on port 22 was redirected to one of 12 interception servers.

Diagram of a Tor circuit with a malicious exit redirecting port 22 SSH to one of 12 interception servers while other traffic reaches the intended web server.
Diagram: Kaba, the SSH redirect path through the malicious Tor exits, Oct. 20, 2026 (fair use).

That is what happened to Kaba on the Friday morning the campaign started. The client showed the familiar host-identification-has-changed warning, with the ED25519 fingerprint SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. Anyone who ignored the warning and continued, Kaba writes, had three things done to them: the password was stolen, a live session watched every command typed, and a second connection planted Ebury on the destination server.

How the set was found

Kaba contacted Tor's network health team that Friday evening. The team confirmed the pattern was new and began reaching operators. "We've not seen an attack like that before," the team told Kaba.

The public timeline Kaba records is short. Interception started Oct. 2. On Oct. 4 the health team announced the pattern and marked the relays BadExit so clients would stop using them as exits. On Oct. 5 the attackers restarted many of the relays, but the BadExit flag left them usable only as middle relays, and by the end of that day the infected servers were offline, shut by operators or by the attackers.

Annotated chart of the 333 malicious exits, with the interception start on Oct. 2 and BadExit and MiddleOnly flags on Oct. 5, separating usable exits from relays no longer exiting.
Chart: Kaba, annotated timeline of the 333 malicious exits and the Tor BadExit response, Oct. 20, 2026 (fair use).

The health team's announcement, quoted by Kaba, said the attacker appeared to be gaining access to Linux hosts and, where those machines ran non-exit relays, editing torrc to turn them into exits for the SSH attack.

exitmap, fingerprints and a honeypot

To find the infected exits, Kaba built a script on exitmap that pinned each of Tor's roughly 3,000 exit relays and opened an SSH connection from one of Kaba's servers to another. The first server checked whether it received the correct fingerprint. The second checked whether the connection arrived from the pinned exit or from one of the 12 interception servers. Around a dozen exits served a fake fingerprint. More than 300 others did not change the fingerprint but still redirected through the same interception servers. The redirect alone was enough to mark an exit infected.

A honeypot built with sshesame then showed the interception software was written in Paramiko, a Python SSH library, and that the Ebury install attempt looked like a permissions probe followed by a base64-encoded Perl one-liner under sudo.

Tor Project metrics chart of the number of relays carrying the Exit flag from early September through mid-October 2026, with a visible dip around Oct. 4.
Chart: The Tor Project, metrics.torproject.org, Exit-flagged relay count around the Oct. 4 removal (fair use).

Open questions remain. How the attackers first reached so many servers is unsettled; one theory discussed on the mailing list points at a hosting cluster, but Kaba treats it as unproven. Who sits behind the campaign is also open. Kaba says the use of Ebury and the broad harvest of unencrypted data point to a financially motivated group, and notes Marc-Etienne M. Leveille's remark that roughly 400,000 servers carried Ebury between 2009 and 2023, so more compromised Tor relays may still be out there.

What responders should do now

  • Treat any SSH host-key mismatch on a path that exited Tor between Oct. 2 and Oct. 5 as a compromise until proven otherwise. Rotate the password that was typed, revoke sessions and keys tied to that login and rebuild the destination host if Ebury cannot be ruled out from a clean rescue environment.
  • Prefer key-only SSH and disable password authentication on every internet-facing and jump host. Hardware keys close the class of theft this campaign relied on.
  • On Linux jump hosts and Tor relays, hunt for the Ebury 1.8.3 library pattern described by the Quetzalcoatl operators: an unowned setuid libkeyutils.so.1.* under /usr/lib/x86_64-linux-gnu/, a libkeyutils.so.1 symlink that no package owns, an @event- abstract socket and root actions with no Requested-By in apt history. Package verification alone will miss it.
  • Never type a password into a host you already suspect. Investigate with keys from a clean machine or an offline image, and capture memory before reboot.
  • Relay operators should monitor published descriptors from outside for unexpected ExitPolicy or family changes, as Tor's own network health team did for the Quetzalcoatl family, and treat management servers as crown jewels with no password reuse across SSH, sudo and backups.
  • Configure mail accounts and servers to reject cleartext ports so an exit that blocks IMAPS and POP3S cannot force a downgrade.

Sources:


Noah Park covers incident response, containment, and blue-team operations for SOCtember from New York.

Related stories

Response desk