[tor-relays] Re: Ebury 1.8.3 on two Quetzalcoatl relay servers: timeline, lessons, open questions

[Tor at 1AEO via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx>]

More details on the attack that recently changed Tor relay exit policies

Everything below uses only public, network-wide CollecTor relay data (hourly consensuses, directory-authority votes, server descriptors), public IP-to-AS maps, and exact matching of exit-policy port lists, incl. rule order, this is the timeline for this thread and hiro's 10-05 thread "Security incident affecting some relay operators". Courtesy of Opus 5.5 and a lot of critique.

Thread questions

- hiro (non-exits made exits): 24 affected relays were non-exits before (0 Quetzalcoatl); all 24 got the Exit flag. Of the other 353, 342 already had an exit policy and 11 were new keys.

- Toralf (does it boil down to the cleartext sudo password?): Unlikely for the whole incident: A or B also appeared on 100 relays of 58 other operators.

- mpan, in hiro's thread (one shared vulnerability, or node by node?): Likely coordinated: A reached 40 relays of 21 operators in 5 min 24 s, 38 by reload (item 4), so one actor already had access to all 40. Whether that access came from one shared hole or from earlier break-ins is not in the data; the FranTech rates (Who was affected) are the strongest hint of a shared factor.

- M-E: How to get the exfil server address? Ebury uses a lot of encryption for obfuscation... Amazing response too!

Summary

- From 10-01 14:49 to 10-04 22:21, 377 relays of 59 operators (277 Quetzalcoatl, 100 of 58 other operators) switched to one of two exit policies, A or B below, that no relay had used in any consensus or server descriptor since 2025-01-01; of other operators' relays listed at 10-01 14:00, 71 of 101 on FranTech became affected vs 13 of 9,054 elsewhere.

- Of the 366 affected relays with an earlier policy, the switch opened 22 SSH (encrypted) on 342 and 23 Telnet (clear) on 335 and closed 993 IMAPS and 995 POP3S (encrypted) on 334; B, used by 350 relays incl. all of Quetzalcoatl, keeps 110 POP3 and 143 IMAP (clear, TLS optional) open, a mix that only 3 of 2,767 unaffected relays with an exit policy had at 10-01 14:00.

- No relay with A or B has been in the consensus since 10-05 17:00, so no Tor client can use them now. At 10-09 01:00, 41 relays (9 Quetzalcoatl) still publish A or B but are not in the consensus, as only 2-3 of the 9 authorities include them in their votes (5 needed); they are listed at the end so their operators can check them.

3 sections:

Terms

What Changed

Timeline

Terms

- Policy A, in short: blocks all mail ports (sending and reading, clear and encrypted), Windows file sharing and Remote Desktop; allows everything else, incl. SSH, Telnet, FTP and HTTP.

  The exit-policy summary (consensus "p" line):

    reject 25,110,135,137-139,143,445,465,587,993,995,3389

  Every relay with A lists the rules in this order: 25,465,587,110,143,993,995,3389,135,137-139,445.

  Ports A rejects (clear = readable by the exit; TLS optional = clear unless the application upgrades to TLS):

    25 SMTP (clear, TLS optional), 110 POP3 (clear, TLS optional),

    143 IMAP (clear, TLS optional), 465 SMTPS (encrypted),

    587 mail submission (clear, TLS optional), 993 IMAPS (encrypted),

    995 POP3S (encrypted), 135 Windows RPC (clear),

    137-139 Windows NetBIOS (clear), 3389 Remote Desktop (encrypted),

    445 Windows SMB file sharing (clear, encryption optional)

- Policy B, in short: tor's default exit policy (blocks mail relay, Windows file sharing, Usenet news, P2P file sharing) plus blocks mail submission (465, 587) and encrypted mail reading (993 IMAPS, 995 POP3S), but leaves 110 POP3 and 143 IMAP (clear, TLS optional) open; allows everything else, incl. SSH, Telnet, Remote Desktop.

  The exit-policy summary (consensus "p" line):

    reject 25,119,135-139,445,465,563,587,993,995,1214,4661-4666,6346-6429,6699,6881-6999

  i.e. tor's default plus reject 465,587,993,995. Every relay with B lists the rules in this order: 25,465,587,993,995,119,135-139,445,563,1214,4661-4666,6346-6429,6699,6881-6999.

  Ports B rejects:

    25 SMTP (clear, TLS optional), 465 SMTPS (encrypted),

    587 mail submission (clear, TLS optional), 993 IMAPS (encrypted),

    995 POP3S (encrypted), 119 NNTP news (clear), 563 NNTPS (encrypted),

    135 Windows RPC (clear), 137-139 Windows NetBIOS (clear),

    445 Windows SMB file sharing (clear, encryption optional),

    136 (no common use; in tor's default 135-139 range),

    1214 Kazaa (clear), 4661-4666 eDonkey (clear, obfuscation optional),

    6346-6429 Gnutella (clear), 6699 WinMX (clear),

    6881-6999 BitTorrent (clear, obfuscation optional)

- A vs B: both reject 25,135,137-139,445,465,587,993,995, and both rule orders start 25,465,587. Only A rejects 110,143,3389. Only B rejects 119,136,563,1214,4661-4666,6346-6429,6699,6881-6999. Both allow every other port, e.g. 21 FTP (clear), 22 SSH (encrypted), 23 Telnet (clear), 53 DNS (clear), 80 HTTP (clear), 443 HTTPS (encrypted).

- Affected relay: published >=1 server descriptor whose IPv4 summary is exactly A or B. A policy match, not proof of compromise.

- Quetzalcoatl: relays in that family's MyFamily line (362 fingerprints) or with its ContactInfo.

- Other operators: all operators except Quetzalcoatl, incl. TorDola.

- TorDola: relays TorDola and TorDola1-4 of one operator on AS211720 (Datashield). TorDola4 is new on 10-04.

- New key: a relay fingerprint seen for the first time.

- Operator: one ContactInfo string; each of the 7 relays without one counts as its own operator. A proxy: one person may use several.

- Host: one IPv4 address; physical machines are not visible.

- FranTech: AS53667 (FranTech Solutions, BuyVM).

- Reload: new policy, same tor start time (published minus uptime), i.e. config re-read. Restart: new tor start time.

- Listed: in the hourly consensus. Needs at least 5 of the 9 directory authorities to include the relay in their votes, and at least 5 to vote it Running (they can reach it).

- Flagged: BadExit or MiddleOnly in the consensus. A flag needs votes from more than half of the authorities that use it (BadExit 3 of 5, MiddleOnly 5 of 9). Leaving a relay out of a vote = no flag vote. BadExit: clients do not use it as an exit. MiddleOnly: clients use it only as a middle relay.

- Usable exit: listed with Exit and without BadExit.

- Dates MM-DD 2026, times UTC, a..b = a to b. hh:mm:ss = descriptor published (tor start time in items 5, 13); hh:00 = consensus/vote.

What the switch changed (each relay's A or B vs its own policy just before 10-01, all ports; "opened" = clients can now exit there to it)

- All 366 affected relays with an earlier policy: opened 22 SSH (encrypted) on 342, 23 Telnet (clear) on 335, 6667 IRC (clear) on 317, 3389 Remote Desktop (encrypted) on 311, 110 POP3 (clear, TLS optional) and 143 IMAP (clear, TLS optional) on 309; closed 993 IMAPS (encrypted) and 995 POP3S (encrypted) on 334, 563 NNTPS (encrypted) on 292. For comparison, at 10-01 14:00, of 2,767 unaffected relays with an exit policy, 1,120 allowed 22 and 1,665 allowed 993 and 995.

- Quetzalcoatl, 277 relays: each allowed the same 79 ports before; B opened 65,235 more, incl. 22 SSH (encrypted), 23 Telnet (clear), 110 POP3 (clear, TLS optional), 143 IMAP (clear, TLS optional), 3389 Remote Desktop (encrypted), 6667 IRC (clear), 6697 IRC (encrypted); closed only 563 NNTPS (encrypted), 993 IMAPS (encrypted), 995 POP3S (encrypted). For mail reading: 110 (clear, TLS optional) and 143 (clear, TLS optional) opened; 993 (encrypted) and 995 (encrypted) closed.

- Other operators, 44 exits to A: opened 22 SSH (encrypted) on 26, 23 Telnet (clear) on 24, 6667 IRC (clear) on 10; closed 110 POP3 (clear, TLS optional) and 143 IMAP (clear, TLS optional) on 36, 993 IMAPS (encrypted) and 995 POP3S (encrypted) on 37, 3389 Remote Desktop (encrypted) on 23.

- Other operators, 21 exits to B: opened 22 SSH (encrypted) on 15, 23 Telnet (clear) on 10, 3389 Remote Desktop (encrypted) on 10, 110 POP3 (clear, TLS optional) and 143 IMAP (clear, TLS optional) on 8, 6667 IRC (clear) on 6; closed 993 IMAPS (encrypted) and 995 POP3S (encrypted) on 20, 563 NNTPS (encrypted) on 15. 24 non-exits to B: opened every port B allows (65,311).

- B's mail mix was on 3 of those 2,767 relays at 10-01 14:00: open 110 (clear, TLS optional) and 143 (clear, TLS optional); closed 465 (encrypted), 587 (clear, TLS optional), 993 (encrypted) and 995 (encrypted). A's (all mail ports closed) was on 1,085.

- A tor client only uses exits that allow the destination port, so closing 993 IMAPS (encrypted) does not push a user to 143 IMAP (clear, TLS optional); it means these relays carry no IMAPS or POP3S, while they now carry 22 SSH (encrypted), 23 Telnet (clear) and, under B, 110 POP3 and 143 IMAP (clear, TLS optional).

- Inference: opening 22 (encrypted) fits hiro's report of SSH interception. Why 993 and 995 (encrypted) were closed is not visible in the data.

Timeline

1. 2025-01-01..2026-09-26 06:00: no relay used A or B.

   Same period for both sources: no A or B p line in 14,426 hourly consensuses (avg 9,221 relays; 5.1% of hours missing in CollecTor), and no A or B in 11.0 M server descriptors. Before TorDola, A's first 7 rules in A's order appear twice, both times followed by other rules (not A): 1 relay (NeonCitadel01) 2025-10-08..2025-10-21, then 6881-6999,51413,8999; 18 relays on 9 IPs (Cypher, Tank, Satoshi, 6 more nicknames) 2026-03-30 11:36:35..2026-03-31 23:34:06, then 22-23,135-139,445,161-162,5900-5901,3389 and 13 more rejects. Rejecting exactly those 7 ports, in another order: 4 relays in 2025 (2025-01-09..2025-01-26 and 2025-09-01..2025-09-02), TorDola once (2026-09-01 23:56:10), DrauseRelay (2026-09-22..2026-09-24).

2. 09-26 06:10:06..10-01 14:44: TorDola uses A's first 7 rules.

   2 TorDola relays from 09-26, all 4 by 09-30: reject 25,465,587,110,143,993,995 in A's order, then accept *:*. 10 new keys on 09-28 reject the same 7 ports in sorted order. No A or B yet.

3. 10-01 14:44:20..14:50:03: the 4 TorDola relays reach A in 2 reloads.

   +3389 at 14:44:20..14:44:31; +135,137-139,445 at 14:49:51..14:50:03. First with A: TorDola1 4F72DEF09B015E9B6F210597083D95D8A3BC38AD.

4. 10-01 15:33:55..15:39:19: A reaches 40 relays of 21 more operators.

   28 hosts; 39 on FranTech. 38 reloads, 1 restart, 1 unknown (no descriptor between its 12:56:18 tor start and A).

5. 10-01 15:36:30..15:47:53: Quetzalcoatl relays restart, policy kept.

   275 relays on 72 of its 73 hosts; 274 then publish their old policy, 919EBE30 publishes nothing until B (item 6).

6. 10-02 09:27:42..09:35:18: all 277 listed Quetzalcoatl relays get B.

   73 hosts; 273 by reload. The other 4 published nothing between a 10-01 restart and B, so reload or restart is unknown. First with B: F532DA2085F87777CE05EA947BF7B4F49B625754.

7. 10-02 09:29:25..18:53:05: 38 other-operator relays get B, 9 drop A.

   09:29:25..09:44:12, 39 FranTech relays: 30 to B (15 from A); 9 leave A without B (8 back to their exact pre-10-01 policy text). 10:15:20..18:53:05: 8 more to B (5 FranTech; 5 non-exits before).

8. 10-03 10:26:02..16:18:40: 19 non-exit relays restart with B.

   Also 1 exit reloads to B; 9 new keys, each reusing an affected relay's nickname and IP:ORPort, start with B. 5 ASes, 0 Quetzalcoatl.

9. 10-04 01:00: usable exits with A or B peak in consensus weight.

   351 relays, with 7.46% of the consensus weight of all usable exits (by count the peak is 352 relays at 04:00, 7.43%).

10. 10-04 15:00..10-05 02:00: Quetzalcoatl relays go unreachable.

    Listed: 277 at 14:00, 8 at 21:00, 0 at 10-05 02:00. At 21:00, 182 were still in all 9 votes, but no authority voted them Running. 269 left before any of them was flagged; the 8 still listed at 21:00 were flagged. No Quetzalcoatl descriptor 22:35:57..10-05 08:56:37.

11. 10-04 18:00..10-05 08:00: 6 of 9 authorities start voting flags.

    First BadExit/MiddleOnly vote on an affected relay other than 9CDB4020 (item 15, flagged since 08-17): gabelmoo and dannenberg 18:00, moria1 19:00, bastet 20:00, longclaw 21:00, maatuska 10-05 08:00; dizum, faravahar, tor26: none as of 10-09 01:00. These flags reach the consensus at 21:00. 14 relays with A or B (none Quetzalcoatl; 5 TorDola) were usable exits 10-04 21:00..10-05 15:00 (11 throughout, 3 for part) and have no BadExit or MiddleOnly vote from any authority as of 10-09 01:00.

12. 10-04 22:23:39..22:47:33: 22 other-operator relays leave B.

    Each restarts with its exact pre-B policy text (13 pre-10-01, 9 A). 1 new key starts with A (22:21:18).

13. 10-05 08:56:30..10:39:50: Quetzalcoatl relays restart in one sweep.

    253 relays on 70 hosts (Zimmer's post: 55), policy still B.

14. 10-05 10:00..14:00: Quetzalcoatl relays are listed again, lose their flags, then drop out.

    None has the Exit flag. Quetzalcoatl relays listed / of them flagged: 10:00 82 / 81; 11:00 218 / 167; 12:00 208 / 0; 13:00 111 / 0; 14:00 0 listed. At 12:00 longclaw and maatuska leave every affected relay except 9CDB4020 out of their votes. For 157 relays, MiddleOnly falls from 6 to 4 of 9 votes and BadExit from 3 to 2 of 5: no flag. The other 51 were in only 5 votes at 11:00 and 12:00 (MiddleOnly 2, BadExit 1), so not flagged then, nor in any consensus as of 10-09 01:00. All 208 still meet the listing bar. 40 other-operator relays lose their flags at 12:00 the same way.

15. 10-05 17:00..10-09 01:00: no relay with A or B is listed.

    One affected relay is listed: TimberDolphin63 9CDB4020E69D9E7201C3D1A8BF9DE1DEBF997A76. It has carried BadExit since 08-17 17:00 and MiddleOnly since 08-17 19:00, so it gets no exit traffic. It had B 10-02 10:15:20..10-04 22:43:13 and is back on its pre-10-01 policy.

16. 10-09 01:00 (latest consensus): only 9CDB4020 (item 15) of the 377 is listed, so no Tor client can use the other 376.

    From descriptors published 10-08 01:00..10-09 01:00 (CollecTor files and the r lines of the votes) and the 01:00 votes:

    - 316 (268 Quetzalcoatl): newest descriptor 10-03 10:26:02..10-07 15:56:50; in none of the 01:00 votes. Offline, or every authority rejects their uploads; public data cannot tell which.

    - 60 published but are not listed: each is in only 1-3 of the 9 votes (dizum, tor26, dannenberg); the other 6 authorities leave it out, and 5 are needed. Of the 60:

      - 49 (0 Quetzalcoatl, 34 FranTech) get 1-3 Running votes: 30 with A or B (9 A, 21 B); 19 with another policy: 11 their exact pre-10-01 policy text; 8 an accept-list: TorDola and TorDola1-3 (pre-10-01: A's first 7 rules only), TorDola4 (new 10-04), dead and drear (pre-10-01 list minus IRC ports), relayon9186 (pre-10-01 list minus 465,587, plus reject 993,995).

      - 11 (9 Quetzalcoatl, 2 FranTech) published B but get no Running vote. Last Running votes: 12:00 for 8 Quetzalcoatl relays on 192.210.214.13 (tor start 11:20:44..11:21:16); 05:00 for Quetzalcoatl 07DCECDF04BE5D470C615C8E1CCF086F74FC8CA6 (107.175.218.6, tor start 04:35:42); 04:00 for 2mpe4; 15:00 for NgePTimE.

    - The 41 that publish A or B are listed at the end.

    Onionoo (10-09 01:00) has 375 of the 376 unlisted relays, all running=false, because it takes running/last_seen from the consensus: e.g. 07DCECDF last_seen 10-05 12:00 ("down 3 days") but last_restarted 10-08 04:35:42. relayon9186 (last listed 09-30 21:00) has aged out of Onionoo. For the 375, Onionoo's last_restarted matches the tor start in the newest CollecTor descriptor.

Who was affected

- 377 relays on 147 hosts, 15 ASes, 59 operators. Quetzalcoatl: 277 relays, 73 hosts. 58 other operators: 100 relays, 74 hosts.

- On FranTech: 129/377 relays (34.2%), 82/147 hosts (55.8%), 47/59 operators (79.7%). Excluding Quetzalcoatl (all 58 other operators): 81/100 relays, 58/74 hosts, 46/58 operators (79.3%). Each of the 58 has its affected relays all on FranTech (46) or all off it (12).

- 10-01 14:00 (last consensus before A), other operators' relays that later became affected: FranTech 71/101 (70.3%), all other ASes 13/9,054 (0.14%). By operator, of the 3,663 other operators listed then: with a FranTech relay 44/59 (74.6%), without 10/3,604 (0.28%).

- 12 of the 46 FranTech operators also had 50 relays listed on other ASes at 10-01 14:00: none of the 50 became affected. The other 12 operators (19 affected relays, 8 ASes) had no FranTech relay 05-01..10-07.

- Quetzalcoatl: all 273 of its relays listed at 10-01 14:00 became affected: 48 on FranTech, 225 on its 6 other ASes (HostPapa, netcup, MAXKO, 3 Contabo ASes). Other operators' relays listed then on those 6 ASes: 0/452 became affected.

- 230/377 were flagged in >=1 consensus (incl. 9CDB4020, item 15). 57 got no BadExit or MiddleOnly vote from any authority 10-01 00:00..10-09 01:00: 14 Quetzalcoatl, 43 others (incl. all 5 TorDola). 36 published only B (incl. the 14 Quetzalcoatl), 13 only A, 8 both. 56 were usable exits with A or B in >=1 consensus. At 10-09 01:00, 37 have no descriptor in the last 24 h (incl. the 14 Quetzalcoatl); 20 published 10-08 03:24:13..10-09 00:42:41 (13 A or B, 7 another policy), each in only 1-3 of 9 votes, so not listed.

Data and method

- CollecTor archive and recent/: consensuses 2025-01-01..2026-10-09 01:00 (775 of 15,506 hours, 5.0%, missing, incl. 2026-04-02 16:00..04-21 01:00); server descriptors 2025-01-01..2026-10-09 00:43 (file time); votes 10-01 00:00..10-09 01:00 (10-01 19:00 missing; no dizum vote 10-01 09:00 and 10-05 18:00..20:00).

- p lines: our re-implementation of tor's policy_summarize() gives the consensus p line for all 203,044 descriptors we have of the 203,479 the 09-24..10-07 02:00 consensuses point to, and for all 9,091 of the 9,096 entries at 10-08 06:00 whose descriptor we have.

- AS: CAIDA pfx2as 20261001-1200 and as-org 20261001; IPFire location 2026-10-01 gives the same AS for all 147 affected IPs.

- Onionoo details of 10-09 01:00, as a cross-check only.

- Scripts and CSVs: https://github.com/1aeo/TorExitPolicyManipulation/tree/main/collector-exit-policy-analysis

Relays still publishing A or B exit policy at 10-09 01:00

Not in the consensus, so not used by Tor clients; listed for their operators. nickname | fingerprint | ContactInfo (long ContactInfo shortened to its email and url fields), grouped by ContactInfo.

Reachable (>= 1 authority votes it Running): 30 relays, 23 contacts

devvulLU | E207721091F48D6A02A2F8F0BFF438A714279B81 | < asara AT devvul DOT com >

devvulLV | 95AA4899FA8F312323C2628B2AFD45EF7D6005C7 | < asara AT devvul DOT com >

devvulMI | 3A78F9C8C874866F430D31188F7C98322AF2E9AC | < asara AT devvul DOT com >

devvulNY | 2325905203E9CFB5206D6811315EB5ED57AF97BD | < asara AT devvul DOT com >

andr788k | 4954B51AF0CBADA08E4BC389DF1E3E419535165A | andr788k(at)airmail(dot)cc [tor-relay.co]

luxvptorex | 0A11C7546A1332412D1EBD13BD4C3D6A6644D7E0 | dhnet.torcontact@xxxxxxxxx

sk4d9f2m8x1q7w3j | FDBEAC98530F2A4CF7FDF164695A93F6AC15BA18 | diskstats@mailboxly.example

azadisrvs2 | 91D9FFB5030F645818505EF983AF8AA4EE2D00A7 | diyarciftciatprotonmaildotcom

2mpe4b | 0D8826A5646B352A7EB843FFBE80326F4D018F1B | DoNotDisturb AT NoContact NoWarnings

2mpe4c | BC7A5E911554477F7346FA9B680250D1D84B14AF | DoNotDisturb AT NoContact NoWarnings

Alberta | 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C | email:denny.obreham[]a-n-o-n-y-m-e.net url:https://a-n-o-n-y-m-e.net

4714 | FA9F92CB28E2285A589643DDA31448361076D0C7 | email:tor [] middelstaedt dot com url:https://middelstaedt.com

4715 | FEDA854291A94B8CA5BB6920AE100346EBC4E522 | email:tor [] middelstaedt dot com url:https://middelstaedt.com

dn3a | 144C5DBEBD925D54A246A10832CBB293EE84C834 | gleepdorf AT proton DOT me

TorDotTeitelNet | 76959901386E8C908F50235D9894007886B67C2E | Jeff Teitel email:jeff[]teitel.net url:teitel.net

TorExitForYou | 1322EE47D35541471D3A00F30FFF2EE7585E5B52 | mailforhkvps@xxxxxxxxxxxxx

mbserver | 982FF2DAC80C1454E826B43F8FF003CF2CDC1CD7 | mb-server <tor AT mb-server dot com>

txn1copeland | 3D01CE600B2DC5C719684800E8C6990FE4CB8F9A | Ralph Copeland <copelandhosting AT pissmail dot com>

JustExiting | 2B4D5AA9997D4DDFF02BC52E173CF0C8FFFD1B9C | Random Person <thud_erasure020@xxxxxxxxxxxxxxx>

sh97US104R | 7E2FF265BE20E154CED120D46E39058F6CCC34D7 | stealthprivacy.eu

DingBerry | 0AE156113CAF79C28EDF599F55FABDE03D5416DC | t(at)randomperson(dot)com

Dumbledore | 7ED6B42716B1D393E7BAC2FFDDE3853CD9896A95 | t(at)randomperson(dot)com

thb8b35d95b69765 | AE6507A440E9353C19C39B5448A13EB60A77B525 | thermalmon@outlook.example

stubbornoxen | 7B67A3AD2395536FD15CB97588A0BC1A015AC267 | tor(at)thewellinspired(dot)com [tor-relay.co]

Triangulum1 | 7417085A0CC99550CF82ADD3F7B1CD01E64AAADE | tor-relay-admin@xxxxxxxxxxxxxx

privatebrowsingorg | 2858C4BF05D57D7FEBEE28DEA82BAC374222F858 | tor@xxxxxxxxxxxxxxxxxx

sullyhelpstor | 3B49A31F1DD5D929133AF10B0B33BB7AE42B53E7 | tor@xxxxxxxxxx

sullyhelpstor | E0999C5F42D12204AA8038653DBACDCE1F40E7FF | tor@xxxxxxxxxx

CarabineroDeChile | 58698C5E518D428DCA4D9780AD8379BB63B57B42 | torrelayoperator@xxxxxxxxxxxx

RunningOnFumes1 | 93D3B5088A6813F679A426323AE0125FB4FE7728 | (no contact line)

Not reachable (no authority votes it Running): 11 relays, 3 contacts

2mpe4 | 5957F8B3503BB566D36F8B9A20280FD990E4C298 | DoNotDisturb AT NoContact NoWarnings

NgePTimE | DB451037C23AF3D028AE1B7E2F82BE5CA77B98A5 | email:a78i2efsewr0neeknk[]proton.me url:allium.observer

Quetzalcoatl | 07DCECDF04BE5D470C615C8E1CCF086F74FC8CA6 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | 09768BD9ACA211008713BA481E0B8EE3239A9F0B | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | 552C2E2AFDD1B740A38CA9768C51EC011B2AF701 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | 728AEDB2DA037D9032F9697FFA7D9E070783A1F6 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | 75ADD82FA44C8E7D76414148CFE5E1131CD2AD0D | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | 9A11E4B46DC53E13043B9FC1EBAFE0128D699B58 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | B04176E992478C82F1AD7A5DC1D1D206B623D624 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | EDCC2668AF97EBA53CD8C228B9127F6CC73D9552 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

Quetzalcoatl | F922C23FF68AAADBD2C9A384471B63694A879BA5 | email:Quetzalcoatl_relays[]proton.me url:https://quetzalcoatl-relays.org

On Thursday, October 8th, 2026 at 10:56 AM, Marc-Etienne M.Léveillé via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:

Hi,

Marc-Etienne here, I've been looking at Ebury for quite some time (13 years now, yikes!). I'm the author of the latest (2024) report on Ebury and co-author of the original paper from 2014.

First, I'd like to thank you for coming forward about the compromise and detailing what you found. **A lot** of servers have been compromised by Ebury in the past but most victims, for good or bad reasons, decided _not_ to disclose they got comprised. I think if we actually work together, we can better remediate threats like Ebury.

I'd be happy to assist in any way. Here are some partial answers to your questions:

> Where did the attacker get the operator password before Aug 28?

That I couldn't say for sure. My best guess is a login from a host already compromised by Ebury.

Another possibility is a compromised hosting provider. We identified a couple of them in the past where their management servers were compromised by Ebury and their customers' VPSes, containers, etc., ended up running Ebury as well.

> How did Switzerland2's sshd accept a key that was in no authorized_keys

I'm really not sure, but maybe Ebury was already present before and was updated on Sept 30? But then if it was Ebury letting them in, that log line wouldn't even be there :-/

> What did guard, failover and snf do on Switzerland2?

I couldn't say. snf may stand for "sniff", so maybe some sort of traffic sniffing on the egress of the exit node?

> Where do the stolen credentials go?

They are kept in memory in a process spawn by Ebury until they are fetched using Ebury's "Xcat" command. There are daily SSH connections from the attacker infrastructure pulling them. After 14 days without Xcat, it will send them via UDP/53 to some exfil server. The "xpost.php" is exclusively for stuff captured from HTTP POST requests made by libcurl (Apache, PHP, etc). This additional module is not activated on non-HTTP servers.

> On Switzerland2, sudo logged the entire base64 installer across 64 "(command continued)"

Any chance you could share this publicly or privately?

> If you find it, take the relays down and mask the tor units, snapshot the disk, and rebuild from scratch rather than cleaning in place.

+1 on this. I will also add: Ebury will spider everywhere. Look at your .ssh/known_hosts file to see where this system connected to before. They certainly did, using every username password and key combination possible.

Also please try to capture anything that could help us better understand this group's impact and intent.

A few notes and advice for any other relay operators in the same situation:

- Ebury version 1.8.3 has been around since at least June 2026. Although _not_ a silver bullet, I've updated the detection script I made to include the latest versions I have: https://github.com/marc-etienne/eset-malware-research/blob/ebury_update/ebury/detect_ebury.sh. It wasn't merged in ESET's version yet (I no longer work there), but I will bump the PR I made for my ex-colleagues.

- Defusing the userland rootkit currently works with "I=1 bash" too. They replaced H with I after our 2024 publication. Now that I say this, next Ebury version will likely use J :P

- From your description it seems it is magling with network settings. The Ebury operators are known to play with them for capturing and redirecting traffic. Consider dumping netfilter tables (iptables-save, iptables-nft-save, nft list ruleset) as well routing tables and rules (ip link show, ip addr show, ip rule show, ip route show table all, ip tunnel show).

- If a process is running but the executable file is missing from disk, procfs will happily extract it from memory for you. Find the PID, and use `cp /proc/$PID/exe suspicious.elf` to dump the original file into suspicious.elf. gcore (just `gcore $PID`), part of gdb, can also be used to dump non-filebacked memory (heap, stack, rw mem). This could be helpful to extract configuration from running processes as well as reveil some details about the context of the execution (example: the SSH_CONNECTION envvar).

That's what I can think of off the top of my head for now. Given how many servers had Ebury between 2009 and 2023 (400 000!) there are most likely other compromised Tor relays out there. I wouldn't be surprised Ebury operators automated the process of installing "special tools" on Tor relay specifically, maybe to capture more SSH credentials from users connecting to SSH servers via Tor.

Feel free to reach out to me for any questions or if you find something interesting that may help better understand what Ebury is up to now :)

Cheers!

M-E

Attachment: publickey - tor@1aeo.com - 0x9288289B.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx