Nadużycie Microsoft Entra ID uderza w klientów MSP i podważa łańcuch zaufania

securitybeztabu.pl 9 godzin temu

Wprowadzenie do problemu / definicja

Ataki na tożsamość chmurową coraz częściej omijają klasyczny phishing wymierzony w użytkowników końcowych i koncentrują się na relacjach zaufania między dostawcami usług zarządzanych, aplikacjami wielodostępnymi oraz tenantami klientów. Najnowszy incydent związany z Microsoft Entra ID pokazuje, iż przejęcie poświadczeń aplikacyjnych lub nadużycie uprzywilejowanego obiektu usługi może otworzyć drogę do wielu środowisk jednocześnie.

W praktyce oznacza to ryzyko ataku łańcucha dostaw w warstwie IAM, gdzie pojedynczy punkt kompromitacji może przełożyć się na szeroki zasięg operacyjny. To szczególnie groźne w modelu MSP, w którym jeden partner technologiczny obsługuje wiele organizacji i posiada dostęp do ich środowisk Microsoft 365 oraz Azure.

W skrócie

W opisywanym przypadku napastnik wykorzystał mechanizmy uwierzytelniania i delegowanego dostępu w Microsoft Entra ID, aby uzyskać dostęp do organizacji powiązanych z dostawcami MSP. Skala incydentu objęła 27 organizacji, w tym klientów końcowych obsługiwanych przez partnerów technologicznych z sektorów takich jak energetyka, administracja, transport, budownictwo oraz żywność i rolnictwo.

Charakter ataku wskazuje na wykorzystanie zaufanych integracji oraz poświadczeń aplikacyjnych, co znacząco utrudnia detekcję. Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia uwagi z samych kont użytkowników także na tożsamości usługowe, aplikacje enterprise i proces nadawania zgód administracyjnych.

Kontekst / historia

Microsoft Entra ID stał się centralnym komponentem zarządzania tożsamością w środowiskach Microsoft 365 i Azure. Wraz z rozwojem aplikacji SaaS, integracji partnerskich i modeli zarządzania wieloma tenantami wzrosło znaczenie obiektów typu service principal, rejestracji aplikacji oraz sekretów i certyfikatów używanych do bezobsługowej autoryzacji.

Środowiska MSP są szczególnie narażone na tego typu zagrożenia, ponieważ z definicji operują na relacjach uprzywilejowanego dostępu do wielu klientów. Gdy atakujący przejmie poświadczenia aplikacji wykorzystywanej przez dostawcę lub nadużyje wcześniej nadanych zgód administracyjnych, może użyć tego samego kanału dostępu do poruszania się między tenantami.

To przesuwa ciężar obrony z pojedynczych kont użytkowników na cały model zarządzania tożsamością usługową, cyklem życia sekretów oraz kontrolą uprawnień aplikacyjnych. W nowoczesnych środowiskach chmurowych to właśnie aplikacje działające w tle coraz częściej stają się najcenniejszym celem dla napastników.

Analiza techniczna

Technicznie incydent wpisuje się w kategorię ataków na workload identities i zaufane aplikacje w Entra ID. Zamiast logować się jako użytkownik, napastnik korzysta z poświadczeń aplikacyjnych lub tokenów uzyskanych dla zarejestrowanej aplikacji. Taki dostęp może umożliwiać pobieranie tokenów do Microsoft Graph, odczyt zasobów Microsoft 365, wykonywanie rekonesansu katalogowego, modyfikację uprawnień aplikacji oraz ustanowienie trwałości.

W analizowanym scenariuszu szczególnie niebezpieczny jest element downstream access, czyli dostęp do klientów obsługiwanych przez MSP. o ile aplikacja partnera posiada już autoryzację w tenantach klientów, przejęcie jej poświadczeń pozwala ominąć wiele tradycyjnych barier bezpieczeństwa. Z perspektywy logów aktywność może wyglądać jak legalna komunikacja aplikacji z usługami Microsoft, a nie klasyczne logowanie z nieznanego urządzenia.

Dodatkowym problemem jest możliwość budowania persistence. o ile po uzyskaniu dostępu napastnik doda nowe credentials do istniejących aplikacji albo przyzna im wyższe role, organizacja może utracić kontrolę choćby po rotacji pierwotnie skompromitowanego sekretu. W środowiskach z rozbudowaną federacją i wieloma aplikacjami enterprise ryzyko pozostawienia ukrytego mechanizmu powrotu jest wysokie.

Z punktu widzenia telemetryki najważniejsze artefakty obejmują:

logi logowań service principal,
użycie Microsoft Graph przez aplikacje partnerskie,
tworzenie lub modyfikację sekretów klienta i certyfikatów,
zmiany ról katalogowych,
nietypowe zgody administracyjne i rozszerzenie zakresów uprawnień,
aktywność z nowych adresów IP lub nietypowych lokalizacji dla workload identity,
masowe operacje odczytu na SharePoint, Exchange Online i Teams.

Konsekwencje / ryzyko

Ryzyko takiego incydentu jest wysokie z kilku powodów. Po pierwsze, naruszenie jednego dostawcy lub jednej aplikacji może objąć wiele niezależnych organizacji. Po drugie, uprawnienia aplikacyjne bywają bardzo szerokie i często wykraczają poza zasadę najmniejszych uprawnień. Po trzecie, organizacje zwykle mają słabszą widoczność w obszarze tożsamości usługowych niż w przypadku kont interaktywnych.

Skutki praktyczne mogą obejmować nieautoryzowany dostęp do poczty i dokumentów, eksfiltrację danych z Microsoft 365, mapowanie relacji administracyjnych i struktury tenantu, nadużycie integracji backupowych lub zarządczych, eskalację do ról o wysokim poziomie uprzywilejowania oraz trwałe osadzenie się napastnika w środowisku.

Dla MSP konsekwencją jest również kryzys zaufania operacyjnego. Klienci oczekują, iż partner zarządzający środowiskiem będzie kontrolował nie tylko konta administratorów, ale również bezpieczeństwo aplikacji, sekretów, certyfikatów i zgód administracyjnych. Właśnie te obszary stają się dziś jednym z najczęściej wykorzystywanych wektorów ataku w chmurze.

Rekomendacje

Organizacje korzystające z usług MSP oraz integracji Entra ID powinny wdrożyć działania defensywne zarówno natychmiastowe, jak i długofalowe.

Przeprowadzić pełny przegląd wszystkich aplikacji enterprise i app registrations, ze szczególnym uwzględnieniem aplikacji partnerów oraz uprawnień typu application.
Zweryfikować poświadczenia workload identities i sprawdzić, czy w ostatnim czasie nie dodano nowych client secrets, certyfikatów lub federated credentials.
Ograniczyć nadmierne uprawnienia aplikacyjne zgodnie z zasadą najmniejszych uprawnień.
Monitorować sign-in logs dla service principals pod kątem nietypowych lokalizacji, godzin aktywności i wzorców masowego pobierania danych.
Włączyć polityki ochrony dla tożsamości usługowych tam, gdzie jest to możliwe, w tym ograniczenia adresów źródłowych i separację uprawnień między klientami.
Po incydencie rotować sekrety i certyfikaty partnerów oraz odwołać zaufanie do wszystkich powiązanych integracji przed ich ponownym ustanowieniem.
Przeanalizować audyt Microsoft Graph i aktywność w Exchange Online, SharePoint Online, OneDrive oraz Teams, aby ustalić faktyczny zakres dostępu.
Oddzielić administrację MSP od produkcyjnych tenantów klientów poprzez segmentację modeli zarządzania, dedykowane aplikacje per klient i eliminację współdzielonych poświadczeń.

Podsumowanie

Incydent związany z Microsoft Entra ID i klientami MSP potwierdza, iż bezpieczeństwo chmury nie kończy się na MFA dla użytkowników. Coraz większe znaczenie mają aplikacje, service principals, sekrety i relacje zaufania między organizacjami. Atakujący wykorzystują fakt, iż integracje partnerskie posiadają rozległe uprawnienia i działają w tle, często poza głównym polem widzenia zespołów SOC.

Dla obrońców najważniejszy wniosek jest prosty: tożsamości usługowe należy traktować jak konta uprzywilejowane najwyższego ryzyka. Bez pełnej widoczności nad aplikacjami Entra ID, bez rotacji poświadczeń i bez ścisłej kontroli uprawnień model downstream access może stać się jednym z najbardziej kosztownych wektorów ataku w nowoczesnym środowisku Microsoft 365.