Threat feed

Ebury Tor exits

Ebury operators hijacked 333 Tor exit relays into SSH password-interception traps

Posted · Updated · Spectrum Delta Research Team

Summary

An independent Tor relay operator publishing as kaba (primary, Oct 20, in-window) documents a coordinated interception campaign that ran Oct 1-5, 2026: attackers who had held Ebury 1.8.3 - an OpenSSH backdoor and credential stealer for Linux - on relay host servers since August switched it on at 09:35 on Oct 2, making 333 of Tor's roughly 3,000 exit relays (~10%) redirect port-22 SSH connections to 12 interception servers. About a dozen relays presented substituted host keys, triggering the client's host-key-changed warning; users who clicked past it and typed a password handed the credential to the interceptor, which kept the session alive by relaying to the real server while watching every command, and opened a further connection attempting to plant Ebury on the destination server via a base64-encoded Perl payload preceded by a sudo-permission probe. Exit policies were also manipulated so the relays carried unencrypted mail traffic. Tor's network health team flagged the relays BadExit from Oct 4; by Oct 5 17:00 UTC none remained in the consensus. ESET's Ebury research (400,000 servers compromised 2009-2023) treats the operators as a financially motivated crime group, and ESET's Léveillé - quoted in the primary - assesses more compromised relays likely remain.

Breakdown

Adversary

Unattributed

Procedures (3)

  1. Compromised relay hosts rewrite torrc exit policy

    Impair Defenses: Ebury-infected relay hosts rewrite torrc to redirect SSH and carry plaintext mail

    • T1562.001

    Logs

    • Relay-host Linux telemetry · torrc rewrite; systemd config reload; setuid libkeyutils file; Ebury socket
    • Network flow / Tor consensus · port-22 redirect to 12 interceptors; BadExit; policy switch

    Detectors

    No known detector

Click to expand remaining (2) procedures

  1. Exit relays redirect SSH to interception servers

    Adversary-in-the-Middle: 12 interception servers capture SSH passwords and relay live sessions

    • T1557Adversary-in-the-Middle

    Logs

    • Network flow / Tor consensus · port-22 redirect to 12 interceptors; BadExit; policy switch
    • OpenSSH auth and session logs · logins from interception IPs; parallel sessions; no-auth logins

    Detectors

    No known detector

  2. Interceptors harvest passwords, push Ebury via Perl

    Command and Scripting Interpreter: base64-encoded Perl payload probes sudo then installs Ebury

    • T1059.004Command and Scripting Interpreter: Unix Shell

    Logs

    • OpenSSH auth and session logs · logins from interception IPs; parallel sessions; no-auth logins
    • Relay-host Linux telemetry · torrc rewrite; systemd config reload; setuid libkeyutils file; Ebury socket

    Detectors

    • ESET detect_ebury.sh - Ebury 1.8.3 socket event-0YsOG9WSOE · abstract UNIX socket found on Linux host (manual hunt script)

Indicators of compromise

Hunt only

Interceptor ED25519 host key SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, presented to SSH clients that exited through infected relays (quoted in the primary). Ebury 1.8.3 abstract UNIX socket event-0YsOG9WSOE (covered by the updated ESET script). Ebury install one-liner shape: environment probe emitting U=$(id -u) and a sudo -n nopass/maybe/none check, then sudo bash -c 'echo <base64> | base64 -d | perl' (primary). Setuid /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 with the libkeyutils.so.1 symlink redirected, and a fake rsyslogd process in the ssh.service cgroup - from the relay operator post-mortem as reported secondarily, not fetched from its primary this run; treat as leads, not verified IOCs.

Detailed

From the primary: interceptor ED25519 host key SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E (presented via infected exits); Ebury install command shape U=$(id -u) + sudo -n probe + sudo bash -c 'echo <base64> | base64 -d | perl'; Ebury 1.8.3 payload; 333 redirecting exits of ~3,000; 12 interception servers (addresses not in the fetched excerpt). From ESET's script (fetched): Ebury 1.8.3 abstract UNIX socket event-0YsOG9WSOE (1.8.2.e7 maps to event-te6Enx7MQS). Secondarily reported, not verified from their primaries this run (treat as leads): setuid /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 with libkeyutils.so.1 symlink redirect; fake rsyslogd in ssh.service cgroup; attacker source IP 185.225.226[.]62 and implant-embedded RSA/ED25519 key fingerprints from the operator post-mortem.

Sources

Grades are source reliability (A–F) and information credibility (1–6).

Questions, detections or sightings of Ebury Tor exits? Bring them to the community.

Discuss in the Tradecraft Slack