Tor Relays Hacked to Intercept SSH Connections

The Tor Project is urging Linux relay operators to audit their servers after attackers broke into some volunteer-run relays, quietly reconfigured them as exit relays and used them to intercept SSH connections.

In an advisory, the project said the affected relays have been flagged. Tor’s directory authorities, the small set of trusted servers that decide which relays enter the network consensus, are now rejecting them.

The first reports reached the Tor Project over the weekend of October 3–4. Operators said their machines had been hacked, their tor configuration file (torrc) edited, and their relays left intercepting SSH traffic. According to the advisory, the attacker appears to be gaining access to Linux hosts. When a machine was running as a non-exit relay, the attacker rewrote its torrc to turn it into an exit relay. Tor’s Network Health team is still working out how the servers were compromised, and the project has not said how many relays were affected.

The conversion is the core of the attack. A Tor circuit passes through three relays. The guard and middle hops handle only encrypted cells, and only the exit relay opens the final connection to the destination server. A hijacked middle relay is useless for watching traffic, so the attacker had to promote it. Tor’s checklist asks operators to hunt for NAT rules that redirect port 22. That indicates SSH connections leaving the exit were being diverted to a listener on the compromised machine rather than reaching their intended destination.

SSH encrypts sessions end-to-end, so intercepting a session means impersonating the server with a different host key. Clients that have connected before will show a host-key mismatch warning. The people at risk are those connecting to a server over Tor for the first time, or anyone who accepts a changed key without checking it. The Tor Project has not said whether any credentials were captured.

The intrusions also went beyond a config edit. Tor told operators to watch for unauthorised kernel module loading, unexpected tunnelling interfaces and unexplained memory usage. It also said one reported technique set up root persistence through a fake uppercase “CRON” daemon. The disguise is well chosen: on Debian and Ubuntu, the legitimate cron service’s child processes already appear as CRON in process listings, so an impostor with the same name is easy to skim past.

What Tor is asking relay operators to check

Operators should first look up their relay on Tor Metrics Relay Search and confirm it does not carry an Exit flag or an exit policy they never set. On the server, Tor wants torrc and any files pulled in through %include paths checked for changes to ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname. Operators can list NAT rules with nft list ruleset or iptables -t nat -S, and find unknown listeners and outbound connections with ss -tnp. The tor binary can be verified against the distribution package with debsums tor or rpm -V tor. New user accounts, authorized_keys entries, cron jobs, and systemd units also need to be reviewed.

For a relay that looks compromised, the advice is to rebuild, not clean up. Operators should take the relay offline, preserve the disk and logs, reinstall, and rotate every credential that lived on the host. They should also generate a fresh relay identity, since the advisory says the old keys “must be treated as stolen.” Georg Koppen of Tor’s Network Health team added in the thread that operators whose IP addresses were blocked during the incident should email once their servers are clean, so the address can be removed from the block list.

The biggest open question came from the operator community. One operator, posting as mpan, reported a clean relay but asked whether the intrusions share an entry point, noting that a single campaign typically exploits a single vulnerability. The alternative is that someone is working through relays one at a time. The thread has not answered that publicly.

An old target, a different route in

Malicious exit sniffing of SSH is not new to Tor. In 2014, Karlstad University researchers Philipp Winter and Stefan Lindskog identified 19 exit relays conducting man-in-the-middle attacks, five of which targeted SSH. In 2017, Tor removed a relay after a user reported it was attempting to intercept SSH sessions. Later campaigns, such as the group tracked as BTCMITM20, added large numbers of fresh exits that were spotted and removed as they appeared.

Those attackers ran their own exits. This one was borrowed from other people. The hijacked machines came with existing uptime and a real operator’s name attached, rather than appearing as an unknown batch of new relays.

As of October 15, the Tor Project had not published a count of affected relays, how long they served as exits, or how the attacker got in.