Agent AI w laboratorium CERT Polska sam stawiał maszyny wirtualne z systemem RouterOS, robił ich migawki, uruchamiał testy i zbierał wyniki, a pod koniec badań obsługiwał 40 takich maszyn. W ten sposób zespół badał routery MikroTik, które według oceny CERT atakowano jeszcze przed wydaniem poprawek. CERT opisał tę pracę w analizie z 22 września i pokazał też jej koszt. Najwięcej czasu wymagały przygotowanie kontekstu dla agenta i laboratorium. W tej samej grupie CERT wymienia rozstrzyganie niejednoznacznych wyników i sprawdzanie ich na prawdziwych wersjach systemu. To rzadki opis tego, jak AI w cyberbezpieczeństwie pracuje w praktyce, z liczbami i od polskiej instytucji państwowej.
Czym jest MikroTrick i co CERT Polska opublikował 22 września
Analiza CERT Polska nosi tytuł “MikroTrick: analiza techniczna, proces ujawnienia i zastosowanie agentów LLM”, a jej autorem jest Sławomir Rozbicki. Opisuje łańcuch dwóch luk w serwerze SSH systemu RouterOS, który daje atakującemu pełną konsolę administracyjną bez hasła i bez klucza.
Pierwsza luka, CVE-2026-67279, dotyczy ponownej wymiany kluczy, czyli operacji nazywanej rekey. Klient mógł ją zainicjować w trakcie logowania. Podatny serwer po jej zakończeniu przechodził wtedy od razu do obsługi kanałów, jakby logowanie się udało. Druga, CVE-2026-86060, polega na tym, że nazwę użytkownika -2 program logowania traktował jak numer deskryptora pliku. Wczytywał wtedy uprawnienia z danych, które podsunął mu atakujący.
MikroTik wydał poprawki 3 września dla czterech gałęzi: 7.25beta3, 7.24.2, 7.23.4 i 6.49.21. Najwcześniejsze publiczne logi ataków pochodzą z 2 września. CERT pisze, że jego zdaniem MikroTrick był wykorzystywany przed publikacją aktualizacji. Same luki i sposób sprawdzenia routera opisaliśmy w tekście o sześciu lukach w MikroTik RouterOS. Tutaj zajmujemy się tym, co jest w nowej analizie: jak CERT tych luk szukał.
Przy okazji CERT prostuje jedną rzecz z obiegu. CVE-2026-67276 bywała łączona z łańcuchem MikroTrick, choć to osobna luka. Pozwala podszyć się pod użytkownika logującego się kluczem RSA. Wymaga jednak znajomości nazwy jego konta i klucza publicznego, więc do masowego ataku nadaje się znacznie gorzej.
Z jakich modeli AI korzysta CERT i co wiadomo o ich udziale
Badania RouterOS zespół prowadził z modelami GPT-5.5-cyber i GPT-5.6-sol, które CERT opisuje jako modele o obniżonym progu odmów. Dostęp do nich dał program OpenAI GTAC. Chodzi o wersje, które rzadziej odmawiają zadań związanych z atakami. Przy badaniu luk takie zadania są codziennością.
CERT ma też własną infrastrukturę, na której lokalnie uruchamia duże modele o otwartych wagach: GLM, DeepSeek, Qwen i polski PLLuM. Analiza wymienia je osobno, jako modele dostępne w CERT, i nie potwierdza ich udziału w badaniu MikroTika. Nie pisze też, który model wykonał które zadanie ani który przyczynił się do którego ustalenia. To ważne zastrzeżenie. Najłatwiej byłoby dopisać tu tezę o polskim modelu, który znalazł lukę, a źródło takiej tezy nie zawiera.
Co robił agent AI, a czego CERT mu nie przypisuje
CERT zaczyna od warunku. Skuteczność badań zależała według niego od izolowanego laboratorium, w którym agent mógł sam sterować maszynami wirtualnymi. Drugim warunkiem było właściwe określenie zakresu eksperymentów.
Laboratorium, które agent obsługiwał sam
Agent sterował maszynami przez libvirt, czyli standardową warstwę do zarządzania wirtualizacją. Przygotowywał maszyny wirtualne, tworzył i przywracał migawki ich stanu, uruchamiał testy i zbierał artefakty. Pod koniec badań laboratorium liczyło 40 maszyn CHR, czyli wirtualnych wydań RouterOS, i 39 migawek. Obejmowało 24 wydania systemu, od 6.43.11 do 7.25beta3. CERT dodaje zdanie, które warto przeczytać dwa razy: “Narzędzia wykonujące te czynności wytworzył i obsługiwał LLM, zastępując pracę wykonywaną wcześniej ręcznie.”
To najbardziej namacalna korzyść z całego opisu. Przywracanie routera do znanego stanu przed każdym eksperymentem jest nudne i łatwo je pominąć. Właśnie od niego zależy jednak, czy wynik da się powtórzyć.
Pliki systemu i porównywanie wersji
Agent prowadził też statyczną analizę plików binarnych wyciągniętych z systemu RouterOS, przy użyciu narzędzi radare2 i Ghidra. Wyniki zestawiał z dokumentacją protokołów, przede wszystkim z dokumentami RFC, które opisują, jak SSH ma działać. Porównanie kolejnych wydań pozwalało ustalić, w której wersji błąd się pojawił i w której zniknął.
Protokół jako maszyna stanów
Według CERT modele szczególnie dobrze sprawdziły się w analizie protokołów jako maszyn stanów. Logowanie przez SSH przechodzi przez kolejne etapy w ustalonej kolejności, a modele systematycznie sprawdzały, co się stanie, gdy ją zaburzyć. Testowały powtarzanie etapów, pomijanie komunikatów, zmianę ich kolejności i przedwczesne otwieranie kanałów. Jeden z takich testów obejmował rekey przed zakończeniem uwierzytelniania i doprowadził do wykrycia nieprawidłowego przejścia stanu. Opis pasuje do luki CVE-2026-67279, choć CERT nie łączy tych dwóch fragmentów wprost.
Monitoring po wydaniu poprawek
Po publikacji łatek agenci LLM śledzili forum MikroTika, Reddita i inne publiczne źródła. Pomagali zespołowi wychwytywać doniesienia o atakach i próby odtworzenia exploita.
Najbardziej czasochłonne etapy
Według CERT najwięcej czasu wymagały cztery rzeczy: przygotowanie kontekstu, czyli precyzyjnych informacji dla agenta, przygotowanie laboratorium, rozstrzyganie niejednoznacznych wyników oraz walidacja na rzeczywistych wersjach RouterOS. Analiza nie mówi, kto je wykonywał. Wprost przypisuje zespołowi dopiero decyzję o potwierdzeniu. Lukę zespół uznawał za potwierdzoną dopiero po powtarzalnych wynikach, testach negatywnych, analizie artefaktów i porównaniu kilku wersji systemu.
Drugą połowę łańcucha, CVE-2026-86060, CERT zidentyfikował w ciągu godziny od zestawienia dwóch źródeł. Pierwszym były logi publikowane przez administratorów na forum MikroTika i Reddicie. Widniało w nich nieudane logowanie użytkownika -2 i utworzenie konta ops w tej samej sesji. Drugim była analiza różnic między starą a poprawioną wersją systemu. Analiza mówi o tym w pierwszej osobie liczby mnogiej i nie określa, jaki udział miał w tym agent.
Od łatki do odtworzenia luki minęło kilkadziesiąt godzin
Najciekawszy wniosek z analizy dotyczy tempa, w jakim szczegóły luki stały się publiczne. Kolejność zdarzeń według CERT wyglądała tak:
- 2 września: najwcześniejsze publicznie dostępne logi ataków, jeszcze sprzed poprawek,
- 3 września: MikroTik wydaje poprawki, wcześniej, niż CERT się spodziewał,
- 4 września, 3:22 UTC: ukazuje się publiczna analiza różnic w pakietach, której autor opisał swoją pracę jako wspartą przez AI i sprawdzoną w laboratorium,
- do 5 września: nazwę
-2publicznie powiązano z programem logowania, - 5 września, 20:00 UTC: CERT zaczyna publikować rekordy CVE,
- 10 września: CVE-2026-67277 i CVE-2026-86060 trafiają do katalogu aktywnie wykorzystywanych luk prowadzonego przez CISA, z trzydniowym terminem na usunięcie,
- 25 września: CISA dopisuje do katalogu CVE-2026-67279, którą według agencji można połączyć z CVE-2026-86060 w atak bez logowania.
CERT podsumowuje to zdaniem: “Szybkość analizy poprawek przy wykorzystaniu LLM zaciera różnicę między wydaniem aktualizacji a publikacją technicznych szczegółów podatności.” Obrona nie przyspieszyła w tym samym tempie. Tańsza analiza kodu nie skróciła czasu potrzebnego na przetestowanie i wdrożenie aktualizacji ani na szukanie śladów włamania. Administratorzy pisali na forum MikroTika, że część urządzeń wymaga fizycznego dostępu albo okna serwisowego. Zgłoszenia problemów po aktualizacji wymuszały z kolei testy i plan wycofania zmian.
CERT nie wyciąga z tego wniosku, że łatki należy opóźniać. Oczekuje za to od producentów, że razem z aktualizacją dostarczą opis powierzchni ataku i sposoby ograniczenia ryzyka, a także wskaźniki włamania i reguły wykrywania. MikroTik 3 września tymczasowo nie ujawnił szczegółów luk. W poprawce dodał jednak regułę, która przy starcie wyłącza konto ops z pełnymi uprawnieniami. Według CERT tak konkretny wskaźnik mógł oznaczać, że producent miał przynajmniej częściową wiedzę o atakach.
Co z tego wynika dla firmy z routerem MikroTik w sieci
Administrator, który jeszcze nie sprawdził swoich urządzeń, ma do zrobienia to samo, co zalecaliśmy na początku września. Trzeba sprawdzić wersję systemu i trzy wskaźniki. Są to wpisy o nieudanym logowaniu użytkownika -2, konto ops z pełnymi uprawnieniami oraz połączenia z adresu 82.192.72.4. Nowa analiza dokłada czwarty trop z polskiego podwórka. Logi z forum trzepak.pl pokazywały utworzenie pliku diagnostycznego RIF i wysłanie danych poleceniem fetch na ten sam adres. CERT uznaje to z wysokim prawdopodobieństwem za wyprowadzenie danych.
Firma powinna z tej historii wziąć jedną liczbę do planowania. Kluczowe elementy luki odtworzono publicznie w ciągu kilkudziesięciu godzin od poprawki. W tym samym czasie trzeba więc umieć otworzyć okno serwisowe dla urządzeń brzegowych. Miesięczny cykl aktualizacji przestaje tu wystarczać. Plan wycofania i lista urządzeń wymagających fizycznego dostępu powinny istnieć, zanim przyjdzie kolejna pilna łatka.
Zespoły, które same budują agenty AI, dostają od CERT rzadki opis z praktyki. Agent przejął wiele czynności wykonywanych wcześniej ręcznie. Najwięcej czasu wymagały jednak kontekst, laboratorium, rozstrzyganie niejednoznacznych wyników i walidacja. Agenci AI z dostępem do narzędzi pojawiają się też po stronie atakujących. Pokazują to złośliwy program sterowany przez cztery modele AI i raport o agentach AI używanych do włamań.
Agenci AI · Kodożercy
Twoje przepływy w n8n mogą podejmować decyzje
Kurs Agenci AI od Kodożerców pokazuje, jak dołożyć do n8n warstwę, która czyta dokumenty, dobiera kolejny krok i pyta o zgodę, zanim zrobi coś nieodwracalnego. Budujesz to na własnych integracjach, moduł po module.
Sprawdź, jak to zbudować →
Najczęstsze pytania
Czy polski model PLLuM pomógł znaleźć luki w MikroTiku?
Tego analiza CERT nie mówi. PLLuM pojawia się w niej raz, na liście modeli o otwartych wagach uruchamianych przez CERT na własnej infrastrukturze. Stoi tam obok GLM, DeepSeeka i Qwena. Tekst nie przypisuje żadnemu modelowi konkretnego ustalenia. Nie da się więc uczciwie powiedzieć, że którykolwiek z nich, polski czy amerykański, znalazł lukę.
Czy aktualizacja MikroTika usuwa konto dodane przez atakującego?
Nie usuwa, tylko wyłącza. Według CERT poprawka dodała regułę, która przy uruchomieniu wykrywa konto ops w grupie full. System wyłącza wtedy to konto, zapisuje ostrzeżenie i ustawia status Flagged. CERT nie podaje, żeby aktualizacja cofała jakiekolwiek inne zmiany. Dlatego po jej instalacji trzeba przejrzeć konta i konfigurację.
Podsumowanie
Najcenniejszy w analizie CERT jest szczegółowy opis pracy agenta. Agent obsługiwał laboratorium z 40 maszynami, analizował pliki systemu, porównywał wersje i systematycznie testował logowanie SSH. Jeden z tych testów doprowadził do wykrycia nieprawidłowego przejścia stanu. Najwięcej czasu wymagały jednak przygotowanie kontekstu i laboratorium, rozstrzyganie niejednoznacznych wyników oraz walidacja na prawdziwych wersjach RouterOS. Zespół uznawał lukę za potwierdzoną dopiero po powtarzalnych wynikach i testach negatywnych. Z modeli korzystają też inni: publiczną analizę poprawki, opisaną przez autora jako wspartą przez AI, opublikowano dzień po łatce. Dla firm z MikroTikami wniosek jest praktyczny. Liczą się wersja systemu, trzy wskaźniki z logów i okno serwisowe, które da się otworzyć w ciągu doby lub dwóch od wydania krytycznej łatki.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
