333 Tor exits redirected SSH: the host-key warning was the decisive boundary

The scan found a redirect, not 333 stolen passwords

The decisive moment in this case is an SSH host-key prompt. On 2 October, a researcher writing as kaba tested specific Tor exits and found 333 relays sending SSH connections to 12 interception servers instead of the intended destination. In roughly a dozen tests, the intermediary presented a substitute host key. If the user stopped at the warning, the password stayed out of that session; if they accepted the substitute key and typed a password, the intermediary could receive it. The reports do not count how many people did either.

The Tor Project's network-health team separately said operators had reported hacked Linux relay hosts, edited Tor configurations and SSH interception. It removed suspect relays from exit use while investigating how the hosts were entered. That corroborates a host-level incident, but does not turn kaba's 333 redirected exits into a victim count.

Two numbers measure different things

Source scopes and time windows, read 21 October 2026. The figures must not be added together or treated as victim counts.

Measure	Result	What it establishes
Active probe of SSH routing	333 exits in kaba's 2 October scan; 12 interception servers	A measured redirection path for port 22 at that test time. It does not measure successful password capture.
Tor directory-policy analysis	377 relays with one of two policy changes across 1 to 4 October; 147 IP hosts, 59 ContactInfo-defined operators	A policy match in published descriptors, explicitly not proof each host was compromised.
Peak network share	351 matching relays, 7.46% of usable-exit consensus weight at 01:00 UTC on 4 October	A share of exit selection weight at a particular hour, not a share of Tor users intercepted.
Confirmed Ebury case	Two servers described by one relay operator	Firsthand host-level evidence; it does not prove Ebury was present on all matching relays.

The directory analysis reconstructed public descriptors and consensus votes through 9 October. Its 377-relay set is broader than kaba's 333 active SSH redirects because it asks a different question: who published the distinctive exit policy, rather than what a live SSH test reached. It found 342 of 366 relays with a previous policy newly opened port 22. The same changes closed encrypted IMAPS and POP3S on 334 and, for many relays, left plaintext-capable POP3 and IMAP open. The policy data shows a traffic-selection opportunity, not actual mail contents read or the attacker's motive.

At 5 October 17:00 UTC, no relay with either identified policy was listed in the analysis's consensus data. That is a time-bounded historical observation. It is stronger than a vague 'taken down' claim and narrower than a guarantee that no compromised operator host remained.

Where the SSH protection held, and where it could fail

The malicious exit was a routing position. It could redirect a port-22 connection to an interceptor, but it could not invisibly become a previously trusted SSH server. SSH binds the encrypted session to a server host key. When kaba's connection was intercepted, OpenSSH displayed its prominent changed-host-key warning. A first-time connection has no saved key for comparison, so the user must validate the fingerprint through an independent channel rather than accept a new prompt automatically.

In a honeypot test, kaba saw the intermediary use Paramiko, a Python SSH library. The test showed an attempt to assess privileges and run a base64-decoded Perl installer on the target. This is evidence of attacker behaviour in the controlled test, not proof the same installer succeeded on every real destination.

Password and public-key authentication differ here. A password typed into an accepted connection is available to the server at the other end, which would be the interceptor. A public-key signature for one SSH session contains that session's identifier, so it cannot simply be replayed into a different connection to the genuine host. The interceptor could still deceive the user with a fake session; this is not permission to disregard a host-key warning.

One operator found Ebury; the broader entry route is still unknown

A Quetzalcoatl relay operator's account describes Ebury 1.8.3 on two of its servers: a management host and a FranTech VPS running two exits. The operator reconstructed an August intrusion using logs and files, while warning that logs had been truncated, timestamps altered and some steps inferred. That account establishes an Ebury case on those machines. It does not show how every other operator's host was entered.

The public directory analysis grouped 377 policy-matching relays under 59 operator identifiers and found a strong concentration among certain FranTech-hosted relays. Those are correlations requiring investigation, not evidence that the hosting provider itself was breached. Kaba explicitly described a provider compromise as a theory, and the Tor Project notice did not identify an entry route or responsible group. An actor's use of Ebury also does not, on its own, identify the actor.

Evidence ladder for the incident. Each row supports only the conclusion in its right-hand column.

Observed record	Supported inference	Still open
Changed Tor exit policy and port-22 redirection	A set of relays could steer selected SSH connections	How each operator host was accessed
Substitute SSH host key in some tests	An interception server was reachable and impersonating the destination	How many users accepted it and supplied a password
Ebury found on two operator servers	Those two servers had a host-level backdoor	Whether other policy-matching hosts had Ebury or a different intrusion

What users and relay operators should check

This incident concerns SSH connections leaving Tor through an exit relay. A direct connection or an onion service has a different path. Likewise, a malicious exit cannot by itself decrypt correctly authenticated HTTPS or SSH. The practical control is to verify the endpoint identity and to treat any compromised relay host as an infrastructure intrusion, not just a configuration mistake.