When the Exit Node Turns Hostile: Inside the Hijacking of 333 Tor Relays

I. A Warning in the Terminal

Tor divides the path between a user and an ordinary internet destination across separate volunteer-operated relays. The guard sees the connection from the user; the middle forwards traffic without possessing the full path; the exit sends traffic to the external destination. That division is meant to stop any one relay from learning both who the user is and which external service they are reaching. ^[6]

On October 2, this architecture created an important separation. A hostile exit could manipulate the last hop to a service, but it did not thereby recover the originating user’s IP address from Tor’s layered encryption. The user could remain hidden from the destination while still being deceived about which server was answering. Those are different guarantees.

The distinction is also why this report concerns ordinary internet exit circuits. A Tor onion service is reached through a rendezvous arrangement inside Tor rather than through the same kind of internet exit. Onion services were not shown to be compromised by the exit-node redirection mechanism described here. ^{[8, 16]}

II. What an Exit Relay Can—and Cannot—See

A normal exit relays encrypted SSH packets to their destination. SSH then negotiates a secure session directly between the client and the destination server. The client authenticates the server’s public host key before trusting that session. Tor’s own encryption and SSH’s host authentication therefore protect different boundaries. ^{[6, 17]}

With a hostile exit, the last leg can be altered. A relay may redirect a connection to an attacker-operated host and allow that host to negotiate a new SSH session. When a known server suddenly presents a new key, a properly configured client warns the user. On a first connection, the client may instead ask the user to approve an unfamiliar key—the familiar trust on first use problem.

Accepting the attacker’s identity does not let the attacker mathematically decrypt the original SSH session. It can persuade the user to establish a different encrypted session with the attacker. That difference is central to understanding how a privacy tool can be working as designed while a user still loses credentials.

The official Tor documentation is explicit about what an exit policy can decide: which destinations and ports a relay will carry. That administrative power is also useful to an attacker controlling the relay configuration. ^[9]

III. The SSH Interception

Kaba used a Tor exit-testing tool called exitmap and two servers under his control. He forced a connection through each exit, checked the SSH host key received at one end and inspected the source address arriving at the other. That approach distinguished a connection coming directly from the selected exit from one arriving through a separate interception machine. ^[1]

His scan of roughly 3,000 Tor exits identified 333 relays sending SSH connections toward 12 interception servers. Of those 333, roughly a dozen were observed substituting SSH host keys in his tests. More than 300 others redirected connections through the same infrastructure without presenting substitute keys in those tests. These observations demonstrate redirection and, in some cases, server impersonation—not 333 successful password thefts.

The credential risk arose when a user accepted the substitute server identity and used password authentication. The attacker-controlled SSH endpoint could read that password because it was the endpoint receiving the encrypted session, then connect separately to the real server. Kaba’s controlled honeypot recorded follow-on attempts to check permissions and execute an Ebury installer. These observations show an operational intrusion technique, not the number of ordinary users who fell for it. ^[1]

Public-key authentication changes the picture. Under SSH’s protocol, the signature used to authenticate with a private key is tied to a specific session identifier. A signature made for the impostor session cannot simply be replayed against the real server. This does not make an accepted impostor harmless: it can still deceive a user about where commands are going. But it removes the simple password-reuse path demonstrated in these tests. ^[7]

IV. Inside the Operator Breach

The hijacking was not limited to forwarding rules that redirected SSH. Public Tor directory records documented conspicuous changes to the ExitPolicy settings broadcast by affected relays. Many began allowing destination port 22, which permits SSH connections. At the same time, policies blocked ports conventionally used for encrypted mailbox retrieval, including IMAPS on 993 and POP3S on 995. Many still allowed POP3 or IMAP on ports where plaintext is possible, although TLS upgrades are also supported. ^{[3, 4]}

That combination creates an obvious interception opportunity, but it does not prove a forced downgrade of email clients. A properly configured client may refuse to fall back to an insecure method, and Tor exits cannot simply compel clients to use different destination ports. No reliable public count of intercepted mail or captured credentials has been established.

One affected relay operator, publishing under the Quetzalcoatl name, provided the clearest host-level explanation. The operator examined a Contabo virtual server used as a management and VPN gateway and a second host called Switzerland2, which ran two exit relays. Both showed Ebury 1.8.3, a persistent OpenSSH backdoor. That finding is direct evidence for two examined machines, not a diagnosis of hundreds of unexamined servers. ^[3]

The surviving logs placed the first known intrusion on August 28. An attacker authenticated to the management server with a valid operator password on the first attempt, obtained root privileges within minutes and installed Ebury. Later that morning, the attacker reached Switzerland2, where the accepted SSH key could not be reconciled with the key files the investigators recovered. The operator explicitly left that second-hop authentication mechanism unresolved.

Its postmortem was candid about operational mistakes: SSH password login on an internet-facing management system; one password reused for login, privilege elevation and an encrypted backup; plaintext secrets in scripts; and copies of supposedly offline master-key material stored in a backup on the connected management server. Investigators saw evidence that backup metadata was decrypted, but they could not establish whether the complete backup was exfiltrated. ^[3]

On October 2, the host’s relay instance configurations were altered without corresponding ordinary login records. A routine reboot on October 4 stopped some hidden utilities, yet Ebury returned. The account illustrates a familiar security inversion: a machine can remain physically in its owner’s possession while administrative commands originate from an adversary.

V. Ebury: An Older Warning

Ebury is not a new cryptocurrency-specific exploit, nor was it created for Tor. In May 2024, ESET published a major retrospective estimating approximately 400,000 Linux servers compromised by Ebury since 2009, including more than 100,000 believed infected as of late 2023. That is a historical estimate of the malware’s reach, not a 2026 Tor victim count. ^[5]

ESET also documented how Ebury operators exploited compromised hosting infrastructure, manipulated SSH traffic and stole financial information. Its investigation described prior attacks affecting Bitcoin and Ethereum node operators. Those earlier cryptocurrency thefts are a useful precedent for why an attacker might value SSH credentials on internet-facing servers. They are not evidence that the October Tor operation drained cryptocurrency wallets.

The version found by the Quetzalcoatl operator, Ebury 1.8.3, contained indicators different from some older public detection guidance. Investigators found it masquerading as a system library; ordinary package checks could still report legitimate packages as intact. Backdoor activity could avoid the usual authentication records, complicating reconstruction. That helps explain why apparently quiet audit logs do not necessarily establish that a root-compromised system is clean. ^{[3, 5]}

The identity and number of operators behind the Tor campaign remain unknown. Similar tools, timing and policy changes suggest coordination, but attribution requires evidence beyond recognizing an established malware family.

VI. Discovery, Scope and Response

Kaba reported his findings to the Tor Network Health team on the evening of October 2. By October 4, affected operators were receiving warnings and the directory authorities were taking steps to stop suspicious relays being selected for exit traffic. The Tor Project’s October 5 notice described compromised Linux hosts, unauthorized changes that turned some non-exits into exits, and indicators such as port-22 redirects and unexpected system processes. ^{[1, 2]}

Independent analyst Tor at 1AEO then reconstructed the public directory record using historical server descriptors, consensus documents and directory-authority votes. From October 1 through October 4, the analyst identified 377 relay identities associated with 59 operator identifiers that adopted one of two distinctive policy patterns. It is a powerful network-level observation, but the author was explicit: a matching exit policy is not equivalent to forensic proof of a compromised host. ^[4]

At 01:00 UTC on October 4, 351 policy-matching relays accounted for 7.46% of the consensus weight of usable exits. That is a measure of network selection capacity at one point in time—not a claim that 7.46% of Tor users were intercepted. On October 5, no relay still publishing either characteristic policy remained listed as a usable exit by 17:00 UTC. Removal from consensus prevented normal client selection; it did not certify that every underlying host had been disinfected. Nor did that intervention retrospectively identify the users whose connections might have passed through affected exits during the attack window. ^[4]

The incident also shows how open infrastructure produces usable evidence. Relay configurations and directory decisions were publicly observable, independent researchers could reproduce the policy comparison, and a mismatched server identity gave the initial user a concrete reason to investigate. None of that made the malicious relays harmless. It did make their behavior easier to document and constrain.

VII. What the Numbers Actually Show

Numbers tend to harden into a story before anyone asks what they represent. Here there are at least four distinct objects of measurement: Tor relay identities, physical or virtual hosts, administrative operators, and people whose traffic was successfully intercepted. They are not interchangeable.

The 333 figure comes from Kaba’s active attempt to route SSH through individual exits. The 377 figure comes from a historical comparison of published exit policies, across several days, including some relays that had previously been non-exits. The 59 figure is a count of operator identifiers derived from directory data; it does not independently identify 59 people or organizations. The 7.46% figure is the peak weighted share of usable exit capacity under the matching policies. ^{[1, 4]}

Most importantly, none measures the unknown number of successful victim logins. To lose a password by the technique observed, a user would have needed to connect through a relevant relay at the relevant time, encounter a substituted endpoint, accept or fail to verify its host identity, and supply a password. Kaba’s controlled test showed the threat was real; it did not establish how often those conditions were met in the wild.

The affected operator also warned against over-generalizing its own case. Its two hosts showed no trace of certain persistence indicators listed in the Tor Project advisory, even though Ebury was present. Different compromised systems may have displayed different behavior. A useful security investigation records those mismatches rather than flattening the whole campaign into one guessed intrusion chain. ^{[2, 3]}

VIII. The Decentralization Test

It would be tempting to describe this as decentralization failing. The facts invite a more demanding question: what kind of decentralization, at which layer? Tor’s relays are operated independently, but individual operators may rely on centralized management hosts, shared administrator identities, common hosting companies and a small number of privileged credentials.

In the examined Quetzalcoatl case, the management server was a hub of trust. It provided legitimate automation and connectivity across infrastructure, yet the password-based compromise gave the attacker a path into systems that were supposed to operate as separate relays. The operator’s encrypted workstation backup was also stored within reach of that management hub. Multiple relays did not mean multiple independent administrative failure domains. ^[3]

But the response demonstrates the opposite property of open coordination. The Tor Project’s directory authorities could mark bad exits or refuse descriptors, operators could take machines offline, and independent observers could examine the public consensus. Decentralization did not make a compromise impossible. It helped make abnormal network behavior measurable and created mechanisms to stop affected relays serving as exits. ^{[2, 4]}

That suggests a more useful measure of resilience than the simple number of nodes: how independently are they controlled, how quickly can hostile behavior be recognized, and what recovery mechanism exists when trusted participants become adversaries? A network may distribute its components yet concentrate its keys. A network may also contain a malicious participant without proving its operators were never compromised.

IX. Tor, Mixnets and Ryo’s Network Roadmap

The Tor case should not be confused with every attack on network anonymity. Exit interception exploits control of the route to an ordinary external service and the user’s trust in that service’s identity. Timing correlation is different: an observer uses the relationship between when traffic enters and leaves a network to infer communication links, potentially without reading the content or impersonating the destination. ^{[6, 13]}

The distinction also explains why the Ryo roadmap belongs in this discussion. A future privacy network assembled from participating nodes must address not only what observers can infer from message timing but also what happens when a relay, operator or administrative key is compromised. Those are separate engineering problems, and a defense against one does not automatically solve the other.

That second problem is the motivation behind mix networks. David Chaum’s foundational work described routing messages through intermediate systems that conceal their association. Later research such as Loopix has examined message delays, cover traffic and techniques for detecting some active attacks. Such systems trade latency and complexity for different forms of metadata protection. Their actual security depends on the implementation, traffic volume, adversary model and integrity of participating nodes. ^{[10, 11]}

This distinction matters for Ryo Currency. Ryo currently relies on private-by-default, RingCT-based transaction confidentiality. Its transition to Halo 2 zero-knowledge proofs is in testing and deployment. According to the developers, the core coding is largely complete, while testing and deployment coordination continue; this is not an independent security audit or a confirmation of completed network-wide activation. Ryo also plans a high-latency mixnet to make transaction-broadcast origins and timing relationships harder to correlate. That network layer is a proposed future capability, not a deployed, adversarially validated guarantee. ^{[12, 14, 15]}

The earlier Ryo mixnet article describes the intended design in terms of batching, shuffling, delayed forwarding and possible decoy traffic. Those are legitimate research directions, but their protection cannot be inferred from terminology alone. The design must specify how it handles hostile mixes, compromised administrators, packet tagging, route concentration and practical throughput constraints. ^{[11, 12]}

Our earlier ProxyMark investigation examined a different boundary again: research suggesting potential Monero-origin inference from interactions among peer selection, application behavior and Tor routing under specific adversarial conditions. Neither ProxyMark nor the October exit-relay case breaks the underlying cryptocurrency proofs. Both illustrate why a private ledger does not automatically produce private network metadata. ^[13]

The lesson for Ryo is therefore neither that Tor is obsolete nor that a future mixnet would have prevented this SSH attack. A well-designed mixnet may reduce certain correlation opportunities. It cannot make a fraudulent SSH host key genuine, recover stolen operator secrets, or protect a wallet on an already compromised machine. Transaction secrecy, network anonymity and endpoint integrity need distinct defenses.

X. Reclaiming the Security Boundary

For anyone who administered a server through Tor during the incident window, the first question is whether they encountered an unfamiliar or changed SSH host key and proceeded anyway. If a password was supplied after accepting a suspect identity, treating that credential as exposed is prudent. The destination server should also be examined for unexpected privileged access or persistence. This is a risk-based recommendation, not a claim that every connection was intercepted. ^{[1, 2]}

The broader preventive lesson is straightforward: verify host-key fingerprints through a trusted channel, avoid password-based SSH where possible, and protect signing keys from routine workstations. Hardware-backed key storage can reduce the exposure of private authentication material, although it does not make an already compromised machine trustworthy. SSH public-key authentication also prevents simple reuse of a captured password in the specific attack pattern described. ^[7]

For relay operators, the Tor Project recommended reviewing unauthorized torrc changes, unexpected exit flags, port-22 redirection rules, new accounts or persistence, and unrecognized network activity. If compromise is suspected, the guidance favors taking systems offline, preserving evidence, reinstalling from trusted media, replacing relay identities and rotating exposed credentials rather than merely restarting Tor. ^[2]

The Quetzalcoatl postmortem adds an especially uncomfortable reminder. An encrypted backup protected by a password already exposed to an attacker is not meaningfully isolated from the compromised system holding it. Nor is an operational key genuinely offline simply because its primary copy was generated elsewhere. Recovery depends on the boundaries you have actually maintained, not the names attached to them. ^[3]

Conclusion: Verify the Boundary

The October operation began, from the public researcher’s perspective, with one server presenting the wrong identity. It expanded into evidence of hundreds of suspicious Tor relays, a coordinated redirection infrastructure, a candid operator postmortem and a network-wide defensive response.

The precise number of stolen passwords is still unknown. The path into many affected hosts remains unresolved. Those gaps should remain visible. They do not diminish what the confirmed record teaches: a protective network can carry traffic through machines whose owners have lost control, and encrypted connections can still lead users to an impostor if endpoint identity is ignored.

The lasting conclusion is about layered trust, not a verdict on Tor or a promise about any alternative design. Decentralization can distribute authority. It cannot remove the need to authenticate, monitor and recover it.

Further Reading from ryo.news

• ProxyMark and Monero over Tor: How Privacy Can Fail Between Layers — a distinct research case concerning peer behavior and network-origin inference.
• Ryo Currency’s High Latency Mixnet vs. Tor and VPNs — an earlier overview of proposed network-metadata protections.
• Enhancing Privacy with Halo 2 and High Latency Mixnet — conceptual discussion, including illustrative figures that should not be treated as measured anonymity performance.