Niebezpieczna luka w Microsoft Entra ID: Jak ominięto MFA i polityki dostępu warunkowego

22 czerwca 2026 roku badacz Thomas Byrne z firmy NetSPI ujawnił publicznie podatność w mechanizmie Nested App Authentication (NAA) (znanym również jako BroCI) w Microsoft Entra ID. Luka umożliwiała atakującym całkowite ominięcie dowolnych zasad dostępu warunkowego, w tym wymogu uwierzytelniania wieloskładnikowego (MFA), kontroli zgodności urządzeń i ograniczeń lokalizacyjnych . Microsoft załatał podatność po stronie serwera, klasyfikując ją jako średnio-poważną. Jej ujawnienie zbiegło się w czasie z publikacją drugiej, odrębnej metody ataku oraz serią zmian w politykach bezpieczeństwa Microsoftu.

Jak działała podatność?

Nested App Authentication to autorski mechanizm logowania jednokrotnego (SSO) Microsoftu, zaprojektowany, aby aplikacja „nadrzędna”, np. portal Azure Portal, mogła w tle zarządzać tokenami dla zagnieżdżonych aplikacji podrzędnych bez ponownego wyświetlania monitu użytkownikowi . Mechanizm ten działa poprzez wstawianie specjalnych parametrów (brk_client_id, brk_redirect_uri) do standardowych żądań tokenów OAuth kierowanych do login.microsoftonline.com .

Byrne odkrył, że w tym mechanizmie istniała krytyczna luka. Dotyczyła ona szczególnie przepływów, w których komponent ADIbizaUX (odpowiedzialny za zarządzanie tożsamością i dostępem w portalu Azure) przekazywał zapisany w pamięci podręcznej token odświeżania portalu Azure Portal w celu żądania tokena dostępu do Microsoft Graph API . Standardowo wymiana tokenów odświeżania podlega ocenie zasad dostępu warunkowego. NetSPI odkrył jednak, że w przypadku przepływu NAA z użyciem ADIbizaUX i zasobu Microsoft Graph, zasady dostępu warunkowego nie były w ogóle oceniane . Token dostępu był wydawany niezależnie od skonfigurowanych polityk. Dodatkowo stwierdzono, że ten sam problem występował w przypadku dwóch identyfikatorów klienta rozszerzenia portalu Microsoft Intune .

Scenariusz ataku

Atak wymaga spełnienia konkretnego warunku wstępnego – posiadania skradzionego tokena odświeżania portalu Azure Portal – ale jest bardzo skuteczny jako technika utrzymania dostępu i ruchu bocznego w sieci . Scenariusz ataku składa się z czterech kroków:

1. Początkowe naruszenie: Atakujący najpierw kradnie ważny token odświeżania Azure Portal, na przykład poprzez phishing, ataki typu adversary-in-the-middle (AITM) na login.microsoftonline.com lub inne metody kradzieży tokenów .
2. Brokerowanie tokenów przez NAA: Atakujący używa skradzionego tokena odświeżania Azure Portal i mechanizmu brokerowania NAA (poprzez ADIbizaUX lub rozszerzenia portalu Intune) do cichej wymiany go na token dostępu Microsoft Graph .
3. Ominięcie wszystkich kontroli: Token Graph jest wydawany bez żadnej oceny zasad dostępu warunkowego – bez monitu MFA, bez sprawdzania zgodności urządzenia, bez ograniczeń lokalizacyjnych – nawet jeśli te polityki są jawnie skonfigurowane .
4. Utrzymanie dostępu i ruch boczny: ADIbizaUX posiada szerokie, wstępnie wyrażone uprawnienia do Graph API i udostępnia nieudokumentowane interfejsy API do zarządzania użytkownikami, grupami, jednostkami usługi, aplikacjami, katalogami, a nawet samymi zasadami dostępu warunkowego – wszystko to bez żadnego logowania, co oznacza, że działania pozostają całkowicie niewykryte .

Ograniczenia podatności:

• Skradziony token odświeżania Azure Portal ma stały 24-godzinny czas życia i nie może być odnowiony, co ogranicza okno czasowe na utrzymanie dostępu .
• Atakujący musi już posiadać token odświeżania ofiary, co czyni tę technikę metodą eskalacji uprawnień i utrzymania dostępu po naruszeniu, a nie zdalnym wykonaniem kodu .

Mimo to, firma Microsoft sklasyfikowała podatność jako średnio-poważną .

Reakcja Microsoftu

• Zgłoszenie: NetSPI zgłosił problem do Microsoft Security Response Center (MSRC) 17 marca 2026 .
• Klasyfikacja i łatka: MSRC uznał podatność za średnio-poważną i wdrożył poprawkę po stronie serwera. Testy po jej zastosowaniu potwierdziły, że wcześniej skuteczne przepływy NAA zwracają teraz błąd AADSTS53003, blokujący dostęp w momencie zastosowania zasad dostępu warunkowego .
• Poprawka: Microsoft nie przypisał tej konkretnej podatności numeru CVE. Poprawka została wdrożona po stronie serwera i nie wymagała żadnych działań ze strony klienta .

Szerszy kontekst: Dwie luki w dostępie warunkowym ujawnione tego samego dnia

22 czerwca 2026 roku badacze ujawnili dwie oddzielne metody ominięcia dostępu warunkowego Entra ID :

Odkrycie	Źródło	Mechanizm	Reakcja Microsoftu
Ominięcie NAA / BroCI	NetSPI (Thomas Byrne)	Nadużycie mechanizmu Nested App Authentication do brokerowania tokenów przez ADIbizaUX i rozszerzenia portalu Intune	Poprawka MSRC o średnim priorytecie; teraz zwraca błąd AADSTS53003
Ominięcie poprzez wykluczenie zasobu	Dirk-jan Molenaar (dirkjanm.io)	Polityki celujące w „Wszystkie zasoby” z przynajmniej jednym wykluczonym zasobem mogły być pomijane dla tokenów Graph używających tylko podstawowych zakresów OIDC/katalogu	Microsoft potwierdził i rozpoczął wdrażanie egzekwowania zakresów bazowych od 15 czerwca 2026; wcześniejsza opcja dostępna w panelu administracyjnym Entra

Kluczowe zmiany w egzekwowaniu zasad dostępu warunkowego Microsoftu w 2026 roku

Oprócz naprawienia luki NAA, Microsoft w 2026 roku stopniowo zamyka luki w egzekwowaniu dostępu warunkowego:

• 27 marca 2026 – czerwiec 2026 (etapowo): Microsoft zmienił sposób egzekwowania polityk CA celujących w „Wszystkie zasoby”, gdy polityki te zawierają wykluczenia zasobów. Wcześniej logowania żądające tylko podstawowych zakresów OIDC (takich jak openid, profile, User.Read) mogły całkowicie ominąć dostęp warunkowy, jeśli polityka miała jakiekolwiek wykluczenie zasobu. Zmiana zapewnia, że polityki z wykluczeniami są nadal oceniane w zakresie „Wszystkie zasoby” .
• 15 czerwca 2026: Microsoft rozpoczął egzekwowanie zakresów bazowych specjalnie dla metody ominięcia przez wykluczenie zasobów, zamykając drogę do ominięcia tokenów Graph ujawnioną przez Dirk-jana Molenaara .
• 31 marca 2026: Microsoft wycofał uwierzytelnianie bez jednostki usługi dla aplikacji wielodostępowych nienależących do Microsoftu. Wszystkie aplikacje muszą teraz uwierzytelniać się przy użyciu zarejestrowanej jednostki usługi; w przeciwnym razie logowanie zakończy się niepowodzeniem .
• Czerwiec 2026: Microsoft ogłosił szersze aktualizacje bezpieczeństwa Entra ID, w tym zastąpienie kontrolek niestandardowych zewnętrznym MFA, konsekwentne egzekwowanie dostępu warunkowego podczas rejestracji poświadczeń oraz wymóg jawnie zarejestrowanych metod uwierzytelniania dla samoobsługowego resetowania hasła (SSPR) .

Kluczowe wnioski dla administratorów

• Luka NAA została naprawiona po stronie serwera. Nie są wymagane żadne działania po stronie dzierżawy dla konkretnego odkrycia NetSPI .
• W przypadku luki związanej z wykluczeniem zasobów, włącz opcję egzekwowania zakresów bazowych w panelu administracyjnym Entra, aby zapewnić prawidłową ocenę CA .
• Monitoruj kod błędu AADSTS53003 – oznacza on teraz prawidłowe blokowanie nieautoryzowanych wymian tokenów NAA .
• Nieudokumentowane interfejsy API ADIbizaUX, które mogą działać bez logowania, pozostają zagrożeniem – organizacje powinny uważnie monitorować dzienniki logowania do portalu Azure Portal i wzorce wydawania tokenów .
• Po wycofaniu uwierzytelniania bez jednostki usługi (31 marca 2026) upewnij się, że wszystkie aplikacje wielodostępowe mają zarejestrowane jednostki usługi .