Cybersecurity News
Cybersecurity News Alert: 333 Tor Exit Relays Hijacked
By Nattapong Sukkasem · Published · Updated .
TL;DR — For roughly three days in early October, someone controlled about a tenth of the Tor network's exit capacity and used it to funnel every SSH connection into twelve interception servers. Passwords typed into those sessions were captured and replayed; where the account had sudo, the attacker installed Ebury 1.8.3, a Linux credential stealer in circulation since 2009. The findings, published on 20 October by a researcher known as kaba, make this week's most instructive piece of cybersecurity news — not because the cryptography broke, but because none of it had to.
The most useful cybersecurity news stories are the ones where every component behaved exactly as designed. Nothing in Tor was exploited here. No protocol was broken, and there is no CVE to patch. An attacker obtained shell access to the Linux hosts that volunteers run Tor relays on, edited a text file called torrc, and reloaded the daemon. By the afternoon of 4 October those relays were carrying 7.46% of all Tor exit capacity, measured by the network's own published consensus weight.
A policy change, not an exploit
An exit relay's ExitPolicy is a short list of ports it is willing to open on the public internet. Most operators block TCP 22. The attacker inverted that default everywhere at once: 342 relays that had been refusing SSH began accepting it, and 24 relays that were not exits at all became exits. The same edit closed IMAPS and POP3S while opening their plaintext equivalents, POP3 and IMAP.
Analysis of Tor's directory data counts 377 relays across 59 operators adopting the attacker's exit policy between 1 and 4 October — a figure the analysis is careful to describe as a policy match rather than proof of compromise. On 1 October, 40 relays belonging to 21 separate operators changed within about five and a half minutes — hard to explain unless one party already held access to all of them.
| Date (2026) | Event |
|---|---|
| 28 August | Attacker logs into one operator's management server with the correct password on the first attempt; root in under five minutes; Ebury installed |
| 2 October | Researcher kaba hits a changed-host-key warning over Tor, scans ~3,000 exits with exitmap, reports 333 of them that evening |
| 4 October, 18:00 UTC | Directory authorities begin voting BadExit and MiddleOnly; both in the consensus by 21:00 UTC |
| 5 October, 17:00 UTC | No relay carrying the attacker's policy remains in the consensus |
| 20 October | kaba publishes the full scan results; Tor's exit-relay count has still not recovered |
What happened to an SSH session
Traffic leaving a hijacked relay on port 22 went to one of twelve interception servers rather than to its destination. About a dozen relays presented a substituted host key; the other three hundred or so forwarded traffic to the same infrastructure without touching it. A returning user saw OpenSSH's REMOTE HOST IDENTIFICATION HAS CHANGED banner. A first-time user saw the ordinary new-key prompt, which looks like nothing at all.
If the user typed a password, it was captured. The interceptor then opened its own connection to the real server with those credentials, checked the user ID and whether sudo was available without a password, and decoded and ran a base64-encoded Perl installer. Meanwhile it forwarded the victim's commands through to the real host, so the session worked normally.
Key-based logins could not be relayed. Under RFC 4252 the client signs a blob containing the session identifier, which differs between the victim's connection and the attacker's, so the signature is worthless one hop further on. That is the whole ceiling on this campaign: an authentication method chosen years earlier on each server decided whether the interception worked. There was no zero-day vulnerability to buy around it.
Ebury, and why server infrastructure keeps it
The payload is not new. Ebury is an OpenSSH backdoor and credential stealer first seen in 2009; ESET estimated in 2024 that it had passed through 400,000 servers, with more than 100,000 still infected at the end of 2023. It persists by dropping a counterfeit libkeyutils next to the real one and repointing the symlink, so dpkg -V and debsums report a clean system. One operator's post-mortem, published 7 October, confirmed version 1.8.3 on two of his machines and noted that it survived a reboot.
Indicators from that post-mortem: a setuid libkeyutils.so.1.10.2 owned by no package, with a different hash on each host; the abstract UNIX socket @event-0YsOG9WSOE; a fake /sbin/rsyslogd running inside the ssh.service cgroup; and the login source 185.225.226[.]62. ESET's Marc-Etienne M. Léveillé notes that published detection scripts stopped at 1.8.2 and that 1.8.3 has circulated since at least June 2026 — which means the installed base across Linux server infrastructure is not knowable from current public indicators.
The intrusion that started it is almost banal. One password served for SSH login, for sudo, and as a backup passphrase; it sat in plaintext in a script on two machines; password authentication was enabled on an internet-facing host that was simultaneously the VPN gateway, the SSH jump box and the backup store. The relay family's supposedly offline master keys were inside a workstation backup on that same server, encrypted with the password that had already been stolen. This is a cloud security problem in the oldest sense: the blast radius was set by how much the convenient box was allowed to hold.
Three trust systems, one of which has no revocation
The thing worth taking away sits in the gap between how fast Tor fixed its half and how permanently it could not fix the other half. Tor publishes a signed consensus naming every relay and what it may do; the directory authorities voted BadExit and the hijacked relays stopped receiving exit traffic within three hours. DNS has an authority, signatures and a TTL bounding how long a stale answer survives. SSH host keys have neither.
| Layer | Who asserts identity | Revocation |
|---|---|---|
| Tor relay | Directory authorities, by signed consensus | Push; flags live in ~3 hours |
| DNS / DNSSEC | The zone's own signing keys | Bounded by TTL and key rollover |
| TLS certificate | A third-party CA, logged in Certificate Transparency | CRL, OCSP, browser push lists |
| SSH host key | The user, once, from memory | None |
Trust on first use asks the person at the keyboard to be the entire public key infrastructure, at the least convenient moment, with a yes/no prompt. Everyone who typed a password into a hijacked session between 1 and 5 October is still exposed, because there is no channel to tell them. Tor revoked the relays; nobody can revoke a password that a human typed. No count of affected users exists, and the campaign's attribution remains unknown.
Why a resolver operator should care
The mechanism here is the same one that makes name resolution worth defending: whoever controls the last hop chooses the destination. On an ordinary corporate network, the equivalent position is far cheaper to obtain, and the usual route to it is the resolver.
Note what the attack did not do, because it shapes how this reached cybersecurity news at all. It did not take capacity down — a DDoS attack moves the graph first and the investigation follows. Here the only visible dent in Tor's public metrics, a drop of roughly 370 exit-flagged relays, came from the cleanup rather than the attack. DNS over HTTPS is a genuine improvement for the resolution path, but it is worth being clear about scope, and it is one of the most common questions in our FAQ: encrypting a query authenticates the resolver, not the destination you eventually reach.
What to check this week
- Turn off SSH password authentication. Keys were structurally immune to this campaign. Everything else in this story is downstream of that one setting.
- Treat a changed host key as an incident. It is the only signal the protocol gives you, and a researcher who refused to click past it is the reason this was found at all.
- Rotate anything typed over Tor between 1 October and the afternoon of 5 October, and check the host for the Ebury indicators above.
- Audit what your jump hosts hold. A box that is also the VPN gateway and the backup store is not a bastion; separating those is the cheapest IT security win in this entire incident.
What it means
How the other 58 operators' hosts were breached is unknown; a compromised hosting provider has been suggested but not confirmed, and no provider has been named. Attribution is absent.
What this piece of cybersecurity news demonstrates is how little a competent attacker now needs. No exploit, no zero-day, no novel tooling: a reused password, a seventeen-year-old backdoor, and a text file edited across enough machines to matter. The defences that held were old and dull — public key authentication, a signed consensus with a working revocation path, and one person who read a warning instead of dismissing it. The defence that failed was the one that asks a human to remember a fingerprint. That asymmetry is the durable lesson of this week's cybersecurity news, and it is the same one the eMudhra CA key compromise taught from the opposite direction a day earlier: trust decisions are only as good as the channel available to undo them.
Sources
- The Hacker News — Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections
- SecureWorld — Tor Exit Relay Hijack: ‘The Root Cause Was Ours’
- GBHackers — Hackers Compromise 333 Tor Exit Nodes to Steal SSH Credentials and Deploy Ebury Malware
- IT-Connect — 333 compromised Tor exit relays intercepted SSH connections to spread Ebury
- SC Media — Hijacked Tor exit relays used to intercept SSH connections
Related articles
Browse every DNS news article by month →
DNS angle
Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.
Source: The Hacker News — Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections ().