Google Threat Intelligence Group (GTIG) opisał w raporcie z 11 maja 2026 r. zaobserwowany exploit zero-day, który obchodził uwierzytelnianie dwuskładnikowe (2FA) w narzędziu administracyjnym. Badacze z wysoką pewnością oceniają, że AI wspomogła znalezienie i opracowanie tego exploita. Dla firm z portalami administracyjnymi i rozbudowanymi ścieżkami MFA to sygnał, że przegląd bezpieczeństwa powinien testować także logikę logowania.

Zadajmy pytanie, na które wiele zespołów zna niewygodną odpowiedź: czy ktoś kiedykolwiek sprawdził, co się stanie, gdy użytkownik z poprawnym hasłem spróbuje dojść do panelu administracyjnego inną drogą niż ekran drugiego składnika? Raport z testów bywa listą klasycznych błędów kodu i nieaktualnych bibliotek. Rzadziej zawiera opis tego, jakie założenia o zaufaniu przyjęli autorzy procesu logowania i czy ktoś próbował je obalić. Przypadek opisany przez GTIG dotyczy właśnie tego obszaru. Według raportu exploit wymagał poprawnych danych logowania, a jego celem było ominięcie 2FA. Hasło było więc pierwszym zamkiem, a drugi zamek okazał się możliwy do obejścia. Jeśli firmowy model zagrożeń kończy się na zdaniu „mamy MFA”, ten opis pokazuje, gdzie w tym zdaniu brakuje testu.

Exploit GTIG zaczynał się od poprawnego hasła

Jak podaje GTIG, opisany exploit zero-day obchodził 2FA w narzędziu administracyjnym, a do jego użycia potrzebne były poprawne dane logowania. Ten warunek ma praktyczne znaczenie. Exploit nie łamał hasła; atakujący musiał je już mieć. Drugi składnik był więc jedyną przeszkodą, którą exploit miał pokonać.

Z perspektywy obrońcy oznacza to przesunięcie uwagi. Wyciek lub przejęcie hasła administratora wiele organizacji traktuje jako ryzyko ograniczone, bo „i tak jest MFA”. Opis GTIG pokazuje scenariusz, w którym to założenie przestaje chronić. Z przytoczonych faktów nie ustalimy nazwy narzędzia, szczegółów technicznych obejścia ani tego, ile organizacji dotknął ten exploit. Tych informacji nie dopowiadamy. Do oceny wystarczy sam mechanizm. Poprawne dane logowania plus obejście 2FA dają dostęp do narzędzia, które zwykle ma szerokie uprawnienia.

Drugi składnik chroni tylko wtedy, gdy każda droga do panelu rzeczywiście przez niego przechodzi.

Ocena roli AI pozostaje oceną badaczy

Drugi wątek raportu przyciąga więcej uwagi. Według GTIG badacze z wysoką pewnością ocenili, że AI wspomogła znalezienie i opracowanie exploita. Trzymajmy się dokładnie tego sformułowania. Jest to ocena analityków, nie bezpośredni zapis procesu tworzenia exploita. GTIG nie twierdzi w przytoczonym fragmencie, że exploit napisała AI bez udziału ludzi, ani nie podaje, jakiego narzędzia użyto.

Dla zarządu z tej oceny wynika jedno: wsparcie AI może skracać drogę od pomysłu do działającego obejścia zabezpieczenia. Jeden udokumentowany przypadek nie pozwala jednak mówić o trendzie ani szacować jego tempa. Uczciwa notatka dla zarządu powinna zawierać oba zdania obok siebie: GTIG z wysoką pewnością wiąże ten exploit ze wsparciem AI, a nie wiadomo, ile podobnych przypadków istnieje.

Czy zmiana narzędzi po stronie atakującego zmienia cokolwiek w samej obronie? Mniej, niż sugerują nagłówki. Exploit trafił w założenie dotyczące logiki uwierzytelniania, a takie założenia obrońca może testować bez względu na to, jakich narzędzi używa druga strona. Koszt poszukiwań po stronie obrońcy także da się obniżyć, jeśli wiadomo, czego szukać.

Procedura mówi „MFA wdrożone”, test powinien zapytać „jak”

W wielu organizacjach odpowiedź na pytanie o ochronę panelu administracyjnego mieści się w jednej kolumnie arkusza: MFA tak lub nie. Taka kolumna opisuje konfigurację. O zachowaniu aplikacji nie mówi wiele: nie wiadomo z niej, czy sesja po pierwszym kroku logowania daje już dostęp do części funkcji, czy istnieje alternatywna ścieżka logowania, na przykład dla integracji lub awaryjnego dostępu, ani czy ktoś te ścieżki sprawdził w teście.

Przypadek z raportu GTIG dotyczy narzędzia administracyjnego, czyli kategorii systemów, do których dostęp mają nieliczni, ale z szerokimi uprawnieniami. W modelu zagrożeń takie panele zasługują na osobny wiersz. Powinien on opisywać założenia zaufania wprost: który krok logowania uznajemy za wystarczający dowód tożsamości, co dzieje się, gdy drugi składnik zawiedzie, i kto potwierdził, że innej drogi nie ma.

Klasyczny przegląd kodu i skan podatności nie zawsze odpowiedzą na te pytania. Błąd logiki uwierzytelniania może nie wyglądać jak błąd w kodzie, bo każda linia robi to, co miała robić. Problem leży w kolejności kroków albo w założeniu, że użytkownik zawsze przejdzie wskazaną ścieżką. Dlatego do zakresu testów zamawianych u dostawcy lub zespołu wewnętrznego dopiszmy scenariusz z raportu: tester zna poprawne hasło i próbuje dojść do panelu bez drugiego składnika.

Kolumna „MFA: tak” w arkuszu opisuje wdrożenie; o tym, czy chroni, mówi dopiero test alternatywnych ścieżek logowania.

Polskie firmy powinny przetestować własne panele

Raport GTIG nie wskazuje polskich ofiar opisanego exploita. Nie ma więc podstaw, by przedstawiać ten przypadek jako zagrożenie wymierzone w polskie organizacje. Mechanizm nie zależy jednak od kraju. Firmowe panele administracyjne i ścieżki MFA działają w polskich spółkach tak samo jak gdzie indziej.

Zarząd nie musi wiedzieć, jakiego narzędzia dotyczył opisany przypadek, żeby zadać właściwe pytania. Wystarczy lista paneli administracyjnych dostępnych z sieci, informacja, kto odpowiada za każdy z nich, i data ostatniego testu logiki logowania. Jeśli przy którymś panelu ta data jest pusta, mamy gotowy punkt do planu testów. Jeżeli przy wszystkich, wiemy przynajmniej, od czego zacząć rozmowę z zespołem bezpieczeństwa.

Co z tym zrobić w poniedziałek

  1. Spisz panele administracyjne z MFA. W ciągu 30 minut zestaw listę narzędzi administracyjnych dostępnych dla pracowników lub dostawców wraz z właścicielem każdego z nich. Przy każdej pozycji zapisz, czy znana jest data ostatniego testu logiki logowania.
  2. Dopisz scenariusz „poprawne hasło, brak drugiego składnika”. Dodaj ten przypadek do zakresu najbliższego testu bezpieczeństwa jednego wybranego panelu. Poproś testera o sprawdzenie alternatywnych ścieżek logowania, w tym dostępu awaryjnego i integracji.
  3. Uzupełnij model zagrożeń o założenia zaufania. Dla jednego panelu zapisz wprost, który krok logowania organizacja uznaje za dowód tożsamości i kto to potwierdził. Brakujące informacje oznacz jako nieustalone i wskaż osobę odpowiedzialną za ich uzupełnienie.

Ocena GTIG o wsparciu AI przy tym exploicie przyciągnie uwagę, ale decyzja po stronie firmy dotyczy czegoś starszego niż AI: sprawdzania, czy logowanie działa tak, jak zakładamy. Przegląd, który kończy się na klasycznych błędach kodu, zostawia ten obszar bez testu. Panel administracyjny z MFA, którego nikt nie próbował obejść, ma zabezpieczenie jedynie zadeklarowane.

Źródła

Redakcja cyberinsight.pl.