Rozpylenie, nie techniczny przełom

Firma bezpieczeństwa Huntress ujawniła kampanię password spraying, która trwała od 12 do 26 czerwca 2026 roku i osiągnęła szczyt 22 czerwca. W ciągu tych dwóch tygodni na konta Microsoft 365 skierowano ponad 81 milionów prób logowania. Ruch wychodził z zakresu IPv6 zarejestrowanego na jednego operatora, a napastnicy wcale nie zgadywali haseł na ślepo. Odtwarzali pary nazwy użytkownika i hasła zebrane z wcześniejszych, zupełnie niepowiązanych wycieków, licząc na to, że ludzie używają tych samych danych logowania w kolejnych usługach. Z tej fali wyszło 78 przejętych kont w 64 organizacjach.

Uwagę zwraca brak czegokolwiek egzotycznego. Nie było luki zero-day, nie było pomysłowego złośliwego oprogramowania, nie było sztuczki w łańcuchu dostaw. Był wolumen, ponownie użyte dane logowania i jedna słaba ścieżka uwierzytelniania. Taki zestaw jest w zasięgu każdego przeciętnego napastnika i właśnie dlatego zasługuje na uwagę właściciela. Technika jest tania, można ją powtarzać bez końca i uderza w warstwę tożsamości, którą większość firm uważa za zabezpieczoną uwierzytelnianiem wieloskładnikowym.

Jak logowania przeszły obok MFA

Mechanizmem była stara ścieżka logowania. Napastnicy uwierzytelniali się przez narzędzia wiersza poleceń Azure, korzystając z przepływu Resource Owner Password Credentials, znanego jako ROPC. To starsza metoda OAuth, która przyjmuje nazwę użytkownika i hasło bezpośrednio i w wielu dzierżawach w ogóle nie wywołuje monitu wieloskładnikowego. Tam, gdzie dzierżawa miała MFA włączone, ale wąsko zakreślone, ponownie użyte dane logowania przeszły prosto przez lukę. Huntress raz po raz znajdował te same błędy konfiguracji: MFA stosowane tylko do wybranych aplikacji, MFA wymuszane tylko dla grup administratorów, MFA wymagane tylko z niezaufanych lokalizacji oraz zasady Conditional Access pozostawione w trybie wyłącznie raportowania, w którym rejestrują zdarzenia, ale nigdy nie blokują.

Mniej oczywista nauka jest taka, że MFA to nie przełącznik, lecz mapa pokrycia. Dzierżawa może przejść audyt, który pyta jedynie o to, czy MFA istnieje, i mimo to zostawić stare drzwi bez zamka. Napastnicy nie pokonali uwierzytelniania wieloskładnikowego. Znaleźli te logowania, przy których nikt o nie nie prosił. W tej różnicy mieści się cała historia i pozostaje ona niewidoczna, dopóki ktoś nie sprawdzi, które ścieżki uwierzytelniania dzierżawa wciąż dopuszcza.

Pół godziny, które zamyka lukę

Problem konfiguracji ma odpowiedź w konfiguracji, a większość tej pracy to krótka sesja administracyjna, nie zakup. Zablokuj stare uwierzytelnianie i wyłącz przepływ ROPC, aby logowania nazwą użytkownika i hasłem, które pomijają MFA, były po prostu odrzucane. Wymuś uwierzytelnianie wieloskładnikowe w każdej aplikacji i przy każdym logowaniu, a nie tylko na kontach administratorów czy przy niezaufanych lokalizacjach, i przestaw Conditional Access z trybu wyłącznie raportowania na aktywne blokowanie. Następnie przejrzyj dzienniki logowań pod kątem wzorca nieudanego rozpylenia i zresetuj każde dane logowania, które mógł ujawnić wcześniejszy wyciek.

Dla europejskiej firmy jest jeszcze jeden powód, by działać szybko. Jeśli ponownie użyte dane logowania otworzą skrzynkę pocztową z danymi osobowymi, incydent może uruchomić obowiązek zgłoszenia na gruncie RODO w ciągu 72 godzin, a cicha luka w tożsamości staje się wtedy zdarzeniem podlegającym zgłoszeniu i rozmową z organem nadzorczym. Zamknięcie drzwi kosztuje popołudnie konfiguracji. Pozostawienie ich otwartych płaci się obowiązkami informacyjnymi i utraconym zaufaniem. Traktuj warstwę tożsamości jako to, czym się stała, czyli jako perymetr.

Czytaj dalej: Audyt AI przeoczył lukę Linuksa, która daje roota  |  29-letni błąd Squida ujawnia loginy w postaci jawnej