Mehr als 330 Tor-Server hat ein bislang unbekannter Angreifer mit der Linux-Malware Ebury infiziert, zu Exit-Relays umfunktioniert und darüber SSH-Verbindungen abgefangen sowie E-Mail-Traffic zum Downgrade gebracht. Die kompromittierten Tor-Exit-Nodes waren zwischen dem 2. und 5. Oktober 2026 aktiv – drei Tage lang, in denen mehr als zehn Prozent aller Exit-Relays des Netzwerks unter fremder Kontrolle standen. Betroffen sind Admins, die SSH-Sitzungen über Tor führen, und alle, die im selben Zeitfenster E-Mail-Protokolle über Tor genutzt haben. Unabhängig bestätigt ist die Größenordnung von mehr als 300 Exit-Nodes sowie die Umleitung von E-Mail- und SSH-Verbindungen.
Tor-Exit-Nodes: drei Tage, ein Ingenieur, eine Blocklist
Die Server waren bereits vor der aktiven Angriffsphase kompromittiert und liefen als Exit-Relays, bevor sie auffielen. Entdeckt wurde die Kampagne von einem Schweizer Ingenieur, der die Auffälligkeiten an das Tor-Sicherheitsteam meldete – nach drei Tagen, in denen die Nodes ungestört SSH-Verbindungen umleiteten und E-Mail-Verbindungen auf unverschlüsselte Varianten herabstuften. Das Team informierte die Betreiber der Relays; die betroffenen Maschinen wurden anschließend entweder von ihren Betreibern abgeschaltet oder auf eine Blocklist gesetzt, sodass kein Tor-Traffic mehr über sie lief.
Die Dimension ist ungewöhnlich. Als Vergleichsfall dient der November 2023, als mehr als 1.000 Tor-Server aus dem Netzwerk entfernt wurden, weil sie über ein profitorientiertes Kryptowährungs-Schema betrieben wurden. Damals ging es um wirtschaftlichen Missbrauch, jetzt um das gezielte Abgreifen von Verbindungsdaten – und damit um eine Schwachstelle im Betriebsmodell des Netzwerks selbst.
Wie der Man-in-the-Middle-Angriff über Exit-Relays funktioniert
Exit-Relays sind bauartbedingt Man-in-the-Middle: Der letzte Hop im Tor-Netzwerk entschlüsselt den Traffic, bevor er das Ziel erreicht, und kann ihn deshalb mitlesen, DNS-Antworten vergiften sowie HTTPS-MitM und sslstrip fahren. Ein Exit, der von einem Angreifer kontrolliert wird, braucht dafür keine zusätzliche Lücke im Protokoll – er muss nur als letzter Knoten gewählt werden.
Genau das macht die aktuelle Kampagne so effektiv. Der TorBrowser hilft gegen diesen Angriff nicht weiter: Schutzmechanismen wie HTTPS-Everywhere und NoScript greifen bei Protokollen wie SSH überhaupt nicht, weil sie auf HTTP-Ebene ansetzen. Wer SSH über Tor administriert, vertraut dem Exit-Relay blind – inklusive Hostkey, der über genau diesen Kanal ausgeliefert wird. Wird der SSH-Hostkey über eine kompromittierte Verbindung ausgetauscht, ist der Man-in-the-Middle für den Client nicht mehr von einer echten Verbindung zu unterscheiden.
Erschwerend kommt die Zuordnung hinzu. Ein bösartiger Exit lässt sich nur clientseitig über den selbst gewählten Exit identifizieren; eingehender Traffic am SSH-Server erlaubt diese Zuordnung nicht. Wer im Nachhinein prüfen will, ob eine Sitzung über einen der blockierten Relays lief, muss die eigenen Logs und die lokal gespeicherten Exit-Adressen auswerten – serverseitig ist der Vorgang nicht rekonstruierbar.
BadExit-Flag: wirksam, aber mit Verzögerung
Das Tor-Projekt kann verdächtige Relays mit dem BadExit-Flag belegen. Nachdem ein Angriff reproduziert wurde, setzen die Directory-Authorities das Flag, es propagiert innerhalb von maximal drei Stunden über das Consensus, danach wählen Clients das Relay nicht mehr als letzten Hop. Als Entry- oder Middle-Relay bleibt es allerdings weiter nutzbar. Alternativ lässt sich das Valid-Flag entziehen – dann wird das Relay für keinen Hop mehr ausgewählt.
Die zweite Schwachstelle ist organisatorischer Natur: Kontaktangaben von Relay-Betreibern sind freiwillig. Im Januar 2014 hatten von 4.962 erfassten Relays nur 56 Prozent überhaupt eine Kontaktadresse hinterlegt. Wer ein Relay ohne Kontaktdaten betreibt, ist im Ernstfall nicht erreichbar – die Blocklist ist dann die einzige Option, und sie greift erst, nachdem der Angriff erkannt wurde. Dass die Entdeckung diesmal einem einzelnen aufmerksamen Nutzer zu verdanken war, ist kein beruhigender Befund für ein Netzwerk, dessen Sicherheitsmodell auf Vielfalt und Beobachtung setzt.
SSH-Angriffe über Exit-Nodes sind kein neues Phänomen
Bereits 2007 lieferte ein Exit-Node fortlaufend wechselnde SSH-Keys aus, um Man-in-the-Middle-Angriffe gegen SSH-Sitzungen zu fahren; der betroffene Relay wurde damals als Exit delistet. 2014 dokumentierten zwei Forscher der Universität Karlstad über vier Monate hinweg zahlreiche bösartige Exit-Relays mit unterschiedlichen Angriffsmustern und entwickelten daraus einen Scanner zur kontinuierlichen Überwachung. Die Erkenntnis von damals gilt unverändert: Einzelne bösartige Exits sind messbar, ihre systematische Erkennung erfordert aber laufende Beobachtung statt Reaktion im Akutfall.
Für den aktuellen Vorfall heißt das: Die Kampagne ist kein Ausreißer, sondern die bislang größte Ausprägung eines bekannten Musters. Neu ist weniger die Technik als die Menge – mehrere hundert gekaperte Relays gleichzeitig bedeuten, dass die Wahrscheinlichkeit, zufällig über einen der betroffenen Exits zu routen, für einen erheblichen Teil der SSH- und Mail-Verbindungen über Tor bestand.
Was Betroffene jetzt prüfen sollten
- SSH-Hostkeys verifizieren: Fingerabdrücke der kontaktierten Systeme gegen einen vertrauenswürdigen Wert prüfen, der nicht über Tor beschafft wurde – etwa aus dem internen Configuration Management oder per Out-of-Band-Kanal.
- Keine SSH-Sitzungen über Tor ohne eigene Verifikation: Wo administriert werden muss, vor der Sitzung den Hostkey abgleichen und die Verbindung nicht blind auf den ersten angebotenen Key aufbauen.
- E-Mail-Verschlüsselung erzwingen: Clients so konfigurieren, dass TLS nicht herunterhandelbar ist und ein Downgrade auf unverschlüsselte Verbindungen scheitert. Mail-Clients ohne zwingende TLS-Durchsetzung sind in Kombination mit einem fremden Exit exponiert.
- Zugangsdaten rotieren: Für Sitzungen aus dem Fenster 2. bis 5. Oktober Passwörter und SSH-Keys wechseln – unabhängig davon, ob ein konkreter Missbrauch nachweisbar ist.
- Relays mit Kontaktadresse betreiben: Wer selbst ein Exit betreibt, sollte erreichbar sein; die Blocklist ist die schlechtere von zwei Optionen.
Fazit
Der Vorfall zeigt eine Grenze der Tor-Architektur, die sich nicht wegpatchen lässt: Wer den letzten Hop kontrolliert, sieht den Klartext. Solange Betreiberangaben freiwillig sind und die Erkennung bösartiger Exits von einzelnen Beobachtern abhängt, bleibt das Netzwerk auf aufmerksame Nutzer angewiesen. Für Admins heißt das konkret: SSH und E-Mail gehören nicht ungeprüft durch fremde Exits – Hostkey-Verifikation und erzwungenes TLS sind keine Kür, sondern die einzige Kontrolle, die auf Client-Seite bleibt.