Zum Inhalt springen

MikroTrick: Angreifer übernehmen MikroTik-Router über offenes SSH

Seit Anfang September laufen aktive Angriffe gegen MikroTik-Router, bei denen Angreifer ohne gültige Zugangsdaten die volle Kontrolle über das Gerät erlangen. Möglich macht das eine Angriffskette namens MikroTrick, die zwei kritische Schwachstellen im SSH-Dienst von RouterOS kombiniert. Betroffen sind Geräte, deren SSH-Zugang offen im Internet steht. Nach Auswertungen mehrerer Quellen sind das je nach Zählweise über 100.000 Geräte. Wer einen solchen Router betreibt, sollte ihn jetzt patchen und auf Spuren einer Übernahme prüfen.

Was ist passiert

Das polnische CERT (CERT Polska) hat sechs Schwachstellen in MikroTik RouterOS entdeckt und am 5. September 2026 öffentlich gemacht. Zwei davon lassen sich zur Angriffskette MikroTrick verbinden, mit der ein nicht authentifizierter Angreifer die vollständige administrative Kontrolle über ein Gerät übernehmen kann, sofern dessen SSH-Dienst aus öffentlichen Netzen erreichbar ist.

Brisant ist der zeitliche Ablauf. MikroTik hat die Fehler am 3. September 2026 mit einem bewusst knapp gehaltenen Update behoben und dazu nur von einem wichtigen Sicherheitsupdate gesprochen, ohne technische Details zu nennen. CERT Polska konnte jedoch belegen, dass die ersten erfolgreichen Angriffe bereits seit mindestens dem 2. September liefen, also einen Tag vor der Veröffentlichung des Patches. Es handelt sich damit um eine Zero-Day-Ausnutzung. Vieles deutet darauf hin, dass jemand vorab von den anstehenden Fixes wusste und die Lücke gezielt ausgenutzt hat, bevor sie öffentlich bekannt wurde.

Bemerkenswert am Rande: MikroTik hat zum ersten Mal überhaupt eine Push-Benachrichtigung an die Smartphones der Nutzer mit installierter MikroTik-App geschickt, um auf das Update aufmerksam zu machen. Entdeckt wurden die Schwachstellen von Sławomir Rozbicki aus dem CERT-Polska-Team, unterstützt durch KI-Modelle in einer agentenbasierten Analyseumgebung.

Die Schwachstellen im Detail

Die Angriffskette MikroTrick besteht aus zwei kritischen Lücken:

  • CVE-2026-67276 (CVSS 9.2), eine Umgehung der SSH-Authentifizierung. RouterOS prüfte den öffentlichen Schlüssel bei der SSH-Anmeldung nicht vollständig, insbesondere wurde der gesamte RSA-Schlüssel eines Nutzers nicht verglichen. Wer den Benutzernamen und den öffentlichen Modulus des hinterlegten Schlüssels kennt, kann einen abweichenden Schlüssel bauen und sich anmelden, ohne den zugehörigen privaten Schlüssel zu besitzen. Die erlangten Rechte entsprechen denen des angegriffenen Kontos.
  • CVE-2026-86060 (CVSS 9.2), eine Rechteausweitung über einen manipulierten Benutzernamen. RouterOS verarbeitete Benutzernamen, die mit einem unzulässigen Zeichen beginnen, fehlerhaft. Über einen präparierten Benutzernamen konnte ein Angreifer seine Rechte ausweiten und erhielt eine Sitzung mit vollen Administratorrechten.

In Kombination führen beide Fehler dazu, dass ein Angreifer ohne vorherige Anmeldung Administratorzugriff auf ein per SSH exponiertes RouterOS-Gerät bekommt und Benutzer, SSH-Schlüssel, Firewallregeln, Skripte, Proxys und Tunnel nach Belieben verändern kann.

Eine dritte relevante Lücke ist CVE-2026-67277 (CVSS 8.8) im Bandwidth-Test-Dienst. Sie erlaubt einer unauthentifizierten Verbindung einen Zustand, der eigentlich erst nach der Anmeldung erreichbar sein sollte. In Verbindung mit dem Auslesen nicht initialisierter Speicherbereiche und einem Integer-Underflow bei der Größenprüfung kann das zu einem Leck von Kernel-Speicher oder zu einem Neustart des Systems durch einen Denial-of-Service führen.

Wer ist betroffen

Gefährdet sind MikroTik-Geräte mit RouterOS, deren SSH-Dienst aus dem Internet erreichbar ist. Die Standardkonfiguration für Heimgeräte blockiert den SSH-Port über die eingebaute Firewall, sodass solche Geräte laut MikroTik keinem unmittelbaren Risiko ausgesetzt sind. Deutlich höher ist das Risiko dort, wo Administratoren den Port manuell geöffnet oder die Firewallregeln angepasst haben.

Zur Größenordnung der Angriffsfläche kursieren unterschiedliche Zahlen, weil interne Scans Dienste und nicht einzelne Geräte zählen. Cybernews nennt über 122.500 MikroTik-Router mit offen erreichbarem SSH. Shodan-Scans zeigen laut weiteren Berichten rund 300.000 potenziell verwundbare Geräte, die noch online sind. Beide Zahlen machen deutlich, dass automatisierte Angreifer reichlich Ziele finden. Das kanadische Centre for Cyber Security führte am 8. September 2026 die drei genannten CVEs als in freier Wildbahn ausgenutzt.

Anzeichen einer Kompromittierung

Die beobachteten Angriffe hinterlassen im RouterOS-Log charakteristische Einträge. Prüfenswert sind Zeilen der Form „login failure for user -2 from <ip> via ssh“ sowie“ user <name> added by ssh:-2@<ip>“. Ein weiteres deutliches Indiz ist ein hochprivilegierter Benutzer mit dem Namen „ops“.

CERT Polska hat die erfolgreichen Angriffe, einschließlich der Anlage des Kontos ops, auf die IP-Adresse „82.192.72.4“ zurückgeführt, aktiv seit mindestens dem 2. September. Zusätzlich kam die Adresse „103.102.31.18“ bei Ausnutzungsversuchen zum Einsatz.

Wichtig ist die richtige Einordnung dieser Spuren. Ihr Vorhandensein ist ein klares Zeichen für einen Angriffsversuch und muss sofort untersucht werden. Ihr Fehlen ist jedoch kein Beweis für Sicherheit. RouterOS setzt in den gepatchten Versionen beim Start ein Flagged-Kennzeichen, wenn bekannte Spuren einer unautorisierten Änderung gefunden werden. Auch dieser Marker erkennt nur ausgewählte Hinterlassenschaften. Ist ein Gerät als kompromittiert markiert, sollte man von einer Übernahme ausgehen.

Handlungsempfehlungen
  • RouterOS umgehend auf eine der bereinigten Versionen aktualisieren: 7.25 beta 3, 7.24.2, 7.23.4 oder 6.49.21. Beachten Sie, dass MikroTik nach einer IPv6-DHCP-Regression in 7.23.4 die Version 7.23.5 nachgereicht hat, die das Sicherheitsupdate weiterhin enthält.
  • SSH nicht offen ins Internet stellen.
  • Kann der Patch nicht sofort eingespielt werden, exponierte Dienste vorübergehend deaktivieren oder abschotten.
  • Bei Anzeichen einer Kompromittierung das Gerät vom Netz trennen und vor einem Reset zunächst Logs und Konfiguration sichern.