Rozpylenie, nie przełom techniczny

Firma bezpieczeństwa Huntress ujawniła kampanię password spraying, która trwała od 12 do 26 czerwca 2026 roku, z apogeum 22 czerwca, w której ponad 81 milionów prób logowania skierowano na konta Microsoft 365. Ruch pochodził z zakresu IPv6 zarejestrowanego na jednego operatora, a napastnicy nie zgadywali haseł na ślepo. Odtwarzali pary nazwy użytkownika i hasła zebrane z wcześniejszych, niepowiązanych wycieków, zakładając, że ludzie używają tych samych danych logowania w różnych usługach. Z tej fali przejęto 78 kont w 64 organizacjach.

Godny uwagi jest brak czegokolwiek egzotycznego. Nie było dnia zerowego, sprytnego złośliwego oprogramowania ani sztuczki w łańcuchu dostaw. To był wolumen plus ponownie użyte dane logowania plus jedna słaba ścieżka uwierzytelniania. Ta kombinacja jest w zasięgu każdego przeciętnego napastnika i właśnie dlatego zasługuje na uwagę właściciela: technika jest tania, powtarzalna i wymierzona w warstwę tożsamości, którą większość firm uważa za już zabezpieczoną uwierzytelnianiem wieloskładnikowym.

Jak logowania przeszły obok MFA

Mechanizmem była stara ścieżka logowania. Napastnicy uwierzytelniali się przez narzędzia wiersza polecen Azure, używając przepływu Resource Owner Password Credentials, znanego jako ROPC, starszej metody OAuth, która przyjmuje nazwę użytkownika i hasło bezpośrednio i w wielu dzierżawcach w ogóle nie wyzwala monitu wieloskładnikowego. Tam, gdzie dzierżawca miał MFA włączone, ale wąsko ograniczone, ponownie użyte dane logowania przechodziły prosto przez lukę. Huntress raz po raz znajdował te same błędne konfiguracje: 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 tylko raport, gdzie rejestrują, ale nigdy nie blokują.

Mniej oczywista nauka jest taka, że MFA to nie przełącznik, lecz mapa pokrycia. Dzierżawca może przejść audyt, który pyta, czy MFA istnieje, a mimo to zostawić stare drzwi otwarte. Napastnicy nie pokonali uwierzytelniania wieloskładnikowego; znaleźli te logowania, przy których nigdy o nie nie proszono. Ta różnica to cała historia i pozostaje niewidoczna, dopóki ktoś nie sprawdzi, które ścieżki uwierzytelniania dzierżawca wciąż dopuszcza.

Pół godziny, które zamyka lukę

To problem konfiguracji z odpowiedzią w konfiguracji, a większość z tego to krótka sesja administracyjna, a 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 na każdej aplikacji i każdym logowaniu, a nie tylko na kontach administratorów czy niezaufanych lokalizacjach, i przenieś Conditional Access z trybu tylko raport do aktywnego blokowania. Następnie sprawdź dzienniki logowań pod kątem wzorca nieudanego rozpylenia i zresetuj każde dane logowania, które wcześniejszy wyciek mógł ujawnić.

Dla europejskiej firmy istnieje drugi powód, by działać szybko. Jeśli ponownie użyte dane logowania otworzą skrzynkę pocztową zawierającą dane osobowe, incydent może uruchomić obowiązek zgłoszenia w ramach RODO w ciągu 72 godzin, tak że cicha luka tożsamości może stać się zdarzeniem podlegającym zgłoszeniu i rozmową z UODO. Europejski standard zaleca dokładnie tę higienę konfiguracji. Koszt zamknięcia drzwi to popołudnie konfiguracji; koszt pozostawienia ich otwartymi mierzy się w obowiązkach ujawnienia i utraconym zaufaniu. Traktuj warstwę tożsamości jako perymetr, którym się stała.

Czytaj dalej: Twój edytor AI może uruchomić cudzy kod  |  Twoj dostawca to drzwi dla ransomware