In het begin van oktober ontdekten onderzoekers een ernstige aanvalsketen waarbij Tor exit-relays werden misbruikt om SSH-verbindingen af te buigen. Wie tussen 1 en 5 oktober via Tor een SSH-server bezocht, kon—onder specifieke omstandigheden—een onderschept wachtwoord in de handen van aanvallers geven.
Het bijzondere: de trafiek liep niet naar de beoogde server, maar naar een interceptie-server die zich voordeed als host. Daarmee werd het voor slachtoffers mogelijk om zonder het te merken inloggegevens te verliezen. Hieronder lees je wat er precies gebeurde, waarom vooral wachtwoord-login risico loopt, en welke stappen relay-operatoren en gebruikers kunnen nemen.
Wat zijn Tor exit-relays en waarom is dit misbruik gevaarlijk?
Tor is opgezet als een netwerk van schakels. De exit relay is de laatste stap: daar verlaat het verkeer het Tor-netwerk en gaat het richting de uiteindelijke bestemming. Als juist die laatste stap wordt gecontroleerd of gemanipuleerd, kan de aanval zich richten op wat er daarna met de verbinding gebeurt.
In dit incident werden exit-relays niet alleen gebruikt als ‘doorgang’, maar actief ingezet om poort 22 (SSH) mogelijk te maken en vervolgens SSH-sessies om te leiden. Daardoor konden aanvallers loginpogingen zien en verwerken.
Hoe de aanval SSH omleidde
De kern van de aanval zat in het aanpassen van de exit-policy in de configuratie van Tor-relays (de torrc-bestanden). Normaal staat een exit relay alleen verkeer toe naar poorten die binnen die policy passen. Door die policy te herschrijven, konden aanvallers op relays die SSH eerst niet toelieten, toch SSH-verbindingen laten passeren.
De analyses beschrijven dat aanvallers:
- SSH (poort 22) toelieten op 342 relays die daarvoor blokkeerden;
- naast die relays ook nog 24 relays ombouwden tot exit waar ze eerst geen exit waren;
- met die wijziging het dataverkeer lieten landen bij één set van 12 interceptie-servers in plaats van de echte bestemming.
Omdat Tor-clients op basis van de exit-policy een exit kiezen die past bij de toegestane poorten, veranderde het gedrag zichtbaar: waar eerder andere (bijvoorbeeld e-mail) routes mogelijk waren, gingen de relays daarna verkeer dragen voor SSH en—in veel gevallen—ook voor overige plaintext-achtige diensten.
Waarom vooral wachtwoord-login kwetsbaar was
De omleiding werkte het best bij een specifieke SSH-stroom: password login nadat de gebruiker de veranderde hostkey accepteerde.
Wanneer de interceptie-server de verbinding overneemt, presenteert deze zijn eigen hostkey. Slachtoffers die al bekend waren met de echte hostkey, zagen een waarschuwing dat de remote host identification was gewijzigd. Nieuwe gebruikers zagen de standaardprompt om een nieuwe key te accepteren.
Wat daarna gebeurde:
- Wie het wachtwoord intypte op een verbinding via Tor die naar de interceptie-server ging, gaf die secret door aan de aanvaller.
- De interceptie-server maakte vervolgens een verbinding naar de echte server, zodat de sessie ‘normaal’ kon lijken.
- Omdat de aanvaller het wachtwoord al had, kon hij de inlog afhandelen en ook proberen privilege-escalatie of verdere acties te volgen via een logische vervolgketen.
Belangrijk verschil: key-based SSH (inloggen met publieke sleutel) kon in de beschreven situatie niet op dezelfde manier worden ‘doorgestuurd’. De SSH-handshake houdt rekening met session-specifieke identificatoren, waardoor een handtekening voor de ene sessie niet zomaar bruikbaar is voor de andere.
Wie was mogelijk blootgesteld?
Of iemand daadwerkelijk getroffen werd, is niet precies te tellen. De blootstelling vereiste meerdere voorwaarden tegelijk:
- Je moest tussen 1 oktober en 5 oktober (middag) via Tor een SSH-server gebruiken;
- je moest uitkomen op een relay die tijdens die periode de aangepaste exit-policy had;
- de verbinding moest door de interceptie-route gaan, niet doorgestuurd worden naar de echte bestemming;
- je moest de hostkey accepteren die door de interceptie-server werd gepresenteerd;
- en je moest inloggen met een wachtwoord.
Een cruciaal extra punt: op het moment dat een gebruiker zo’n hostkey accepteerde, moest het wachtwoord als mogelijk gestolen worden behandeld.
Wat Tor-projecten en onderzoekers deden om het te stoppen
De aanval werd niet ‘automatisch’ uitgeschakeld, maar door detectie en ingrijpen. Een onderzoeker ontdekte de omleiding op 2 oktober nadat een SSH-verbinding via Tor een waarschuwing gaf over een gewijzigde hostkey.
Daarna werd met een scan-aanpak nagegaan welke exits omleidden naar dezelfde interceptie-servers. Daarnaast signaleerde het Tor-netwerkteam de problematiek: relays werden gemarkeerd en uit de consensus van Tor gehaald.
Concreet kwam de actie neer op het plaatsen van vlaggen zodat Tor-clients die relays niet meer als exit zouden gebruiken. In de periode rond 4 en 5 oktober was de impact aan het afbouwen: relays met de aanvalspolicy vielen weg uit de consensus en bleven daarna grotendeels niet terugkeren.
Praktische check voor relay-operators (Linux)
Voor wie zelf Tor-relays beheert, ging de waarschuwing vooral over het controleren van de exit-configuration en mogelijke tekenen van manipulatie.
De meldingen adviseren om te letten op:
- een exit-flag of exit-policy die je niet hebt ingesteld;
- wijzigingen in torrc en ingesloten configuratiebestanden (bijvoorbeeld regels zoals ExitRelay/ExitPolicy en contact- of familyvelden);
- aanpassingen aan NAT-regels rond poort 22;
- nieuwe luisterende processen of uitgaande verbindingen die niet passen bij normaal gedrag;
- wijzigingen in gebruikers en geautoriseerde keys;
- nieuwe of onverwachte cronjobs en systemd-units;
- een tor-binaire die niet aan pakket- of integriteitsverwachtingen voldoet.
Verder wordt benadrukt dat een ‘schone’ host-check niet automatisch uitsluit dat er alsnog een implant actief was: bij sommige gevallen leek het spoor vooral terug te leiden naar de exit-policy-wijzigingen.
Wat gebruikers moeten doen als ze een gewijzigde hostkey accepteerden
Voor gebruikers is het belangrijkste: stel dat een geaccepteerde, onbekende of veranderde hostkey een signaal is dat je wachtwoord mogelijk is onderschept. Als je in het relevante tijdvenster over Tor een hostkey accepteerde die afweek van wat je verwachtte, neem dan deze maatregelen:
- Behandel het wachtwoord als gestolen: verander het onmiddellijk op het betreffende systeem.
- Controleer of er tekenen zijn van geavanceerdere sporen op de server die je bezocht hebt.
- Wees extra alert op vervolgacties met dat account (bijvoorbeeld nieuwe sessions, sudo-gebruik of onverwachte scripts).
Voor extra veiligheid helpt het ook om in de toekomst zoveel mogelijk naar key-based SSH te migreren en zorgvuldig om te gaan met hostkey-warnings. Een waarschuwing is geen formaliteit; in dit soort scenario’s kan het direct het verschil maken.
Waarom dit ook raakt aan OpenSSH-implicaties
De incidentanalyse verbindt de uitrol aan een backdoor/credential-stealer die bekendstaat als Ebury. In een post-mortem wordt beschreven hoe de aanvaller toegang kreeg, vervolgens implantatie uitvoerde en exit-relays gebruikte om later wachtwoordlogins af te vangen.
Voor organisaties betekent dit vooral: beperk je niet tot ‘alleen patches’. Ook wanneer een server na een reboot ogenschijnlijk “weer normaal” draait, kan een implant terugkeren of sporen veranderen. Daarom zijn integriteitschecks, configuratie-inspectie en incidentrespons-procedures essentieel.
Maak je aanpak completer: van detectie tot herstel
Wil je dit soort risico’s structureel verkleinen, dan helpt het om je securityproces te koppelen aan snelle detectie en herstel. Richt je daarbij op drie lijnen: (1) configuratiewijzigingen vroeg signaleren, (2) wachtwoordflows waar mogelijk verminderen en (3) bij incidenten gericht controleren op zowel host- als verbindingsteken.
Als je dit onderwerp breder bekijkt binnen moderne aanvallen, kan ook nuttig zijn om te lezen hoe beveiliging omgaat met agent- en runtime-context. Bijvoorbeeld: AI-agent runtime security: Beacon en beleid. En voor het perspectief op hoe “hijack”-achtige trajecten zich in praktijk versnellen, past Ransomware en snelle exploitatie: Q3-trends als achtergrondkader.
Conclusie
Dit incident laat zien hoe krachtig de combinatie is van toegang tot infrastructuur en misbruik van netwerkfuncties: Tor exit-relays werden aangepast zodat SSH via interceptie kon lopen. Slachtoffers die in de bewuste periode een gewijzigde hostkey accepteerden en met wachtwoorden inlogden, konden hun credentials kwijtraken.
Heb je als gebruiker in die tijd een hostkey-warning geaccepteerd? Zet dan meteen de volgende stap: wachtwoorden wijzigen en de server controleren. Beheer je Tor-relays? Laat dan torrc, exit-policy en netwerksporen streng doorlichten. Zo voorkom je dat je relay een onbedoelde schakel wordt in een groter aanvalstraject.
Bron: https://thehackernews.com/2026/10/attackers-hijacked-over-300-tor-exit.html
