MikroTrick-Zero-Day-Kette verschafft Angreifern Administratorzugriff auf MikroTik-Router

MikroTik-RouterOS-Geräte, deren SSH-Dienst aus dem Internet erreichbar ist, werden derzeit über eine als MikroTrick bekannte Angriffskette angegriffen. Die Kampagne kann einen Angreifer von einem nicht authentifizierten SSH-Zugriff bis zur vollständigen administrativen Kontrolle über einen verwundbaren Router führen.

Die Kette kombiniert CVE-2026-67276, eine kritische Umgehung der RSA-Schlüsselauthentifizierung mit einem CVSS-Wert von 9,2, mit CVE-2026-86060, einer Schwachstelle zur Rechteausweitung innerhalb einer SSH-Sitzung. CERT Polska hat erfolgreiche Kompromittierungen bestätigt, darunter die Erstellung eines nicht autorisierten Kontos namens ops.

Der Sicherheitsforscher Costin Raiu berichtete, dass die Ausnutzung bereits am 2. September 2026 begonnen haben könnte – einen Tag bevor MikroTik die relevanten Fehlerbehebungen veröffentlichte. Damit handelt es sich bei MikroTrick um eine Zero-Day-Kampagne und nicht um eine Ausnutzung, die erst nach einer öffentlichen Analyse der Patches begann.

Angriffe begannen vor MikroTiks Sicherheitsupdates

In einem polnischen Sicherheitsforum veröffentlichte Logs zeigen offenbar bereits auf den 2. September datierte Ausnutzungsversuche. CERT Polska bestätigte unabhängig davon erfolgreiche Angriffe, die mindestens an diesem Tag begonnen hatten.

MikroTik veröffentlichte am 3. September 2026 Fehlerbehebungen in RouterOS 7.25beta3, 7.24.2, 7.23.4 und 6.49.21. Auch RouterOS 7.23.5, das am 4. September 2026 veröffentlicht wurde, wird als gepatcht eingestuft.

Raiu veröffentlichte seine technische Analyse am 5. September 2026. Ebenfalls an diesem Tag gab CERT Polska eine Warnung heraus, dass kritische RouterOS-Schwachstellen aktiv ausgenutzt würden, und forderte Kunden auf, ihre Systeme umgehend zu aktualisieren.

Der zeitliche Ablauf legt nahe, dass die Angreifer möglicherweise wussten, dass Fehlerbehebungen unmittelbar bevorstanden, und mit dem Scannen oder Ausnutzen von Geräten begannen, bevor Administratoren Patches zur Verfügung standen. Der Großteil der beobachteten Aktivitäten ging von einer einzigen Adresse aus. Das deutet auf einen Angriffsbetrieb hin, der exponierte Router in großem Maßstab angreifen konnte.

MikroTik verschickte Warnungen zu den Schwachstellen außerdem über seine offizielle mobile Anwendung. Berichten zufolge war dies das erste Mal, dass das Unternehmen diesen Kanal für eine Sicherheitswarnung nutzte.

Für diese Schwachstellen wurde bislang weder ein Eintrag im Katalog der von CISA bekannten ausgenutzten Schwachstellen noch eine damit verbundene Frist für Maßnahmen auf Bundesebene veröffentlicht. Die bestätigte Ausnutzung zeigt jedoch bereits, dass es sich um ein operatives und kein rein theoretisches Risiko handelt.

Wie die MikroTrick-Kette die SSH-Authentifizierung aushebelt

CVE-2026-67276 betrifft die Validierung von öffentlichen RSA-Schlüsseln durch RouterOS während der SSH-Authentifizierung. Kennt ein Angreifer einen gültigen Benutzernamen und den öffentlichen Bestandteil des RSA-Schlüssels dieses Benutzers, kann er einen gefälschten Schlüssel erstellen, den RouterOS akzeptiert, ohne dass er im Besitz des zugehörigen privaten Schlüssels ist.

Damit wird eine grundlegende Sicherheitsannahme von SSH verletzt. Öffentliche Schlüssel sollen autorisierte Zugangsdaten identifizieren, während der private Schlüssel beweist, dass die Verbindungspartei tatsächlich deren rechtmäßiger Besitzer ist. Verwundbare RouterOS-Versionen können dazu gebracht werden, eine Authentifizierung ohne diesen Nachweis zu akzeptieren.

Der unbefugte Zugriff wird anschließend mit CVE-2026-86060 kombiniert, die eine Rechteausweitung innerhalb einer SSH-Sitzung ermöglicht. Durch die Verkettung der beiden Schwachstellen kann ein entfernter, nicht authentifizierter Angreifer die vollständige administrative Kontrolle erlangen.

Für den Angriffsweg muss der SSH-Dienst von RouterOS aus dem Netzwerk des Angreifers erreichbar sein. Router, deren SSH-Dienst direkt aus dem öffentlichen Internet erreichbar ist, sind besonders gefährdet. Ein Gerät kann jedoch auch aus einem anderen nicht vertrauenswürdigen oder bereits kompromittierten Netzwerk angegriffen werden.

Die beiden Schwachstellen gehören zu sechs RouterOS-Fehlern, deren Offenlegung von CERT Polska identifiziert und koordiniert wurde. Die genauen verwundbaren Versionsbereiche wurden nicht veröffentlicht. Administratoren sollten ihre Installationen daher mit den Fehlerbehebungen für den jeweiligen Zweig abgleichen, anstatt davon auszugehen, dass eine nur geringfügig ältere Version sicher ist.

Die identifizierten korrigierten Versionen sind:

• RouterOS 7.25beta3
• RouterOS 7.24.2
• RouterOS 7.23.5
• RouterOS 7.23.4
• RouterOS 6.49.21

Sowohl 7.23.4 als auch 7.23.5 wurden als gepatchte Versionen bezeichnet. Betreiber sollten die aktuell unterstützte korrigierte Version für ihren jeweiligen Zweig installieren und die installierte Version nach einem Neustart oder dem Abschluss des Aktualisierungsvorgangs überprüfen.

Administrativer Zugriff legt den gesamten Netzwerkperimeter offen

Ein kompromittierter Router verschafft Angreifern mehr als nur einen Zugang zu einem einzelnen Gerät. Mit Administratorzugriff können sie das Routing verändern, Firewall-Richtlinien abschwächen, Datenverkehr mitschneiden, Verbindungen umleiten, Tunnel einrichten oder das Gerät als Proxy konfigurieren.

Angreifer können außerdem Benutzer und SSH-Schlüssel hinzufügen, geplante Aufgaben erstellen, Skripte bereitstellen oder Diensteinstellungen ändern, um ihren Zugriff dauerhaft aufrechtzuerhalten. Funktionen zum Mitschneiden von Netzwerkpaketen könnten Datenverkehr und Anmeldedaten offenlegen, die den Router passieren. Manipulierte Routing- oder DNS-bezogene Einstellungen könnten Benutzer zu einer von Angreifern kontrollierten Infrastruktur umleiten.

Langjährig eingesetzte MikroTik-Installationen sind besonders gefährdet, wenn sie nur eingeschränkt gewartet werden. Router können jahrelang in Betrieb bleiben, wodurch vergessene Geräte und nicht zentral verwaltete Bereitstellungen in Außenstellen besonders wahrscheinlich verspätet gepatcht werden.

Geräte, die die standardmäßige Firewall-Konfiguration von MikroTik verwenden und deren SSH-Dienst nicht aus dem öffentlichen Internet erreichbar ist, gelten als wahrscheinlich vor diesem speziellen entfernten Angriffsweg geschützt. Das bedeutet jedoch nicht, dass sie gepatcht oder auf anderem Weg nicht kompromittiert wurden. Ihre Erreichbarkeit für die Verwaltung und die installierten Softwareversionen müssen weiterhin überprüft werden.

Logs und Konfigurationsverlauf können eine Kompromittierung aufdecken

Ein fehlgeschlagener MikroTrick-Versuch kann einen Authentifizierungs-Logeintrag mit dem Benutzernamen -2 erzeugen. Dabei handelt es sich nicht um einen normalen Kontonamen. Taucht er in RouterOS-Aufzeichnungen auf, sollte der Eintrag untersucht werden.

Erfolgreiche Aktivitäten können unter /system history in einer Form wie der folgenden protokolliert werden:

ssh:-2@<IP>

Incident-Response-Teams sollten dieses Ereignis mit nachfolgenden administrativen Aktionen abgleichen. Zu den verdächtigen Änderungen können gehören:

• Erstellung oder Änderung von Benutzern und SSH-Schlüsseln
• Neue oder veränderte Skripte und Scheduler-Einträge
• Änderungen an aktivierten Diensten
• Veränderte Firewall- oder Routing-Regeln
• Aktivierung von Proxys oder Tunneln
• Konfiguration zum Mitschneiden von Netzwerkpaketen
• Andere nicht erklärbare Konfigurationsänderungen

Das nicht autorisierte Konto ops ist ein bestätigter Kampagnenindikator. Sein Vorhandensein sollte unverzüglich eine Untersuchung im Rahmen der Incident Response auslösen.

Das Fehlen eines -2-Eintrags beweist nicht, dass ein Router sauber ist. Logs können überschrieben, durch die Rotation entfernt oder von einem Angreifer gelöscht worden sein. Ein historisches Ereignis mit ssh:-2@<IP>, auf das eine Konfigurationsänderung folgt, sollte als bestätigte Kompromittierung behandelt werden, sofern es nicht aus einem autorisierten Sicherheitstest stammt.

Ermittler sollten sowohl den aktuellen Zustand als auch historische Aufzeichnungen überprüfen. Benutzer, Schlüssel, Skripte, Scheduler, Dienste, Firewall-Richtlinien, Proxys, Tunnel, Einstellungen zur Paketerfassung und Regeln für den Verwaltungszugriff müssen vollständig untersucht werden.

Kampagneninfrastruktur und Dateiindikatoren

Die meisten beobachteten Angriffe gingen von 82.192.72[.]4 aus, einer von Leaseweb gehosteten Adresse. Eine zweite Adresse, 103.102.31[.]18, wurde ebenfalls mit der Kampagne in Verbindung gebracht.

Auf der primären Adresse waren vier Dateien gehostet:

• Eine MIPS-Version der offiziellen vorkompilierten BusyBox-1.16.1-Binärdatei, kompiliert im Jahr 2010
• ftpsrv.py
• launch.sh
• serve.py

Zum Zeitpunkt der Untersuchung wurden drei der bereitgestellten Dateien von VirusTotal nicht erkannt. Eine niedrige oder fehlende Erkennungsrate sollte in diesem operativen Kontext nicht als Hinweis darauf interpretiert werden, dass die Dateien harmlos sind.

Verteidiger können gesammelte Dateien und Telemetriedaten anhand der folgenden SHA-256-Hashes durchsuchen:

Datei	SHA-256
ftpsrv.py	6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d
launch.sh	972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd
serve.py	6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e

Ein Hash für die BusyBox-Binärdatei wurde nicht veröffentlicht. Historische Netzwerkdaten sollten auf eingehende oder ausgehende Verbindungen zu beiden gemeldeten IP-Adressen untersucht werden.

Zuerst patchen, dann exponierte Router untersuchen

Administratoren sollten unverzüglich die passende korrigierte RouterOS-Version installieren und sicherstellen, dass das Upgrade erfolgreich war. SSH sollte deaktiviert oder eingeschränkt werden, wenn der Dienst aus dem Internet oder einem anderen nicht vertrauenswürdigen Netzwerk erreichbar ist.

Der Verwaltungszugriff sollte stattdessen auf vertrauenswürdige administrative Pfade, genau kontrollierte Quelladressen oder geschützte interne Zugriffsmechanismen beschränkt werden. Das Filtern der beiden Kampagnenadressen ist sinnvoll, kann das Patchen jedoch nicht ersetzen, da Angreifer auf eine neue Infrastruktur ausweichen können.

Jedes RouterOS-Gerät mit aus dem Internet erreichbarem SSH-Dienst sollte als potenziell kompromittiert behandelt werden, bis Logs, Konfigurationsverlauf, Benutzer, Schlüssel und aktive Einstellungen überprüft wurden.

Wird eine nicht autorisierte Administratoraktivität festgestellt, sollten Incident-Response-Teams den Router isolieren, Logs und Konfigurationsdaten sichern, Passwörter und SSH-Schlüssel austauschen, Persistenzmechanismen entfernen sowie Routing- und Firewall-Richtlinien überprüfen. Unter Umständen muss das Gerät über einen vertrauenswürdigen Prozess neu aufgebaut oder wiederhergestellt werden.

Bis zum 5. September wurde kein funktionsfähiger öffentlicher Proof of Concept gemeldet. Raiu schätzte, dass innerhalb von ein oder zwei Tagen einer auf GitHub erscheinen könnte, obwohl die aktive Ausnutzung bereits ohne einen solchen Proof of Concept stattfand. Auf öffentlich verfügbaren Exploit-Code zu warten, würde Verteidigern daher keinen sinnvollen Sicherheitsvorsprung verschaffen.