Security incident affecting some relay operators
Hello Tor relay operators, We encourage relay operators running Linux to audit their tor configuration file (torrc) and monitor for unauthorized kernel module loading, tunnelling interfaces or unexplained memory usage. Background: Over the weekend we received reports that relays of some of our operators were intercepting SSH connections. According to the operators their servers were hacked, the tor config had been edited and the relays were intercepting SSH connections. It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack. The Tor Network Health team are investigating the issue and looking into how these machines were compromised. For now, we have been flagging those affected relays and the directory authorities are rejecting them from the network. What you can do: Audit your relay looking for potential sign of compromise. * On Tor Metrics Relay Search: does your relay show the Exit flag or an exit policy you didn't set? * Check torrc and anything in %include paths for ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname changes. * Look for NAT rules redirecting port 22 (nft list ruleset, iptables -t nat -S). * Look for unknown listening processes or outbound connections (ss -tnp). * Verify the tor binary against your distribution package (debsums tor or rpm -V tor). * Look for new users, authorized_keys entries, cron jobs or systemd units. One of the techniques that were reported involved establishing root cron persistence via a fake uppercase CRON daemon. If you suspect a relay got compromised: take the relay offline, preserve disk and logs before wiping, reinstall rather than clean up, generate a new relay identity (the old keys must be treated as stolen), and rotate every credential that was on the host. Reach out: If you have been affected or if you have more information about this incident, please reach out to bad-relays@lists.torproject.org. Please stay vigilant and thanks for running relays. -hiro
On 05/10/2026 19:50, hiro via tor-relays wrote:
Over the weekend we received reports that relays of some of our operators were intercepting SSH connections. According to the operators their servers were hacked, the tor config had been edited and the relays were intercepting SSH connections.
But to avoid panic reactions, something like e.g. this tfoerste@p14s ~ $ ssh i30 ss -4tnp | grep ':22 ' SYN-RECV 0 0 194.164.53.4:22 81.162.210.95:47267 ESTAB 0 0 194.164.53.4:36330 94.142.244.24:22 users:(("tor",pid=603,fd=299)) is totally harmless: The usual port 22 hammering, and a re,mote relay which has its ORPort configured at port 22. ;) -- Toralf
Hello Tor relay operators,
We encourage relay operators running Linux to audit their tor configuration file (torrc) and monitor for unauthorized kernel module loading, tunnelling interfaces or unexplained memory usage. (…) Hello, thanks for monitoring and the warning.
Seems clean here, but is there any pattern in how the actor gains access to the systems? A single campaign usually exploits one vulnerability nowadays. Or does it seem somebody is indeed meticulously work out each node one by one? Cheers, mpan
hiro via tor-relays:
Hello Tor relay operators,
We encourage relay operators running Linux to audit their tor configuration file (torrc) and monitor for unauthorized kernel module loading, tunnelling interfaces or unexplained memory usage.
Background:
Over the weekend we received reports that relays of some of our operators were intercepting SSH connections. According to the operators their servers were hacked, the tor config had been edited and the relays were intercepting SSH connections.
It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack.
The Tor Network Health team are investigating the issue and looking into how these machines were compromised. For now, we have been flagging those affected relays and the directory authorities are rejecting them from the network.
What you can do:
Audit your relay looking for potential sign of compromise.
* On Tor Metrics Relay Search: does your relay show the Exit flag or an exit policy you didn't set? * Check torrc and anything in %include paths for ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname changes. * Look for NAT rules redirecting port 22 (nft list ruleset, iptables -t nat -S). * Look for unknown listening processes or outbound connections (ss -tnp). * Verify the tor binary against your distribution package (debsums tor or rpm -V tor). * Look for new users, authorized_keys entries, cron jobs or systemd units. One of the techniques that were reported involved establishing root cron persistence via a fake uppercase CRON daemon.
If you suspect a relay got compromised: take the relay offline, preserve disk and logs before wiping, reinstall rather than clean up, generate a new relay identity (the old keys must be treated as stolen), and rotate every credential that was on the host.
Reach out:
If you have been affected or if you have more information about this incident, please reach out to bad-relays@lists.torproject.org. This might be implied by the last sentence (but it's better to spell it out explicitly): this goes as well for the case your relay got blocked by IP address during this incident. Once you are good to go again (or you believe you are erroneously blocked) give us a note so we can make sure your IP address is removed from the block list.
Georg
participants (4)
-
Georg Koppen -
hiro -
mpan -
Toralf Förster