How Attackers Hijacked 333 Tor Exit Relays and Stole SSH Credentials at Scale Using Ebury
Executive Summary
Between October 1–5, 2026, threat actors compromised over 333 Tor exit relays across 59 operators, rewriting torrc configuration files to redirect SSH traffic through 12 interception servers. At peak, the attacker-controlled relays represented 7.46% of Tor's total exit capacity. The campaign leveraged Ebury v1.8.3, a long-running OpenSSH backdoor and credential stealer active since 2009, to silently capture SSH passwords and establish persistent access. Users who accepted a spoofed host key and authenticated with a password had credentials stolen and sessions monitored in real time. The Tor Project's network health team identified and flagged all affected relays by October 5, removing them from the consensus directory.
This incident underscores the resurgence of Ebury-class supply-chain implants targeting infrastructure operators and the persistent danger of SSH password authentication on internet-facing hosts. With over 400,000 servers historically infected by Ebury and confirmed v1.8.3 variants active since at least June 2026, security teams must treat credential-based SSH access as a high-risk vector, particularly within anonymization networks and shared hosting environments.
Why This Matters Now
Ebury version 1.8.3 has been circulating since at least June 2026 and evades standard package-integrity checks (dpkg -V, debsums), meaning thousands of servers may be silently compromised today. The simultaneous hijacking of 7.46% of Tor exit capacity in under 72 hours demonstrates that credential theft at infrastructure scale can occur faster than most organizations detect it, making SSH hardening and encrypted traffic enforcement urgent priorities.
Attack Path Analysis
Attackers leveraged reused plaintext SSH passwords (likely harvested via a prior Ebury-infected host or compromised hosting provider) to gain initial access to Tor relay management servers, then escalated to root within minutes and installed the Ebury OpenSSH backdoor to persist and capture future credentials. Using the management server as a jump host, the attacker pivoted laterally to additional relay servers, rewrote Tor exit policies to enable SSH interception, and deployed 12 interception servers to perform man-in-the-middle credential theft against Tor users making SSH connections. The attacker maintained covert command and control via Ebury's backdoor and hidden processes, intercepted and logged SSH passwords in transit during a four-day window, and caused significant disruption to Tor's exit capacity by forcing the removal of over 370 relays from the network.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
The attacker authenticated to a Tor relay operator's internet-facing management server (Contabo VPS) using a reused plaintext SSH password on the first attempt on August 28. The password was stored in plaintext on the server and reused across SSH login, sudo, and backup passphrase. The origin IP 185.225.226[.]62 indicates a likely prior Ebury-compromised host was used to source the credential. A compromised hosting provider (FranTech/BuyVM) is also suspected as an access vector for the broader set of 58 other operators whose relays were affected.
MITRE ATT&CK® Techniques
Adversary-in-the-Middle
Modify Authentication Process: Pluggable Authentication Modules
Valid Accounts
Create or Modify System Process
Hijack Execution Flow: Dynamic Linker Hijacking
Masquerading: Match Legitimate Name or Location
Account Manipulation: SSH Authorized Keys
Data Manipulation: Transmitted Data Manipulation
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev. 5 – Authenticator Management: Password-Based Authentication
Control ID: IA-5(1)
CISA Zero Trust Maturity Model 2.0 – Phishing-Resistant Multi-Factor Authentication
Control ID: Identity Pillar – Authentication
NIS2 Directive (EU) 2022/2555 – Policies on Risk Analysis, Supply Chain Security, and Network Integrity
Control ID: Article 21(2)(a) and (e)
PCI DSS 4.0 – User Identification and Strong Authentication Management
Control ID: Requirement 8.2 / 8.3
DORA (EU) 2022/2554 – ICT Security Controls and Continuous Monitoring
Control ID: Article 9(4)(d) and Article 10
ISO/IEC 27001:2022 – Secure Authentication, Vulnerability Management, and Information Security for Cloud Services
Control ID: Annex A 8.5 / 8.8 / 5.23
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Tor exit relay hijacking enabling SSH credential theft via Ebury backdoor directly threatens IT infrastructure operators managing Linux servers, SSH jump hosts, and multi-cloud environments lacking zero trust segmentation and egress policy enforcement.
Computer/Network Security
Supply-chain compromise of 300+ Tor relays exposes network security practitioners to credential theft and lateral movement risks, undermining encrypted traffic integrity and requiring immediate east-west traffic controls and anomaly detection response.
Telecommunications
Interception of SSH sessions traversing hijacked Tor exit relays threatens telecom operators' management infrastructure, where password reuse and disabled key-based authentication amplify credential theft and unauthorized privileged access risks.
Financial Services
Ebury-driven credential theft targeting Linux-based servers risks unauthorized access to financial systems, violating PCI 4.0 and NIST 800-53 controls, with exfiltration exposure compounded by insufficient egress filtering and zero trust segmentation gaps.
Sources
- Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connectionshttps://thehackernews.com/2026/10/attackers-hijacked-over-300-tor-exit.htmlVerified
- Tor Project Network Health Team Notice - Bad Exit Relays October 2026https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/Verified
- Kaba - Tor SSH Interception Attack Analysis October 2026https://kaba.cx/posts/20261020_Tor/Verified
- Tor Directory Data Analysis - Attacker Exit Policy Match Reporthttps://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/Z2B6XYKJZBBQADU77MSNL6FJP7MHZHIV/Verified
- ESET - Ebury Botnet Malware Compromises 400,000 Servers (2024 Report)https://thehackernews.com/2024/05/ebury-botnet-malware-compromises-400000.htmlVerified
- Zimmer Quetzalcoatl Family Post-Mortem - Tor Relays Mailing Listhttps://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/QHRD6YOX6RZRDR7NCHNDO7GLCEA6VFM6/Verified
- ESET Ebury Detection Script (Updated for v1.8.3) - Marc-Etienne M. Leveillehttps://github.com/marc-etienne/eset-malware-research/blob/ebury_update/ebury/detect_ebury.shVerified
- CISA Known Exploited Vulnerabilities Cataloghttps://www.cisa.gov/known-exploited-vulnerabilities-catalogVerified
- Tor Metrics - Relay Exit Flag Statistics October 2026https://metrics.torproject.org/relayflags.html?start=2026-09-02&end=2026-10-19&flag=ExitVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is directly relevant to this incident because the attacker's ability to pivot freely between management servers and relay infrastructure depended entirely on unrestricted SSH reachability across hosts. Enforcing identity-aware segmentation and east-west traffic controls would likely have reduced the attacker's blast radius by constraining lateral movement paths and limiting how far a single compromised credential could propagate.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Unrestricted external SSH reachability to the management server would likely be constrained, reducing the attacker's ability to directly authenticate using harvested credentials from an arbitrary external IP without passing through an identity-aware access boundary.
Control: Zero Trust Segmentation
Mitigation: Zero Trust workload segmentation would likely constrain the privilege scope available to a session authenticated with a single reused credential, reducing the reach of any one compromised account across the management server's adjacent workload boundaries.
Control: East-West Traffic Security
Mitigation: East-west SSH reachability between the management server and individual relay nodes would likely be constrained by micro-segmentation policies, reducing the attacker's ability to use a single compromised jump host to fan out to dozens of downstream relay servers simultaneously.
Control: Multicloud Visibility & Control
Mitigation: The attacker's ability to redirect port 22 traffic to external interception servers via NAT manipulation would likely be subject to visibility and anomaly detection, and outbound connections to previously unseen attacker-controlled endpoints could be flagged or constrained through policy-enforced traffic controls.
Control: Egress Security & Policy Enforcement
Mitigation: Outbound egress paths from relay infrastructure to the 12 attacker-controlled interception servers would likely be constrained by egress policy enforcement, reducing the attacker's ability to sustain man-in-the-middle credential collection across a high-volume, multi-day exfiltration window.
Had earlier-stage controls constrained lateral movement and egress paths, the number of relay servers reaching full compromise would likely have been smaller, reducing the operational disruption to Tor's exit capacity and limiting the pool of stolen credentials available for downstream exploitation.
Impact at a Glance
Affected Business Functions
- Tor Anonymity Network Exit Relay Operations
- SSH Remote Administration and Server Authentication
- Credential and Identity Management for Linux Infrastructure
- Encrypted Network Communications (IMAPS, POP3S, Tor Circuits)
Estimated downtime: 5 days
Estimated loss: N/A
SSH login credentials (passwords) of users who connected to SSH servers over Tor between October 1 and October 5, 2026 via hijacked exit relays and accepted the interceptor host key. Exposed data categories include: plaintext SSH passwords captured by 12 interception servers, full SSH session command streams monitored and logged by the attacker, sudo privilege escalation data on victim servers, potential exposure of server private keys and relay identity keys stored on compromised hosts, plaintext email credentials where POP3 and IMAP were redirected, and backup encryption passphrases stored in cleartext on management infrastructure. The Ebury v1.8.3 backdoor on compromised hosts enables persistent credential harvesting beyond the October 1-5 window. Scale of direct victim count is unconfirmed but the attack window covered up to 7.46 percent of Tor exit capacity affecting all users routing SSH over Tor during that period.
Recommended Actions
Key Takeaways & Next Steps
- • Enforce Zero Trust Segmentation (CNSF) to isolate management servers from relay infrastructure — identity-based microsegmentation would have prevented the attacker from using the Contabo VPN/jump host to reach Switzerland2 and other relay servers without re-authentication against a policy-aware control plane, limiting lateral movement even after initial compromise.
- • Deploy Encrypted Traffic (HPE) and Egress Security controls to ensure all SSH and relay management traffic transits only over policy-enforced encrypted channels (MACsec/IPsec); FQDN-based egress filtering enforced via Cloud Firewall (ACF) would have flagged or blocked outbound connections from relay servers to the 12 unknown interception server IPs, surfacing the redirect at the network layer.
- • Implement Multicloud Visibility & Control with anomaly baselining to detect the mass simultaneous torrc configuration change across 40 hosts within 5.5 minutes — centralized traffic observability and control plane telemetry would have generated high-confidence alerts on coordinated, identical policy changes across unrelated operator namespaces.
- • Apply East-West Traffic Security controls to monitor and restrict workload-to-workload SSH flows between management servers and relay nodes; policy enforcement requiring explicit service identity for all inter-server SSH sessions would have detected the credential-based lateral movement from the management server to Switzerland2 and raised an alert on first-attempt root acquisition within five minutes.
- • Operationalize Inline IPS (Suricata) with Threat Detection & Anomaly Response to identify known Ebury behavioral signatures (setuid library injection into OpenSSH, abstract UNIX socket creation, fake syslog process in ssh.service cgroup, NAT rule modifications on port 22) and automatically isolate affected workloads, preventing the attacker from maintaining persistent backdoor access through multiple reboots and scripted restarts.
