Security Operations

Ebury-infected Tor exits hijacked SSH: 333 relays pulled

333 Ebury-infected Tor exit relays hijacked SSH logins in October. Why host-key warnings, key-based auth and Ebury hunting matter for UK defenders.

Network diagram illustration representing hijacked Tor exit relays intercepting SSH connections

For around three days in early October, roughly one in ten Tor exit relays quietly diverted SSH logins to attacker-run servers built to harvest passwords and plant the Ebury backdoor. The only thing standing between users and compromise was a host-key warning that many people are trained by habit to ignore.

What happened

On the morning of Friday 2 October 2026, 333 Tor exit relays began behaving in a coordinated way. Ordinary encrypted web traffic passed through untouched, but any SSH connection to port 22 that left the Tor network through one of those exits was silently redirected to one of around a dozen interception servers controlled by the attacker. With around 3,000 exits on the whole network, roughly one in ten was hostile.

The campaign was spotted because the researcher who later documented it, writing as Kaba, had their own SSH session hijacked and was greeted with a changed host-key warning. They alerted Tor’s network health team that evening. By Sunday 4 October the affected relays had been flagged as BadExit, so clients stopped using them to leave the network, and operators had been told. On Monday 5 October the Tor Project published a security notice to relay operators, and by the end of that day the infected servers were offline, shut down partly by their operators and partly by the attackers.

Kaba’s detailed write-up appeared on 20 October, and SecurityWeek included the incident in its weekly roundup on 23 October. Earlier, on 7 October, the operators of the Quetzalcoatl relay family had posted a candid post-incident account on the tor-relays mailing list, which drew a response from the researcher behind ESET’s Ebury reports.

The technical picture

The relays were not malicious from the start. According to the Tor Project, the attacker was compromising Linux hosts that already ran Tor, editing the torrc configuration and, where a machine was running as a non-exit relay, converting it into an exit so it could carry out the SSH attack. Kaba says the servers had been breached about two months earlier, in August, and seeded with Ebury version 1.8.3, a long-lived OpenSSH backdoor and credential stealer.

The interception worked in two stages. A user who ignored the host-key mismatch and logged in anyway gave the man-in-the-middle server their password. The attacker then watched the live session and, using a second connection to the real destination, tried to install Ebury there too. Kaba mapped the infected exits by testing every relay with the Tor Project’s exitmap tool: around a dozen presented a fake key, and more than 300 quietly routed traffic via the same interception servers.

Exit policies were also altered to block the TLS mail ports while allowing plaintext ones, pushing mail retrieval through those relays into cleartext.

The Quetzalcoatl account is the most useful part for defenders. Their entry point was not an exotic exploit: the attacker logged in to an internet-facing management server on 28 August with the correct operator password at the first attempt. That password doubled as the sudo password and a backup passphrase, sat in cleartext in a helper script, and the server still accepted password logins. The attacker then most likely hopped from it to a relay server, where Ebury was installed one second after the login.

Their forensic notes explain why Ebury is so hard to spot. The implant lived as a single setuid library alongside the genuine libkeyutils, with the symlink re-pointed at it, so package verification tools reported nothing wrong. Its backdoor logins left no PAM records, log lines or shell history, and because sshd has to decrypt a password to check it, the implant saw every password typed, failed attempts included. ESET’s published indicators stop at 1.8.2, and its detection script missed this build, though one YARA rule still matched.

Timeline of the Ebury Tor exit relay SSH interception campaign from August to 23 October 2026

Why it matters for UK organisations

Few UK businesses route administrative SSH over Tor, but this is not a niche privacy story. The interception relied on a behaviour that exists in almost every IT team: clicking through, or deleting the known_hosts entry, when SSH complains that a host key has changed. The same habit exposes administrators on hotel Wi-Fi or any hostile network.

Ebury itself is not new or rare. In the mailing list thread, the researcher behind ESET’s reports points to around 400,000 servers compromised by Ebury between 2009 and 2023, and suggests other Tor relays are probably still infected. Hosting customers, managed service providers and anyone with a sizeable Linux estate should assume it is still circulating.

There is a supply chain lesson too. In the Quetzalcoatl case, one compromised jump host put a relay server and every device on its VPN within the attacker’s reach, and many UK organisations run a bastion with that level of trust.

Expert view

In my experience, the host-key warning is one of the most valuable and most ignored security controls in the Unix toolset. When we test infrastructure, we routinely find teams who rebuild servers without preserving host keys, so mismatches become normal noise and everyone learns to clear them. This incident shows what that conditioning costs. A changed key on a server that has not been rebuilt should be treated as an incident, not an annoyance.

The root cause here was depressingly familiar: password authentication left enabled on an exposed host, a password reused across functions, and a secret stored in plaintext. Credit is due to the Tor Project, which flagged the relays over a weekend within two days of the first report, and to the operator who published a full timeline when most Ebury victims stay silent.

For detection, file integrity checks alone will not do. The telling signals in the Quetzalcoatl case were behavioural: root actions with no logged-in user, unrequested service reloads and sshd logging that had quietly changed.

What to do now

  1. Disable SSH password authentication on internet-facing hosts. Move to key-based or certificate-based authentication, ideally with hardware-backed keys for administrators. This maps directly to the Cyber Essentials secure configuration and user access control requirements.
  2. Treat host-key mismatches as security events. Use SSH certificates or published fingerprints, preserve host keys across rebuilds, and tell staff to stop and report.
  3. Hunt for Ebury on Linux estates. Look for unowned or setuid libraries next to libkeyutils, re-pointed symlinks, processes whose binaries are missing from disk, and unusual abstract sockets. Use updated YARA rules.
  4. Watch for behavioural anomalies. Alert on root activity without a matching login or sudo record, package history entries with no requesting user, unexpected NAT rules redirecting port 22 and unexplained changes to sshd logging levels.
  5. Kill password reuse and plaintext secrets. Separate login, sudo and backup credentials and keep secrets out of scripts.
  6. Rebuild, do not clean. If you find Ebury, isolate the host, preserve disk and memory, reinstall from scratch, and treat every credential and key that touched it, including anything in known_hosts, as compromised.
  7. Harden jump hosts. Limit what a bastion can reach, monitor it closely and never store backups of administrator keys on it.

Bottom line

A tenth of Tor’s exits became an SSH trap, and the warning that would have saved every victim was already on their screen. Disable password logins, respect host-key warnings and hunt for Ebury by behaviour, not checksums.

Sources

Related Posts