MikroTrick: przejęcia MikroTik RouterOS przez SSH w naturze

MikroTik RouterOS spędził pierwszy tydzień września 2026 w środku szybkiego incydentu na brzegu sieci. CERT Polska skoordynował ujawnienie sześciu błędów w RouterOS i potwierdził, że dwa z nich są już łączone w atakach w naturze w pełne przejęcie bez uwierzytelnienia, o ile SSH jest osiągalne z internetu.

Ten łańcuch nazwano MikroTrick. Jeśli masz sprzęt MikroTik w homelabie, jako CPE u ISP, firewall oddziału albo CHR na VPS, najpierw patch, potem hunting.

Co się zmieniło, po kolei

MikroTik opublikował poprawione buildy RouterOS 3 września 2026. CERT Polska podał kontekst techniczny i CVE 5 września. Ślady eksploatacji sięgają co najmniej 2 września, czyli dzień przed publicznymi poprawkami. Właśnie dlatego część relacji opisuje kampanię jako zero-day w praktyce: atakujący zdążyli działać, zanim floty zostały zaktualizowane.

MikroTik zrobił też coś rzadkiego. Po raz pierwszy wysłał powiadomienie push w aplikacji mobilnej z wezwaniem do aktualizacji. Traktuj to jako sygnał wagi, nie jako marketing.

Łańcuch MikroTrick bez recepty exploita

Publiczny opis CERT Polska wystarczy administratorom. Nie publikuję tu PoC.

CVE-2026-67276 (CVSS 9.2) to obejście uwierzytelniania SSH. RouterOS nie weryfikował w pełni klucza publicznego RSA używanego przy logowaniu. Nie porównywał całego materiału klucza przypisanego do użytkownika. Atakujący znający nazwę konta i wystarczający materiał klucza publicznego mógł się uwierzytelnić bez legalnego klucza prywatnego.

CVE-2026-86060 (CVSS 9.2) to eskalacja uprawnień w sesji SSH. Spreparowane nazwy użytkownika w ścieżce logowania mogły dać sesję z pełnymi uprawnieniami administracyjnymi RouterOS.

Razem ścieżka jest prosta do nazwania i brzydka w produkcji: SSH wystawione na świat, sesja, kontrola na poziomie admina. Bez hasła. Bez kliknięcia użytkownika.

CVE-2026-67277 (CVSS 8.8) dotyczy usługi bandwidth-test i może wyciekać pamięć kernela albo zdalnie zcrashować urządzenie. To nie jest główna ścieżka MikroTrick, ale kolejny argument, by nie wystawiać usług management-adjacent do internetu. CERT zgłosił też kolejne problemy wokół SSH, X.509 i WebFig. Wrześniowy update traktuj jako pakiet.

Jeśli chcesz szerszej ramy, jak podatności, IoC i mitygacje układają się w decyzję operatorską, rozpisałem to w [Vulnerabilities, IoCs, and Mitigations](/pl/research/vulnerabilities-iocs-mitigations).

Kto realnie jest wystawiony

Biuletyn MikroTik jest ostrożny. Domyślne konfiguracje, które nie otwierają SSH na świat, siedzą w dużo lepszej sytuacji. Ostre ryzyko dotyczy urządzeń, gdzie ktoś ręcznie wystawił management, zwłaszcza SSH, na niezaufane sieci "na chwilę".

Ten wzorzec wraca stale: małe biura z przekierowanym Winboxem lub SSH, floty CPE u ISP i WISP z nawykami zdalnego zarządzania, labowe routery na publicznych VPS oraz setupy "potem dam WireGuarda", które nigdy nie dostały tego potem. W oknie disclosure skanowanie pokazywało ponad 100 tys. hostów MikroTik z widocznym SSH z internetu. Nie wszystkie dzielą tę samą klasę ryzyka, ale powierzchnia była wystarczająco duża, by oportunistyczne skany były pewne.

Wersje z poprawką

Zainstaluj jedną z linii wskazanych przez MikroTik i CERT Polska:

1. 7.25beta3
2. 7.24.2
3. 7.23.4
4. 6.49.21

Użyj System, Packages, Check for updates albo swojego pipeline'u flotowego. Nie wymyślaj buildów "prawie tych". Po upgrade od razu przejdź do kontroli kompromitacji. Łata zamyka dziurę. Nie cofa wcześniejszego przejęcia.

Kontrole mostkowe, jeśli nie dasz rady załatać w tej godzinie

To redukuje blast radius. Nie zastępuje update'u.

Zdejmij ekspozycję SSH, WWW, WWW-SSL i bandwidth-test. Management tylko z jump hosta, sieci OOB albo mocnego VPN. MikroTik wprost sugeruje dostęp w stylu WireGuard i brak otwartych portów zarządzania. Do czasu patcha unikaj wbudowanych klientów SSH i TLS urządzenia wobec niezaufanych peerów, w tym /system ssh i /system ssh-exec. Zrób inventory wszystkich instancji RouterOS: oddziały, backupy, zapomniane AP z RouterOS i wirtualne CHR.

Hunting po każdym upgrade

Poprawione buildy mają mechanizm Flagged. Przy starcie RouterOS może przeskanować znane odciski nieautoryzowanych zmian, wyłączyć część podejrzanych wpisów, wpisać critical do logu i ustawić znacznik ostrzeżenia.

Krytyczna uwaga CERT Polska nadal obowiązuje: brak Flagged nie jest dowodem czystości. Atakujący zmieniają tooling. Marker łapie wybrane fingerprinty, nie każdy stan po eksploatacji.

Uruchom przynajmniej:

/system/device-mode/print
/log print where message~"-2"
/user print where name="ops"
/user print
/system script print
/system scheduler print
/ip service print

Sprawdź też proxy, tunele, reguły firewall oraz automatyzację fetch lub import, której nie tworzyłeś.

CERT powiązał obserwowane ataki z wzorcami w logach w stylu:

login failure for user -2 from <ip> via ssh
user <name> added by ssh:-2@<ip>

Dodatkowy wskaźnik to wysoko uprzywilejowany lokalny user ops. W advisory z 5 września CERT wskazał m.in. 82.192.72.4 dla udanych ataków i tworzenia ops od co najmniej 2 września oraz 103.102.31.18 dla prób eksploatacji. Traktuj te IP jako pivoty śledcze, nie jako zamkniętą listę złych. Infrastruktura się rotuje.

Stronę "co dalej po IoC" rozwinąłem w [Incident Response and Vulnerability Management](/pl/research/incident-response-vulnerability-management).

Jeśli Flagged albo cokolwiek wygląda źle

Zakładaj przejęcie, dopóki nie udowodnisz inaczej. Izoluj urządzenie z ruchu produkcyjnego, jeśli możesz. Zabezpiecz logi i konfigurację przed wipe, używając zaufanej procedury eksportu. Zgłoś do właściwego CSIRT, jeśli jesteś w zakresie. Zrób factory reset, potem odbuduj z known-good config. Nie przywracaj ślepo pełnego backupu z potencjalnie zatrutego urządzenia. Rotuj hasła, klucze SSH, PSK VPN, sekrety RADIUS, tokeny API i certyfikaty z tego boxa. Nie czyść znacznika Flagged przed zakończeniem obsługi dowodów.

Router brzegowy to kotwica zaufania. Ciche konto admina plus implant tunelu albo skrypt w schedulerze przeżyje moment "zaktualizowałem, wygląda OK".

Dlaczego ta sprawa wychodzi poza MikroTik

Ekspozycja management plane'u nadal jest najtańszym krytycznym findingiem. Błędy w walidacji kluczy mają znaczenie, ale wzorzec operacyjny jest stary: SSH na 0.0.0.0/0.

Okno ciszy vendora i diff patchy działa w obie strony. MikroTik początkowo nie publikował szczegółów, by dać czas na update. Gdy paczki trafiły publicznie, społeczność mogła odtworzyć część napraw. Brak posta na blogu nie oznacza, że atakujący grzecznie czekają.

CERT Polska podał też, że badania użyły GPT-5.5-cyber i GPT-5.6-sol w nadzorowanym labie agentowym z prawdziwymi RouterOS, kontrolami negatywnymi i weryfikacją ludzi. Wniosek nie brzmi "modele magicznie znajdują CVE". Dobrze zbudowany lab plus eksploracja wspomagana modelem przyspiesza hipotezy protokołowe i binarne, gdy człowiek nadal trzyma scope, safety i confirmation.

Jeśli mapujesz taki edge compromise na język kontrolek w stylu Security+, przydatnym companionem jest [Security Controls, CIA, and AAA](/pl/research/security-controls-cia-aaa).

Domknięcie praktyczne

Zrób inventory każdego RouterOS, w tym CHR, backupów i labu. Upgrade do 7.24.2, 7.23.4, 6.49.21 albo 7.25beta3. Potwierdź, że SSH, Winbox i WWW nie są wystawione do internetu. Sprawdź /system/device-mode/print pod Flagged. Przeszukaj logi pod -2 i ssh:-2@ oraz userów pod ops. Przejrzyj skrypty, scheduler, tunele i proxy. Przy podejrzeniu: izolacja, secure evidence, reset, rebuild, rotacja sekretów.

Główne źródła: [advisory CERT Polska](https://cert.pl/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/) oraz [biuletyn MikroTik z września 2026](https://mikrotik.com/supportsec/september-2026-vulnerability).

TL;DR: jeśli SSH RouterOS kiedykolwiek patrzyło na internet, patch teraz, a higienę po upgrade traktuj jako część incydentu, nie opcjonalny appendix. MikroTrick wyszedł już poza stadium teoretycznego CVE.