Cyberprzestępcy przeprowadzili zakrojoną na szeroką skalę, w pełni zautomatyzowaną kampanię typu password spray, wymierzoną w środowiska Microsoft 365 za pośrednictwem interfejsu wiersza poleceń Azure (Azure CLI). W ciągu zaledwie dwóch tygodni napastnicy wygenerowali ponad 81 milionów prób logowania i przejęli co najmniej 78 kont użytkowników w 64 organizacjach. Na kampanię jako pierwsza zwróciła uwagę firma Huntress, zajmująca się cyberbezpieczeństwem — i to właśnie szczegółowy raport zespołu Huntress jest głównym źródłem opisanych poniżej ustaleń.
Najbardziej niepokojący nie jest jednak sam rozmach ataku. Jest nim fakt, że wiele zaatakowanych organizacji miało włączone uwierzytelnianie wieloskładnikowe (MFA) i polityki dostępu warunkowego — a mimo to zostały przejęte. Poniżej wyjaśniamy, jak to możliwe, i co konkretnie zrobić, żeby nie powtórzyć błędów ofiar.
Password spraying to technika ataku na konta użytkowników, w której napastnik próbuje jednego lub kilku bardzo popularnych haseł na wielu różnych kontach — zamiast zgadywać wiele haseł dla jednego konta. To odwrócenie klasycznego ataku siłowego (brute force) ma kluczową zaletę z perspektywy atakującego: pozwala uniknąć blokad kont, które zwykle uruchamiają się po kilku nieudanych próbach logowania na to samo konto. Rozkładając próby "cienką warstwą" na tysiące kont, napastnik dłużej pozostaje niezauważony.
W tej konkretnej kampanii, jak podkreśla Huntress, atak niemal w całości opierał się na tzw. combo lists — listach loginów i haseł wykradzionych we wcześniejszych wyciekach. Innymi słowy, przestępcy nie zgadywali haseł, lecz sprawdzali, które ze skradzionych wcześniej par login–hasło wciąż działają, bo nigdy nie zostały zmienione.
Huntress obserwował aktywność wśród kont swoich klientów w oknie od 12 do 26 czerwca 2026 roku. W ciągu tych 14 dni odnotowano ponad 81 milionów prób logowania. Przebieg ataku miał wyraźną dynamikę:
Według Huntress zdecydowana większość prób logowania pochodziła z systemu autonomicznego AS32167, powiązanego z dostawcą infrastruktury internetowej LSHIY LLC. Co istotne, dobór celów nie był związany z branżą ani wielkością firmy — decydowała wyłącznie obecność danych logowania na listach skompromitowanych haseł.
To nie jest odosobniony incydent. Huntress zaznacza, że opisywana kampania jest częścią znacznie szerszej fali ataków typu credential spray, prowadzonych z wielu różnych numerów AS. W ciągu ostatnich sześciu miesięcy firma odnotowała ponad 155-krotny wzrost liczby takich ataków wśród swoich klientów, przy średniej rzędu blisko 2 000 nieudanych prób logowania miesięcznie na pojedynczego chronionego klienta.
Azure CLI to wieloplatformowe narzędzie wiersza poleceń służące do zarządzania zasobami chmury Azure — administratorzy używają go do obsługi maszyn wirtualnych, wdrażania aplikacji, zarządzania bazami danych czy automatyzacji operacji chmurowych. Dla atakujących jest to jednak wyjątkowo atrakcyjny punkt wejścia z dwóch powodów.
Po pierwsze, logowania przez Azure CLI pojawiają się w dziennikach jako aktywność aplikacji "Microsoft Azure CLI" i często nie wzbudzają takiej czujności, jak logowania przez przeglądarkę. Po drugie — i to jest sedno sprawy — Azure CLI obsługuje przestarzały mechanizm uwierzytelniania, który potrafi całkowicie ominąć nowoczesne zabezpieczenia. Mowa o OAuth ROPC.
W ramach kampanii napastnicy wykorzystywali mechanizm OAuth ROPC (Resource Owner Password Credentials) do weryfikowania poprawności danych logowania. Mechanizm ten działa w sposób prosty i niebezpieczny zarazem: przesyła login i hasło bezpośrednio do punktu końcowego tokenów (/token), a w zamian — jeśli dane są poprawne — natychmiast wydaje token dostępowy użytkownika. Bez interaktywnego kroku, bez monitu, bez pytania o drugi składnik.
ROPC został wycofany w standardzie OAuth 2.1 i sam Microsoft otwarcie odradza jego stosowanie. W oficjalnej dokumentacji platformy tożsamości Microsoft czytamy wprost, że przepływ ten jest niekompatybilny z uwierzytelnianiem wieloskładnikowym i wymaga bardzo wysokiego poziomu zaufania do aplikacji, niosąc ze sobą ryzyka nieobecne w innych metodach.
Problem polega na tym, że polityki dostępu warunkowego (Conditional Access) egzekwują MFA na etapie autoryzacji. Tymczasem ROPC uderza prosto w punkt tokenów, omijając ten etap. Jak ujmuje to Huntress: ROPC przesyła hasło bezpośrednio do punktu końcowego, bez wyświetlenia użytkownikowi jakiegokolwiek monitu o potwierdzenie MFA. Efekt? Prawidłowy login i hasło wystarczą, by uzyskać token — nawet jeśli organizacja "ma MFA".
To najważniejsza lekcja z tej kampanii. Analizując skok z 22 czerwca, który dotknął 23 firmy, Huntress ustalił, że aż 15 z nich miało wdrożone i wymuszone MFA poprzez politykę dostępu warunkowego. Firmy te były przekonane, że są chronione — a jednak MFA "nie odpaliło". Dlaczego?Powtarzały się te same błędy konfiguracji:
Osobna grupa ofiar to organizacje, które nie miały żadnej polityki MFA — takich firm w tej kampanii było osiem.
Huntress stawia sprawę jasno: fakt, że napastnicy potrafili obejść MFA tam, gdzie było ono wdrożone, absolutnie nie oznacza, że MFA jest nieskuteczne. Wniosek jest inny — polityki MFA muszą być celowo skonfigurowane tak, aby obejmowały wszystkie ścieżki uwierzytelniania, których faktycznie używa atakujący, łącznie ze starszymi przepływami w rodzaju ROPC, omijającymi standardowe, interaktywne monity. Polityka, która chroni logowania przez przeglądarkę, ale zostawia otwarte tylne drzwi dla starszych protokołów, daje jedynie złudne poczucie bezpieczeństwa.
Zakres adresów IPv6, z którego prowadzono ataki (2a0a:d683::/32), należy do LSHIY — dostawcy infrastruktury internetowej. Rejestracja firmy wiąże ją z adresami w Hongkongu i Wuhan (Chiny), a także ze współdzieloną przestrzenią biurową pod adresem 42 Broadway w Nowym Jorku — układem, który skutecznie zaciemnia rzeczywistą strukturę właścicielską. Część adresów IP tego zakresu rozwiązuje się do Stanów Zjednoczonych, część do Chin, a inne raporty wskazują na chińskie źródło zakresów IPv6 powiązanych z numerami AS obsługiwanymi przez tę firmę.
Huntress zgłosił złośliwą aktywność do LSHIY za pośrednictwem firmowego systemu zgłaszania nadużyć (abuse reporting), lecz początkowo nie otrzymał żadnej odpowiedzi.
W przeciwieństwie do samej diagnozy, obrona przed tego typu atakiem jest w dużej mierze kwestią poprawnej konfiguracji. Oto najważniejsze działania, które warto wykonać jeszcze w tym tygodniu:
Warto też spojrzeć na własne środowisko oczami napastnika. Zanim luki w politykach dostępu warunkowego znajdzie ktoś o złych intencjach, znajdź je sam — w ramach autoryzowanego, kontrolowanego testu. Wynajmij hakera (etycznego pentestera lub zespół red team), który przeprowadzi symulowany atak typu password spray z wykorzystaniem ROPC na Twój tenant Microsoft 365 i sprawdzi, czy MFA rzeczywiście "odpala" tam, gdzie powinno. Testy penetracyjne i ćwiczenia red team to standardowa, legalna praktyka, która pozwala zweryfikować konfigurację w boju, zamiast zakładać, że "włączone" znaczy "chroniące". Do symulacji zachowania polityk dostępu warunkowego przydaje się również wbudowane w Entra ID narzędzie "What If".
Jest i dobra wiadomość. Jak wynika z późniejszej aktualizacji raportu (z 2 lipca), ataki ustały po tym, jak LSHIY zakończył świadczenie usług użytkownikom odpowiedzialnym za wskazany zakres adresów IP. Reakcja dostawcy infrastruktury okazała się więc skuteczniejsza niż milczenie na zgłoszenia nadużyć — choć zajęła trochę czasu.
Ta kampania to nie wyjątek, lecz zapowiedź trendu. 155-krotny wzrost liczby ataków credential spray w ciągu pół roku pokazuje, że tego typu działania przyspieszają, a nie wygasają. Podobne techniki obserwowano już wobec narzędzi wiersza poleceń AWS i Google Cloud — w miarę jak coraz więcej organizacji przenosi się do chmury, a deweloperzy chętniej sięgają po CLI zamiast portali graficznych, powierzchnia ataku będzie rosła.
Najtrwalszy wniosek jest zaskakująco prozaiczny: bezpieczeństwo tożsamości rzadko upada z powodu wyrafinowanego, przełomowego exploita. Znacznie częściej zawodzą przewidywalne hasła, starsze protokoły omijające MFA oraz polityki, które istnieją "na papierze", ale nie obejmują ścieżek faktycznie wykorzystywanych przez napastników. MFA warto traktować nie jak przełącznik do jednorazowego włączenia, lecz jak dyscyplinę wymagającą regularnego audytu i testowania.