Masowy password spraying na Azure CLI doprowadził do przejęcia co najmniej 78 kont Microsoft

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Password spraying to technika ataku polegająca na sprawdzaniu niewielkiej puli popularnych haseł wobec dużej liczby kont. W przeciwieństwie do klasycznego brute force celem nie jest intensywne zgadywanie wielu haseł dla jednego użytkownika, lecz rozproszenie prób tak, aby ograniczyć ryzyko blokady kont i utrudnić wykrycie. Najnowsza kampania wymierzona w środowiska Microsoft pokazuje, że taka metoda pozostaje bardzo skuteczna, zwłaszcza gdy organizacje nadal utrzymują aktywne konta z hasłami pochodzącymi z dawnych wycieków.

W opisywanym przypadku atakujący wykorzystali Azure CLI oraz starszy przepływ OAuth 2.0 Resource Owner Password Credentials (ROPC). To podejście pozwoliło ominąć część źle wdrożonych mechanizmów ochronnych, w tym nieprecyzyjnie skonfigurowane zasady MFA i Conditional Access.

W skrócie

Między 12 a 26 czerwca 2026 roku zaobserwowano zakrojoną na szeroką skalę kampanię password spray wymierzoną w konta Microsoft. W jej trakcie wykonano ponad 81 milionów prób logowania, a skutkiem było przejęcie co najmniej 78 kont należących do użytkowników z 64 organizacji.

Atak opierał się na masowym testowaniu popularnych haseł.
Wykorzystano Azure CLI jako wektor logowania.
Kluczową rolę odegrał starszy przepływ ROPC, uznawany za ryzykowny.
Część organizacji miała MFA i Conditional Access, ale wdrożone niekompletnie.
Incydent pokazał, że sama obecność polityk ochronnych nie gwarantuje bezpieczeństwa.

Kontekst / historia

Ataki password spraying od lat należą do najczęściej spotykanych metod uzyskiwania dostępu do kont tożsamościowych w usługach chmurowych. Ich skuteczność wynika z połączenia automatyzacji, dużej skali oraz wykorzystania poświadczeń znanych z wcześniejszych naruszeń danych. Zamiast szukać jednej podatności technicznej, napastnicy wykorzystują słabości organizacyjne: brak rotacji haseł, ponowne używanie tych samych sekretów i niepełne wdrożenie nowoczesnych mechanizmów uwierzytelniania.

W tej kampanii ofiary nie były ograniczone do jednej branży, co sugeruje oportunistyczny model działania. Atakujący wybierali cele na podstawie użyteczności kont i prawdopodobieństwa trafienia w poprawną kombinację loginu oraz hasła. Szczególnie niepokojące jest to, że część zaatakowanych podmiotów miała aktywne mechanizmy MFA oraz Conditional Access, ale ich zakres nie obejmował wszystkich scenariuszy logowania.

Analiza techniczna

Sercem operacji było wykorzystanie przepływu Resource Owner Password Credentials. W tym modelu aplikacja przekazuje nazwę użytkownika i hasło bezpośrednio do serwera autoryzacji w celu uzyskania tokenu dostępu. Rozwiązanie to od dawna uznawane jest za przestarzałe i ryzykowne, ponieważ nie współgra dobrze z nowoczesnym egzekwowaniem MFA oraz zakłada bezpośrednie operowanie hasłem przez klienta.

Atak przebiegał według klasycznego schematu credential attack. Operator kampanii wykonywał rozproszone, zautomatyzowane próby logowania z użyciem znanych nazw użytkowników oraz ograniczonej listy najczęściej stosowanych haseł. Po trafieniu poprawnej kombinacji możliwe było uzyskanie dostępu przez ścieżkę nieuwzględnioną lub niewłaściwie zabezpieczoną przez zasady Conditional Access.

Z technicznego punktu widzenia nie był to przykład pojedynczej krytycznej podatności w usłudze Microsoft, lecz efekt połączenia kilku czynników:

istnienia starych, nadal aktywnych haseł,
dostępności starszego przepływu ROPC,
niespójnego egzekwowania MFA i Conditional Access,
wysokiego poziomu automatyzacji po stronie atakującego.

Skala operacji, obejmująca ponad 81 milionów prób logowania w ciągu kilkunastu dni, wskazuje na dobrze przygotowaną infrastrukturę do rozproszenia ruchu i utrzymywania stałego tempa ataku. Dla zespołów bezpieczeństwa oznacza to, że wykrywanie pojedynczych nieudanych logowań nie wystarcza. Kluczowe staje się korelowanie zdarzeń na poziomie tenantu, aplikacji, typu klienta i wykorzystywanego przepływu autoryzacji.

Konsekwencje / ryzyko

Najbardziej oczywistym skutkiem takiej kampanii jest przejęcie tożsamości użytkownika. W zależności od uprawnień ofiary może to oznaczać dostęp do poczty, plików, aplikacji biznesowych, zasobów chmurowych, a nawet paneli administracyjnych. Nawet konta nieuprzywilejowane mogą posłużyć do dalszego rozpoznania środowiska, eskalacji uprawnień, ruchu bocznego lub prowadzenia skuteczniejszych ataków phishingowych.

Ryzyko rośnie szczególnie tam, gdzie użytkownicy stosują te same hasła w wielu usługach albo nie przeprowadzono rotacji poświadczeń po wcześniejszych wyciekach. Incydent pokazuje również, że organizacje mogą mieć fałszywe poczucie bezpieczeństwa wynikające z samego faktu włączenia MFA. Jeżeli polityki nie obejmują wszystkich aplikacji i wszystkich ścieżek logowania, napastnik wybierze tę najsłabiej chronioną.

Z operacyjnego punktu widzenia skutki incydentu obejmują również konieczność przeglądu logów uwierzytelnienia, resetów haseł, unieważniania aktywnych tokenów oraz sprawdzenia, czy przejęte konta nie zostały użyte do utrwalenia dostępu. W większych środowiskach Microsoft 365 i Entra ID może to oznaczać szeroki audyt konfiguracji dostępu warunkowego oraz starszych metod logowania.

Rekomendacje

Organizacje powinny potraktować ten incydent jako sygnał do pilnego przeglądu całego modelu uwierzytelniania. W pierwszej kolejności warto zidentyfikować procesy, skrypty i integracje nadal korzystające z przepływu ROPC, a następnie zaplanować ich migrację do nowocześniejszych mechanizmów wspierających silne uwierzytelnianie i właściwe egzekwowanie polityk bezpieczeństwa.

Ograniczyć lub całkowicie wyłączyć użycie ROPC tam, gdzie to możliwe.
Zweryfikować, czy Conditional Access obejmuje wszystkich użytkowników, wszystkie aplikacje chmurowe i wszystkie odpowiednie typy klientów.
Sprawdzić, czy Azure CLI podlega tym samym wymaganiom bezpieczeństwa co standardowe logowania interaktywne.
Wymusić rotację haseł dla kont narażonych na wykorzystanie danych z historycznych wycieków.
Blokować słabe i popularne hasła oraz stosować ochronę przed użyciem kompromitowanych poświadczeń.
Monitorować logowania pod kątem prób ROPC, anomalii związanych z Azure CLI i nagłych wzrostów błędnych logowań wobec wielu użytkowników.
Ograniczyć użycie Azure CLI do administratorów lub wybranych grup, jeśli model operacyjny na to pozwala.
Po incydencie przeglądać i unieważniać aktywne tokeny oraz szukać oznak utrwalenia dostępu.
Wdrażać odporne na phishing metody MFA zamiast polegać wyłącznie na podstawowych mechanizmach drugiego składnika.

Dla zespołów SOC i IAM istotne jest także budowanie detekcji opartych nie tylko na sukcesie logowania, ale również na rodzaju przepływu autoryzacji, identyfikatorze aplikacji, geolokalizacji źródeł ruchu oraz korelacji rozproszonych prób wobec wielu kont jednocześnie.

Podsumowanie

Masowa kampania password spraying przeciwko środowiskom Microsoft udowadnia, że zagrożenia tożsamościowe nadal opierają się przede wszystkim na połączeniu automatyzacji, słabych lub historycznie ujawnionych haseł oraz luk w konfiguracji polityk bezpieczeństwa. Przejęcie co najmniej 78 kont po ponad 81 milionach prób logowania nie wynikało z nowej krytycznej luki, lecz z praktycznego obejścia ochrony dzięki starszemu przepływowi OAuth i niepełnemu egzekwowaniu MFA.

Dla organizacji korzystających z Microsoft 365, Entra ID i Azure CLI najważniejsza lekcja jest jasna: samo włączenie mechanizmów ochronnych nie wystarcza. Konieczne są regularne przeglądy starszych metod uwierzytelniania, walidacja polityk Conditional Access i stały monitoring nietypowych wzorców logowania.