Nadużycie SSPR w Microsoft 365 i Azure posłużyło do kradzieży danych z chmury

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

Mechanizm Self-Service Password Reset, czyli SSPR, w Microsoft Entra ID ma ułatwiać użytkownikom samodzielne odzyskiwanie dostępu do konta. Najnowsze ustalenia pokazują jednak, że funkcja zaprojektowana z myślą o wygodzie i ciągłości działania może zostać wykorzystana jako element zaawansowanego ataku na środowiska Microsoft 365 i Azure.

W analizowanej kampanii napastnicy nie koncentrowali się na klasycznym wdrażaniu złośliwego oprogramowania. Zamiast tego przejmowali tożsamości użytkowników, utrzymywali dostęp do kont uprzywilejowanych i wykorzystywali natywne mechanizmy administracyjne platformy do eksfiltracji danych z usług SaaS, PaaS i IaaS.

W skrócie

Atak wykorzystywał socjotechnikę oraz proces resetu hasła SSPR do przejmowania kont.
Ofiary były nakłaniane do akceptowania żądań MFA podszywających się pod działania wsparcia IT.
Po przejęciu dostępu napastnicy usuwali istniejące metody MFA i rejestrowali własne urządzenia w Microsoft Authenticator.
Kolejnym etapem było rozpoznanie Entra ID, pobieranie danych z OneDrive i SharePoint oraz rozszerzenie działań na zasoby Azure.
Celem operacji była długotrwała kontrola nad środowiskiem i systematyczna kradzież danych o wysokiej wartości biznesowej.

Kontekst / historia

Opisany scenariusz dobrze wpisuje się w szerszy trend ataków opartych na kompromitacji tożsamości, a nie pojedynczych stacji roboczych. W nowoczesnych środowiskach chmurowych przejęcie jednego konta z odpowiednimi uprawnieniami może otworzyć dostęp do wielu warstw organizacji bez konieczności wykorzystywania tradycyjnych podatności systemowych.

Kampania przypisywana grupie śledzonej jako Storm-2949 pokazuje, że konta personelu IT oraz kadry kierowniczej pozostają szczególnie atrakcyjnym celem. Po skutecznym przejęciu tożsamości napastnicy mogli mapować środowisko, identyfikować wrażliwe zasoby i przechodzić z usług Microsoft 365 do elementów Azure odpowiedzialnych za aplikacje produkcyjne, dane i zaplecze administracyjne.

Analiza techniczna

Łańcuch ataku rozpoczynał się od uruchomienia procedury SSPR wobec wybranej ofiary. Następnie operatorzy kontaktowali się z użytkownikiem, podszywając się pod dział wsparcia technicznego i przekonując go do zatwierdzenia żądań MFA. Po zaakceptowaniu promptów możliwe było zresetowanie hasła, usunięcie istniejących metod uwierzytelniania wieloskładnikowego oraz dodanie nowej rejestracji Microsoft Authenticator kontrolowanej przez atakującego.

Po przejęciu konta napastnicy prowadzili szczegółowe rozpoznanie katalogu Entra ID przy użyciu Microsoft Graph API oraz własnych skryptów. Celem było ustalenie, które konta, role, aplikacje i service principal mogą posłużyć do dalszej eskalacji uprawnień, utrzymania dostępu i rozszerzenia zasięgu operacji.

W dalszej fazie analizowano zasoby OneDrive i SharePoint w poszukiwaniu dokumentacji operacyjnej, danych projektowych, konfiguracji dostępu zdalnego oraz informacji przydatnych do kolejnych etapów ataku. W co najmniej jednym przypadku doszło do masowego pobrania tysięcy plików za pośrednictwem interfejsu webowego OneDrive.

Po stronie Azure kluczową rolę odegrały konta posiadające uprzywilejowane role RBAC w wielu subskrypcjach. Dzięki temu napastnicy mogli wykonywać operacje zarządcze wobec usług takich jak App Service, Key Vault, Azure Storage, Azure SQL Server oraz maszyny wirtualne. Szczególnie istotne było użycie operacji publishxml w Azure App Service, pozwalającej pobrać profil publikacji z poświadczeniami umożliwiającymi dalszy dostęp do aplikacji i ich środowiska wykonawczego.

Gdy bezpośredni dostęp do głównego celu był utrudniony, atakujący koncentrowali się na Azure Key Vault. Po uzyskaniu odpowiednich uprawnień modyfikowali konfigurację dostępu i pobierali sekrety, w tym connection stringi oraz dane uwierzytelniające, które następnie wykorzystywano do uzyskania dostępu do bardziej wrażliwych usług produkcyjnych.

Równolegle modyfikowano reguły zapory Azure SQL Server, dopuszczając połączenia z infrastruktury kontrolowanej przez napastników. W obszarze Azure Storage zmieniano ustawienia sieciowe i pozyskiwano klucze kont oraz tokeny SAS, co pozwalało zautomatyzować pobieranie dużych wolumenów danych z blob storage.

W warstwie IaaS nadużywano funkcji VMAccess i Run Command. Umożliwiało to tworzenie nowych lokalnych kont administracyjnych, zdalne uruchamianie skryptów, rozpoznanie środowiska, pozyskiwanie poświadczeń, próby pobrania tokenów z usługi metadanych instancji oraz instalację narzędzi do zdalnej kontroli. Obserwowano także działania zmierzające do osłabienia zabezpieczeń oraz usuwania artefaktów śledczych, takich jak logi czy historia poleceń.

Konsekwencje / ryzyko

Największe zagrożenie polega na tym, że wiele działań napastników opiera się na legalnych funkcjach chmurowych i skompromitowanych tożsamościach. W praktyce aktywność może przypominać zwykłe operacje administracyjne, co utrudnia wykrycie incydentu, zwłaszcza jeśli organizacja nie koreluje logów z obszaru tożsamości, usług chmurowych i endpointów.

Ryzyko obejmuje jednocześnie utratę poufności, integralności i kontroli operacyjnej. Przejęcie kont uprzywilejowanych pozwala zmieniać konfigurację zabezpieczeń i utrzymywać trwały dostęp. Kompromitacja Key Vault może prowadzić do wtórnego przejęcia aplikacji, baz danych i usług zaplecza. Z kolei dostęp do dokumentacji operacyjnej i ustawień łączności może stworzyć pomost między chmurą a infrastrukturą lokalną.

Rekomendacje

Podstawą ochrony powinno być wzmocnienie warstwy tożsamości. Organizacje powinny wymuszać MFA dla wszystkich użytkowników, a dla administratorów i ról uprzywilejowanych stosować metody odporne na phishing. Ważne jest również wcześniejsze rejestrowanie kontrolowanych metod MFA dla kont o wysokim poziomie uprawnień, aby utrudnić złośliwe dodanie nowego urządzenia po przejęciu procesu resetu hasła.

Niezbędne pozostaje wdrożenie Conditional Access z politykami uwzględniającymi poziom ryzyka, zgodność urządzenia, zaufane lokalizacje i siłę uwierzytelniania. W Entra ID oraz Azure trzeba rygorystycznie stosować zasadę najmniejszych uprawnień, regularnie przeglądać role RBAC i ograniczać dostęp do operacji zarządczych wysokiego ryzyka.

Po stronie Azure szczególne znaczenie ma monitorowanie zdarzeń control plane. Dotyczy to między innymi zmian reguł firewall, pobierania kluczy storage, modyfikacji dostępu do Key Vault, użycia profili publikacji App Service, tworzenia lokalnych administratorów na maszynach wirtualnych oraz wykonywania poleceń przez Run Command. Warto także ograniczać publiczny dostęp do usług, stosować private endpoints, utrzymywać dłuższą retencję logów oraz rozważać mechanizmy niezmienności danych tam, gdzie jest to uzasadnione.

Z perspektywy zespołów SOC kluczowa jest korelacja sygnałów z obszaru tożsamości, aplikacji SaaS, zasobów Azure i stacji końcowych. Alarmujące powinny być nietypowe resety haseł, ponowna rejestracja MFA, masowe pobrania z OneDrive i SharePoint, nagłe zmiany konfiguracji sieciowej, pobrania sekretów z Key Vault, użycie narzędzi zdalnego dostępu oraz próby wyłączania mechanizmów ochronnych.

Nie można również pomijać czynnika ludzkiego. Personel IT oraz kadra zarządzająca powinni być regularnie szkoleni w zakresie scenariuszy socjotechnicznych, w których rzekome wsparcie techniczne prosi o zatwierdzenie promptów MFA lub wykonanie pilnych działań na koncie.

Podsumowanie

Kampania przypisywana Storm-2949 pokazuje, że skuteczny atak na Microsoft 365 i Azure nie musi opierać się na zaawansowanych exploitach. Wystarczy przejęcie tożsamości, nadużycie legalnych mechanizmów administracyjnych i umiejętne wykorzystanie przydzielonych uprawnień do poruszania się po środowisku.

Nadużycie SSPR, przejęcie MFA, wykorzystanie RBAC, dostępu do Key Vault, App Service, SQL, Storage i funkcji zarządzania maszynami wirtualnymi tworzy spójny model ataku nastawiony na długotrwały dostęp oraz eksfiltrację danych. Dla obrońców najważniejsze pozostają twarde zabezpieczenie tożsamości, ścisła kontrola uprawnień i pełna widoczność operacji administracyjnych w chmurze.