Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Mechanizmy Self-Service Password Reset (SSPR) zostały zaprojektowane po to, aby użytkownicy mogli samodzielnie odzyskiwać dostęp do kont bez angażowania działów IT. Rozwiązanie to poprawia wygodę i skraca czas obsługi incydentów związanych z hasłami, ale jednocześnie staje się atrakcyjnym celem dla napastników, jeśli zostanie połączone z socjotechniką oraz przejęciem procesu uwierzytelniania wieloskładnikowego.
Opisana kampania pokazuje, że legalne funkcje platform Microsoft 365 i Azure mogą zostać wykorzystane jako element łańcucha ataku prowadzącego do przejęcia kont uprzywilejowanych, trwałego dostępu do środowiska i kradzieży danych z usług chmurowych oraz infrastruktury produkcyjnej.
W skrócie
Grupa śledzona jako Storm-2949 prowadziła ukierunkowane operacje przeciwko środowiskom Microsoft 365 i Azure, koncentrując się na pozyskiwaniu danych o wysokiej wartości. Atak rozpoczynał się od socjotechniki wymierzonej w użytkowników uprzywilejowanych, po czym wykorzystywano proces SSPR do resetu haseł, przejęcia kont i ponownej rejestracji metod MFA na urządzeniach kontrolowanych przez napastników.
Po uzyskaniu dostępu operatorzy przechodzili do rekonesansu w Entra ID, przeszukiwania OneDrive i SharePoint, a następnie rozszerzali działania na usługi Azure, w tym App Service, Key Vault, Storage, SQL i maszyny wirtualne. Celem nie była szybka destrukcja, lecz systematyczna eksfiltracja danych oraz utrzymanie dostępu w środowisku ofiary.
Kontekst / historia
Ataki na tożsamość od lat należą do najskuteczniejszych metod wejścia do organizacji, szczególnie w modelu chmurowym, gdzie pojedyncze konto administracyjne może zapewniać szeroki dostęp do aplikacji, danych i warstwy zarządzania. W tym przypadku szczególnie istotne jest to, że napastnicy nie polegali wyłącznie na złośliwym oprogramowaniu, lecz na nadużyciu natywnych mechanizmów administracyjnych oraz legalnych interfejsów API.
Taki model działania wpisuje się w rosnący trend wykorzystywania wbudowanych funkcji platform chmurowych. Dla zespołów bezpieczeństwa oznacza to trudniejsze wykrywanie incydentów, ponieważ część aktywności przeciwnika przypomina standardowe operacje administracyjne i może nie wzbudzać natychmiastowych alertów.
Analiza techniczna
Pierwszym etapem kampanii była socjotechnika skierowana do osób z podwyższonymi uprawnieniami, takich jak pracownicy IT czy kadra kierownicza. Napastnik inicjował proces SSPR dla wybranego użytkownika, a następnie kontaktował się z ofiarą, podszywając się pod wsparcie techniczne i nakłaniając ją do zatwierdzenia żądań MFA. W praktyce ofiara była przekonana, że uczestniczy w legalnej procedurze odzyskiwania dostępu.
Po skutecznym przejściu procesu resetu hasła atakujący mógł zmienić poświadczenia, usunąć dotychczasowe zabezpieczenia MFA i zarejestrować własną aplikację Microsoft Authenticator. Taki krok zapewniał trwałość dostępu i znacząco utrudniał szybkie odzyskanie kontroli nad kontem przez prawowitego użytkownika.
Kolejna faza obejmowała rekonesans środowiska z użyciem Microsoft Graph API oraz własnych skryptów. Operatorzy enumerowali użytkowników, role, aplikacje i service principals, aby ocenić zakres dostępu oraz zidentyfikować najbardziej wartościowe cele. Następnie przeszukiwali OneDrive i SharePoint w poszukiwaniu dokumentów operacyjnych, konfiguracji VPN i innych danych wspierających dalszy ruch boczny.
Po etapie SaaS atakujący rozszerzali działania na infrastrukturę Azure, korzystając ze skompromitowanych tożsamości posiadających rozległe uprawnienia RBAC. Dzięki temu mogli przejść do zasobów produkcyjnych i identyfikować kluczowe komponenty środowiska.
W przypadku Azure App Service wykorzystywano interfejsy zarządzania, takie jak FTP, Web Deploy oraz konsola Kudu. Pozwalało to na przeglądanie systemu plików aplikacji, odczyt zmiennych środowiskowych oraz wykonywanie poleceń w kontekście aplikacji, co jest szczególnie niebezpieczne w sytuacji, gdy przechowywane są tam sekrety, tokeny i parametry połączeń.
Następnie operatorzy przechodzili do Azure Key Vault, gdzie modyfikowali ustawienia dostępu i pozyskiwali sekrety, w tym dane uwierzytelniające do baz danych i connection stringi. Równolegle ingerowali w reguły sieciowe usług Azure SQL i kont Storage, pobierali klucze dostępu oraz tokeny SAS i automatyzowali proces wyprowadzania danych.
W warstwie IaaS nadużywano funkcji zarządzania maszynami wirtualnymi, takich jak VMAccess i Run Command. Umożliwiało to tworzenie nieautoryzowanych kont administracyjnych, zdalne uruchamianie skryptów oraz pozyskiwanie kolejnych poświadczeń. W końcowych etapach raportowano również instalację narzędzi zdalnego dostępu, próby osłabienia zabezpieczeń oraz działania zmierzające do utrudnienia analizy incydentu.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko w tego typu operacji polega na tym, że atak rozpoczyna się od pojedynczego procesu tożsamościowego, lecz bardzo szybko eskaluje do kompromitacji wielowarstwowej. Przejęcie jednego konta uprzywilejowanego może otworzyć drogę nie tylko do dokumentów w Microsoft 365, ale także do sekretów aplikacyjnych, baz danych, zasobów produkcyjnych i maszyn wirtualnych.
Dla organizacji oznacza to zagrożenie wyciekiem danych biznesowych, poświadczeń technicznych, konfiguracji sieciowych i materiałów umożliwiających kolejne włamania. Ujawnienie sekretów z Key Vault, kluczy do Storage czy connection stringów może skutkować wtórną kompromitacją systemów nawet po odzyskaniu przejętego konta użytkownika.
Dodatkowym problemem jest legalny charakter wykorzystywanych narzędzi i usług. Część aktywności napastnika wygląda jak standardowe działania administracyjne, przez co detekcja incydentu jest znacznie trudniejsza, a pełne ustalenie skali naruszenia może wymagać długotrwałej analizy logów i artefaktów śledczych.
Rekomendacje
Organizacje korzystające z Microsoft 365 i Azure powinny traktować procesy odzyskiwania dostępu do kont jako krytyczny element powierzchni ataku. Ochrona samych zasobów chmurowych nie wystarczy, jeśli przeciwnik może przejąć tożsamość uprzywilejowanego użytkownika i wykorzystać legalne mechanizmy administracyjne do rozszerzenia dostępu.
- Ograniczyć liczbę kont z wysokimi uprawnieniami i regularnie przeglądać przypisania RBAC.
- Stosować zasadę najmniejszych uprawnień w Entra ID i Azure.
- Wymusić silne, odporne na phishing metody MFA dla administratorów i kont uprzywilejowanych.
- Wdrożyć polityki Conditional Access dla operacji wysokiego ryzyka.
- Monitorować zdarzenia związane z resetem haseł, zmianą metod MFA i rejestracją nowych urządzeń uwierzytelniających.
- Analizować użycie Microsoft Graph API pod kątem nietypowej enumeracji użytkowników, ról i aplikacji.
- Przeglądać dostęp do OneDrive, SharePoint, App Service, Key Vault, Storage i SQL pod kątem anomalii oraz prób eksportu danych.
- Ograniczać publiczny dostęp do Key Vault i Storage oraz preferować prywatne punkty końcowe.
- Utrzymywać logi usług chmurowych przez odpowiednio długi okres na potrzeby dochodzeń.
- Alertować na zmiany reguł firewalli, generowanie tokenów SAS, pobieranie kluczy dostępu oraz użycie Run Command i VMAccess.
- Kontrolować instalację narzędzi zdalnego dostępu i próby wyłączania zabezpieczeń endpointów.
Z perspektywy SOC szczególnie wartościowe są scenariusze detekcyjne łączące zdarzenia tożsamościowe z aktywnością w usługach chmurowych. Sam reset hasła nie musi oznaczać incydentu, ale reset połączony z nową rejestracją MFA, wzrostem aktywności Graph API oraz nietypowym dostępem do Key Vault lub Storage powinien być traktowany jako silny wskaźnik kompromitacji.
Podsumowanie
Przypadek Storm-2949 pokazuje, że bezpieczeństwo środowisk chmurowych zależy nie tylko od ochrony zasobów, lecz przede wszystkim od odporności procesów tożsamościowych. Nadużycie SSPR w połączeniu z socjotechniką i przejęciem MFA umożliwiło płynne przejście od pojedynczego konta użytkownika do krytycznych zasobów Azure i Microsoft 365.
Dla organizacji to wyraźny sygnał, że konieczne jest równoczesne wzmacnianie obszarów IAM, monitoringu usług chmurowych oraz kontroli uprawnień administracyjnych. W praktyce to szybkie wykrywanie anomalii w procesach odzyskiwania dostępu i zmianach metod uwierzytelniania może zatrzymać incydent, zanim przerodzi się on w rozległą kradzież danych.
Źródła
- BleepingComputer – Microsoft Self-Service Password Reset abused in Azure data theft attacks — https://www.bleepingcomputer.com/news/security/microsoft-self-service-password-reset-abused-in-azure-data-theft-attacks/
- Microsoft Security Blog – How Storm-2949 turned a compromised identity into a cloud-wide breach — https://www.microsoft.com/en-us/security/blog/2026/05/18/storm-2949-turned-compromised-identity-into-cloud-wide-breach/