Threat reportSupply ChainTL-2026-4381
Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections (Ebury 1.8.3)
Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH (TL-2026-4381), also tracked as Tor exit relay SSH interception, is a high-severity supply-chain compromise, first published 2026-10-24. It has no confirmed attribution, affects Tor Project Tor exit relays (hosted on Linux VPS/servers), maps to 14 MITRE ATT&CK techniques (T1014, T1021.004, T1036.005), and is covered by 9 detection rules and 12 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 14MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 12Indicators of compromise
Key facts for TL-2026-4381
- Threat ID
- TL-2026-4381
- Also known as
- Tor exit relay SSH interception, Ebury 1.8.3 Tor exit hijacking
- Severity
- HIGH
- Status
- MONITORING
- Category
- SUPPLY_CHAIN
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- technology, telecoms, research, non-profit organisation
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 12
Malware and tooling in Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH
Malware and tooling: Ebury, Ebury 1.8.3, PlugX, Tor - S0183
How Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH works
Between Oct 1-5, 2026, attackers changed the torrc exit policy on 333-377 Tor exit relays to allow port 22 and redirect SSH traffic to 12 interception servers that captured passwords from users who accepted unfamiliar host keys. The earliest confirmed compromise was a Quetzalcoatl relay-family management server at Contabo on Aug 28, where the Ebury backdoor v1.8.3 was installed; the Tor Project flagged the relays BadExit/MiddleOnly on Oct 4 and none remained in the consensus by Oct 5.
On 2026-10-02 an independent researcher (kaba) hit a changed SSH host-key warning while connecting through Tor, scanned all ~3,000 exit relays with the exitmap tool and identified 333 exits that redirected SSH (port 22) to 12 interception servers; the Tor directory data later showed 377 relays with policy changes (342 with port 22 enabled, 24 newly converted to exits) across 59 operators. The changes were made by editing torrc exit policies. SecurityOnline reports a first phase in which relays filtered traffic to handle only unencrypted mail protocols before SSH interception began; this detail is from a single secondary source.
The interception servers presented their own SSH host key. Users who accepted a first-time key, or ignored a changed-key warning, entered their password, which was captured; the interceptor relayed the session to the real server, and the attacker then used the stolen password to log in separately, check sudo privileges and deploy a base64-encoded Perl installer for Ebury. Key-based authentication cannot be relayed because the SSH protocol signs a per-connection session identifier, so users authenticating with keys were not exposed to password capture.
The earliest confirmed compromise was the management server of the Quetzalcoatl relay family at Contabo on 2026-08-28. The attacker logged in with operator credentials from 185.225.226.62 and, within about five minutes, escalated to root and installed Ebury 1.8.3; a Switzerland2 VPS was compromised roughly 1.5 hours later with a different attacker SSH key. Root causes documented by the operator (Stefan Zimmer): one password reused for SSH login, sudo and a backup passphrase, stored in plaintext on the Contabo management host and a FranTech VPS, password authentication enabled on an internet-facing management host, and 'offline' relay master keys backed up encrypted with the same password.
Ebury 1.8.3 is delivered as a single setuid library, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 (63,368 bytes, not owned by any package), with the libkeyutils.so.1 symlink repointed to it while the packaged library is left untouched so dpkg -V and debsums checks pass. It steals credentials from SSH, sudo and PAM flows, embeds RSA and ED25519 SSH keys for independent remote access, listens on the abstract UNIX socket @event-0YsOG9WSOE, runs a fake process (/sbin/rsyslogd, systemd-udevd or arpd) inside the ssh.service cgroup, hides configuration changes from login/sudo/cron logs and survives reboot. ESET's public v1.8.2 detection did not cover 1.8.3 until Marc-Etienne M. Leveille published an updated detection script on 2026-10-21.
Scope is broader than one operator: 71 of 101 FranTech/BuyVM-hosted relays changed policy versus 13 of 9,054 elsewhere, and 40 relays from 21 operators changed within 5.5 minutes on Oct 1, indicating pre-established access. Possible explanations offered by Leveille: an Ebury-infected host giving lateral access, a compromised hosting-provider management infrastructure, or both; the initial access vector for the wider set is unconfirmed. The actor is unattributed; Ebury is historically tied to financially motivated operators (ESET: ~400,000 servers compromised 2009-2023), but no source attributes this campaign. Peak attacker capacity was 7.46% of Tor exit bandwidth on Oct 4. Tor directory authorities voted BadExit/MiddleOnly on Oct 4 (18:00-21:00 UTC); a scripted restart swept 55 Quetzalcoatl hosts on Oct 5 by an unknown actor; no hijacked relay had returned by Oct 9 and exit count remained ~370 below baseline on Oct 18.
MITRE ATT&CK techniques used in TL-2026-4381
Defense Evasion
T1014 Rootkit; T1036.005 Masquerading: Match Legitimate Resource Name or Location; T1140 Deobfuscate/Decode Files or Information
Lateral Movement
T1021.004 Remote Services: SSH
Execution
T1059 Command and Scripting Interpreter
Initial Access
T1078 Valid Accounts; T1195 Supply Chain Compromise
Persistence
T1098.004 Account Manipulation: SSH Authorized Keys
Privilege Escalation
T1548.001 Abuse Elevation Control Mechanism: Setuid and Setgid
Credential Access
T1552 Unsecured Credentials; T1556 Modify Authentication Process; T1557 Adversary-in-the-Middle
stealth
Resource Development
Affected products and versions in Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH
- Tor Project — Tor exit relays (hosted on Linux VPS/servers)
Vulnerable versions: 333-377 relays across 59 operators with modified exit policy
Fixed in: Relays flagged BadExit/MiddleOnly and removed from consensus Oct 4-5, 2026 - Linux (Debian-family x86_64 hosts) — libkeyutils.so.1 (replaced by Ebury 1.8.3 implant)
Vulnerable versions: Hosts with unpackaged libkeyutils.so.1.10.2 setuid library
Fixed in: Reinstalled OS images
Remediation for Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH
Patches
- No CVE or vendor patch: this is a credential-compromise and backdoor campaign
Immediate actions
- Relay operators: check Relay Search for unexpected Exit flags and audit torrc/exit policy for port 22 changes
- Take any suspect relay offline, preserve disk and logs for forensics before wiping
- Hunt for /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, abstract socket @event-0YsOG9WSOE and fake rsyslogd/systemd-udevd/arpd processes in the ssh.service cgroup
- Run host checks from a rescue system or offline image, or log in with a key rather than a password, to avoid password capture by the implant
- Report suspected malicious relays to bad-relays@lists.torproject.org
Workarounds
- Reinstall the OS rather than clean in place (the implant survived reboot on the operator host)
- Generate a new relay identity and treat old keys as compromised; rotate all credentials stored on the host
- After remediation, request removal of the relay IP block from the Tor Project
Longer-term hardening
- Disable SSH password authentication on management hosts and use key-based authentication
- Never reuse one password across SSH login, sudo and backup passphrases; do not store passwords in plaintext
- Keep relay master keys genuinely offline, not as backups encrypted with an attacker-obtainable password
- SSH users: verify host-key fingerprints out of band and never accept changed-host-key warnings when connecting over Tor
- Run Ebury detection (ESET/Leveille script updated 2026-10-21 for 1.8.3) across Linux fleets
Weaknesses (CWE) in Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH
Timeline of Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH
- About 1.5 hours later a Switzerland2 VPS is compromised using stolen credentials and a different attacker SSH key.
- Attacker logs into the Quetzalcoatl relay family's Contabo management server from 185.225.226.62 using operator credentials, escalates to root and installs Ebury 1.8.3 within about five minutes.
- 40 relays from 21 operators change exit policy within 5.5 minutes, indicating pre-established access; interception window runs Oct 1-5.
- Researcher kaba hits a changed host-key warning, scans ~3,000 exits with exitmap, finds 333 relays redirecting SSH to 12 interception servers and reports to the Tor Project health team that evening.
- Tor Project detects the policy changes, contacts the operator, and directory authorities vote BadExit and MiddleOnly flags from 18:00 UTC (in consensus by 21:00 UTC); attacker capacity peaks at 7.46% of exit bandwidth.
- A scripted restart sweeps 55 Quetzalcoatl hosts (actor unknown); by 17:00 UTC no affected relay remains in the consensus and authorities reject rejoining relays.
- Operator Stefan Zimmer publishes a post-mortem with root cause and host indicators.
- No hijacked relay has returned to the network.
- Exit relay count remains about 370 below the Oct 3-5 baseline.
- Marc-Etienne M. Leveille publishes an updated Ebury detection script covering 1.8.3; The Hacker News reports the incident.
Sources cited for Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH
- Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections
- kaba: Tor exit relay SSH interception analysis
- Tor exit nodes hijacked with Ebury malware (SecurityOnline)
- Hijacked Tor exit relays used to intercept SSH connections (SC Media)
- ESET Research: Ebury botnet alive & growing; 400k Linux servers compromised
- A single operator got 333 infected Tor exit nodes shut down (discussion)
Detection coverage for TL-2026-4381
As of 2026-10-24, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-4381 across Splunk SPL, Microsoft KQL and Sigma, covering 12 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.