Threat actor hijacks 10% of Tor exit nodes with Ebury malware for mass sniffing

1. Executive summary

Between October 2 and 5, 2026, an unidentified actor compromised more than 330 Tor relays, infected them with the Ebury Linux malware and converted them into exit relays used to intercept SSH connections and downgrade email sessions to capture unencrypted traffic. The intrusion ran undetected for three days until a Swiss engineer reported it to the Tor Project, which notified operators and blocklisted the affected relays, removing more than 10% of exit capacity. No CVE has been assigned and no CVSS score, EPSS estimate or CISA KEV entry exists for this activity; the risk is operational rather than patchable. For EMEA financial services the exposure is indirect but concrete: any staff, automated job or third party that routes traffic through Tor, or that relies on opportunistic TLS for email and SSH, could have had credentials or message content captured by an exit node under attacker control. Attribution is unconfirmed and the actor is described only as unidentified.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

3. Technical analysis & attack chain

The reporting is a newsletter summary. It gives the shape of the operation and the malware family but not the initial access vector, the Ebury build, command-and-control addresses or the tooling used to convert relays. Treat the chain below as confirmed at the level of what happened, not how each step was executed.

The actor gained control of more than 330 Tor relays. The method of compromise is not stated in the source.
Each relay was infected with Ebury, a Linux malware family historically associated with SSH credential theft and relay-level traffic manipulation.
The actor reconfigured the relays to operate as exit nodes, so that traffic leaving the Tor network for the open internet passed through infrastructure it controlled.
From the exit position the actor intercepted SSH connections and downgraded email connections, capturing unencrypted email traffic.
The campaign ran from October 2 to October 5 before a Swiss engineer detected it and reported it to the Tor security team.
The Tor Project notified relay operators. Operators either shut down compromised servers or the Tor Project added them to its blocklist, stopping Tor traffic from transiting them.

The technical significance for a defender is the exit-node position, not the relay compromise itself. An exit node sees the plaintext of any connection that is not end-to-end encrypted, and it can interfere with protocol negotiation. The source states the actor downgraded email connections, which points to manipulation of STARTTLS-style opportunistic upgrade rather than passive capture alone. SSH interception implies the actor could observe or manipulate the SSH handshake for sessions routed over Tor. Neither mechanism is described in more detail in the source.

Ebury is the only named tool. The source does not give the version, the persistence mechanism, the C2 infrastructure or the loader. Ebury has historically been used to steal SSH credentials and to proxy traffic, which fits the observed behaviour, but the source does not confirm which Ebury capability was used here.

The actor is described as mysterious and unidentified. No MITRE ATT&CK profile is available for it and no attribution to a state or criminal group is made in the source. Any attribution beyond "unidentified" is unconfirmed.

The source also notes a November 2023 precedent in which the Tor Project removed more than 1,000 relays set up through a for-profit cryptocurrency scheme. That is context for scale, not a link to this campaign.

4. Mitigation & containment

P1 within 24 hours

Identify any host, service account or automated job that egresses through Tor, including vendor tooling and research sandboxes. Block Tor exit traffic at the perimeter unless there is a documented business case, and log any exception.
Enforce SSH over Tor as prohibited for production access. Where administrators use Tor for privacy, require key-based authentication with no password fallback and confirm host key verification is on.
Require TLS on all email submission and retrieval (SMTPS on 465, IMAPS on 993, POP3S on 995) and disable plaintext and opportunistic-only upgrade paths on mail clients and relays. Reject STARTTLS-stripping by pinning the expected TLS state where the client supports it.
Rotate credentials for any account that authenticated to an SSH or mail service over Tor between October 2 and October 5, 2026.

P2 within 72 hours

Review mail gateway and relay logs for the October 2 to 5 window for downgrade indicators: connections that began as plaintext, STARTTLS failures followed by successful plaintext sessions, or certificate changes on internal mail hosts.
Search endpoint and server telemetry for Ebury artefacts. The source gives no hashes or paths, so hunt on behaviour: unexpected SSH daemons or listeners, new authorized_keys entries, and outbound connections from Linux hosts to unfamiliar destinations.
Confirm that no internal service relies on Tor for reachability, including third-party integrations and remote support tooling.

P3 within 7 days

Add Tor exit-node blocklisting to the egress proxy and to mail and SSH gateways, refreshed from the public Tor exit list.
Require MTA-STS and DANE where the counterparty supports them, so that inbound mail to your domain cannot be downgraded by an exit node.
Brief staff who use Tor that exit nodes are untrusted by definition and that any credential entered over Tor should be treated as exposed.

No vendor fix applies. There is no CVE and no patch. The remediation is configuration and credential hygiene.

5. Indicators of compromise

No indicators of compromise available in the source material.

The source names no hashes, domains, IP addresses, file paths or registry keys. It describes behaviour only. The behavioural indicators below are derived from the described campaign and are not atomic indicators; they are for hunting, not for blocking.

Behavioural indicators

behaviour	where to observe	confidence
Tor relay converted to exit node and used to carry SSH or mail traffic	Tor relay consensus and exit lists; egress proxy logs	medium
SSH sessions routed over Tor from internal or administrative hosts	SSH server auth logs, bastion logs, proxy logs	medium
Email connection downgraded from TLS to plaintext	Mail gateway and MTA logs, STARTTLS negotiation records	medium
Ebury infection on Linux relay or server	EDR and Linux audit telemetry, process and listener inventory	low, single-sourced and without artefacts

6. Detection

The source gives no file hashes, strings, mutexes, paths or command lines. It gives behaviour: Tor exit usage, SSH interception and email downgrade. A YARA rule cannot be written from this material without inventing strings, so none is provided. The Sigma rule below targets the observable email downgrade behaviour at the mail gateway; tune the field names to your MTA's log schema before deployment.

title: Email session downgraded from TLS to plaintext
id: 8f3c2a10-6b7e-4d21-9a55-0c1e7d4b2f88
status: experimental
author: Adverse Trace
date: 2026-10-21
description: Detects mail sessions where STARTTLS was offered or attempted but the session continued in plaintext, consistent with exit-node downgrade activity described in AT-2026-10-21-1448.
references:

  - https://news.risky.biz/risky-bulletin-hacker-hijacks-10-of-tor-exit-nodes/
logsource:
  category: mail
  product: generic
detection:
  selection_starttls:
    starttls_result:

      - failed
      - not_offered
      - stripped
  selection_plaintext:
    encryption: none
  condition: selection_starttls and selection_plaintext
falsepositives:

  - Legacy internal relays that do not support STARTTLS
  - Misconfigured clients during rollout
level: medium

For SSH, alert on any authentication to a production host where the source address resolves to a Tor exit node, and on host key mismatches for internal SSH endpoints during the October 2 to 5 window.

7. Sources

Risky Business, "Risky Bulletin: Hacker hijacks 10% of Tor exit nodes", https://news.risky.biz/risky-bulletin-hacker-hijacks-10-of-tor-exit-nodes/, published 2026-10-21.

This is a single source. The relay count, the three-day dwell time, the Ebury identification and the SSH and email interception claims all rest on this one newsletter summary and have not been corroborated against a Tor Project statement or a vendor technical report in the material available. Verify before acting on the specific figures.

8. Adverse Trace position

Adverse Trace assesses this as a medium-impact exposure for most EMEA financial services clients and a high-impact one for any client whose staff, automation or third parties route traffic through Tor or rely on opportunistic TLS for email and SSH. There is no CVE, no CVSS score, no EPSS estimate and no CISA KEV entry, so severity here is driven by exposure path rather than a patchable flaw, and we are not assigning a numeric score the data does not support. The attribution is unconfirmed: the source names no actor and no MITRE ATT&CK profile exists for one, so we treat the campaign as unattributed. The single-source nature of the reporting is a confidence caveat on every specific figure. We will monitor for a Tor Project statement or a technical report on the Ebury build used, and we will update this advisory if either appears. Clients who confirm Tor egress or plaintext mail paths should treat credentials used between October 2 and October 5, 2026 as exposed and rotate them now.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.