Ebury on 333 Tor exit relays: SSH passwords intercepted

In early October 2026 a substantial share of the Tor network’s exit relays was used for a man-in-the-middle attack against SSH connections. The story is reported by The Hacker News, Ars Technica and Insicurezza Digitale; according to the latter two, 333 relays were involved, compromised with Ebury, the Linux backdoor documented since 2014. The details below come from Ars Technica and Insicurezza Digitale, which draw on the report published on 20 October by a Tor volunteer who goes by Kaba and on information from the Tor Project.

What happened

According to Ars Technica, the intrusion began in late August: the attacker logged into a relay operator’s management server with a valid, reused password. Insicurezza Digitale dates the access to 28 August 2026 and adds that the same password was used for SSH, for sudo and as the backup passphrase, and was stored in plain text on two machines; root privileges followed within five minutes.

From there the attacker connected over SSH to a second server, “Switzerland2”, with an RSA key that does not appear among the authorised keys, and installed Ebury on it. How the attacker came to control all 333 relays has not been established: both outlets mention the unconfirmed hypothesis of access at hosting provider level.

How the interception worked

The compromised relays were modified in the torrc configuration file:

• SSH: connections to port 22 were redirected to one of 12 interception servers, each with its own host key. Users who ignored the client’s “REMOTE HOST IDENTIFICATION HAS CHANGED” warning typed their password into the attacker’s server, which then forwarded the session to the legitimate server. According to Insicurezza Digitale, some middle relays were also turned into exit relays with port 22 open.
• Email: ports for encrypted mail were blocked while plain-text ones stayed open. Ars Technica lists ports 25, 465, 587, 993 and 995; Insicurezza Digitale cites 465, 587, 993 and 995. It is not known whether any downgrade succeeded.

Using a honeypot, Kaba observed what happened after a password was captured: a first connection to the victim’s server to watch the commands being typed, then a second one to install Ebury. Insicurezza Digitale reports the commands seen (id -u, command -v sudo, sudo -n true), followed by a Perl installer with a base64 payload delivered through the Python paramiko library. Every stolen password thus became a newly infected server.

Public key authentication is not exposed to this scheme: the signature is bound to the individual session and cannot be relayed.

Timeline and the Tor Project’s response

Kaba received the host key warning on 2 October and then tested the roughly 3,000 exit relays one by one, checking the SSH fingerprint returned by a test server. The sources differ slightly on the attack window: Ars Technica gives 2 to 5 October, Insicurezza Digitale 1 October onwards, when 40 relays run by 21 operators changed policy within five and a half minutes.

According to Insicurezza Digitale, on 4 October the Tor Project contacted the operators and assigned the BadExit and MiddleOnly flags to the affected relays; peak compromised exit capacity, by consensus weight, was 7.46%. On 5 October the last relay with the attacker’s policy dropped out of the consensus.

Ebury: what to look for on Linux servers

Insicurezza Digitale reports that the version found is 1.8.3, newer than the one covered by ESET’s public indicators (1.8.2). Ebury poses as the libkeyutils.so system library, does not modify the sshd and sudo binaries, passes dpkg -V and debsums checks, leaves no trace in standard access logs and survives reboots.

Indicators published by Insicurezza Digitale:

• the file /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, which belongs to no package (different hash on each host), pointed to by the libkeyutils.so.1 link;
• the abstract UNIX socket @event-0YsOG9WSOE;
• fake rsyslogd, systemd-udevd and arpd processes, and a hidden snf process;
• SSH keys of the attacker’s infrastructure: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E (the same one shown in the warning reported by Ars Technica), ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y, RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo;
• the address of the initial access on 28 August: 185.225.226.62.

Indicative MITRE ATT&CK mapping, derived from the reported facts: T1078 (Valid Accounts), T1021.004 (Remote Services: SSH), T1557 (Adversary-in-the-Middle), T1014 (Rootkit), T1036 (Masquerading).

Impact for European and Italian companies

The direct risk concerns anyone who administered servers with SSH passwords over Tor in the first days of October, including consultants and suppliers: the intercepted password led to a backdoor on the server reached. The root cause, a password reused across SSH, sudo and backups, applies to any Linux estate. For NIS2 entities, authentication, cyber hygiene and supplier security fall under the Article 21 measures. And mailboxes that still accept plain-text IMAP and POP3 expose credentials on any untrusted network, not only on Tor.

What to do now

1. Ask who uses Tor to reach company servers. If anyone accepted an unknown host key between 1 and 5 October, treat the password as compromised, change it wherever it was reused and check the server reached.
2. Disable SSH password login (PasswordAuthentication no) and use keys or certificates. Do not reuse the same password for SSH, sudo and backups.
3. Never ignore a changed host key warning: StrictHostKeyChecking yes with centrally managed known_hosts, or host certificates.
4. Look for the indicators: check with dpkg -S or rpm -qf which package libkeyutils belongs to and look for the abstract socket with ss -xa. Insicurezza Digitale suggests opening the shell with H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash to bypass the rootkit; where possible, analyse the disk with the machine powered off.
5. Compromised host: the Tor Project advises operators to take it offline, preserve disk and logs, reinstall from scratch and rotate all credentials on it.
6. Email: reject plain-text IMAP and POP3 and accept authentication only over TLS.

How ARXDOME helps

ARX Expose shows the open ports and mail configuration visible from outside. On Linux servers the ARX Sentry agent collects the inventory of processes and ports and checks file integrity in the chosen folders, while ARX Shield verifies hardening against the CIS benchmarks. ARX Horizon enriches every connection with country, network operator and threat lists, so an SSH login from an unusual address stands out immediately.

Last updated: 22 October 2026