Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa alarmują o rosnącym wykorzystaniu techniki OAuth Client ID Spoofing w środowisku Microsoft Entra ID. Metoda ta pozwala atakującym prowadzić cichą enumerację kont użytkowników oraz wyciągać wnioski o poprawności poświadczeń bez konieczności korzystania z legalnie zarejestrowanej aplikacji OAuth.
Z perspektywy obrony jest to szczególnie niebezpieczne, ponieważ aktywność może być słabiej widoczna w logach i trudniejsza do wykrycia przez zespoły SOC. W praktyce oznacza to, że organizacja może nie zauważyć etapu rekonesansu lub wstępnej walidacji danych logowania aż do momentu dalszej eskalacji incydentu.
W skrócie
Istota ataku polega na podszywaniu się pod identyfikator klienta OAuth przekazywany w parametrze client_id podczas żądań uwierzytelniających. Dzięki różnicom w odpowiedziach usługi napastnik może rozróżnić, czy dane konto istnieje, czy hasło jest błędne, a w wybranych scenariuszach także czy login i hasło są poprawne.
- atak nie wymaga użycia prawidłowej aplikacji OAuth,
- telemetria może nie wskazywać nazwy aplikacji,
- klasyczne detekcje oparte na analizie ruchu per aplikacja tracą skuteczność,
- technika była obserwowana w kampaniach o dużej skali przeciw organizacjom korzystającym z Entra ID.
Kontekst / historia
Microsoft Entra ID od lat pozostaje jednym z głównych celów dla operatorów prowadzących rekonesans, password spraying oraz działania związane z uzyskaniem dostępu początkowego do środowisk chmurowych. Dotychczas napastnicy często wykorzystywali znane aplikacje pierwszej strony albo publiczne narzędzia, co zwiększało szansę ich wykrycia dzięki analizie logów logowania i korelacji zdarzeń.
Obecnie obserwowany trend pokazuje zmianę taktyki. Zamiast opierać operacje na jednym łatwo rozpoznawalnym identyfikatorze aplikacji, atakujący rozpraszają ruch pomiędzy ogromną liczbę fałszywych identyfikatorów klienta. Taki model utrudnia łączenie zdarzeń w jedną kampanię i obniża skuteczność prostych mechanizmów analitycznych.
Analiza techniczna
Mechanizm nadużycia opiera się na zachowaniu endpointu OAuth 2.0 podczas żądań kierowanych z parametrem client_id. Napastnik wysyła żądania do endpointu tokenowego, najczęściej wykorzystując przepływ Resource Owner Password Credentials, przekazując nazwę użytkownika, hasło oraz spreparowany identyfikator klienta.
Kluczowe znaczenie mają różnice w odpowiedziach serwera. Jeśli użytkownik nie istnieje, usługa może zwrócić komunikat wskazujący brak konta. Jeśli konto istnieje, ale hasło jest błędne, zwracany jest inny kod błędu. Jeżeli natomiast para login-hasło jest poprawna, lecz podany client_id nie odpowiada prawidłowej aplikacji, pojawia się błąd związany z nierozpoznanym identyfikatorem aplikacji. To właśnie ten wzorzec umożliwia inferencję stanu konta i poprawności poświadczeń bez klasycznego sukcesu logowania.
Istotny problem dotyczy także telemetrii. Gdy client_id jest poprawnie sformatowany, ale nie należy do realnej aplikacji, logi mogą zawierać sam identyfikator bez nazwy aplikacji. W efekcie detekcje zależne od pola nazwy aplikacji stają się mniej użyteczne. W bardziej zaawansowanych wariantach stosowane są nawet losowe identyfikatory UUID v4 generowane niemal dla każdego żądania, co dodatkowo utrudnia korelację.
W opisywanych kampaniach zaobserwowano dwa odmienne wzorce operacyjne. W jednym z nich zmieniano końcową część znanego identyfikatora aplikacji i rozkładano ruch na ponad 700 tysięcy spoofowanych identyfikatorów, obejmując ponad milion unikalnych kont w blisko 4 tysiącach tenantów. W drugim wariancie skala była jeszcze większa: użyto około 3,7 miliona spoofowanych identyfikatorów i wycelowano w ponad 2 miliony użytkowników.
Dodatkowym problemem jest możliwość obchodzenia części polityk Conditional Access, jeśli zostały one zaprojektowane głównie wokół konkretnych aplikacji. Fałszywy identyfikator klienta może nie uruchamiać takich kontroli w oczekiwany sposób, przez co zabezpieczenia nie zawsze zadziałają zgodnie z założeniami architektów bezpieczeństwa.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko polega na tym, że organizacja może błędnie ocenić charakter zdarzeń. To, co wygląda jak seria nieudanych prób logowania lub nietypowych błędów aplikacyjnych, w rzeczywistości może oznaczać skuteczną enumerację użytkowników albo nawet potwierdzenie poprawnych par login-hasło.
Osłabieniu ulega także monitoring oparty na trendach per aplikacja. Puste pole nazwy aplikacji, rozproszenie ruchu i stale zmieniające się identyfikatory klienta rozbijają obraz incydentu na wiele pozornie niezależnych sygnałów. W środowiskach o dużej skali może to prowadzić do obniżenia priorytetu alertów lub całkowitego przeoczenia kampanii.
- wyższe ryzyko przejęcia kont,
- możliwość nadużyć w usługach Microsoft 365 i aplikacjach SaaS,
- większe prawdopodobieństwo ruchu bocznego w środowisku chmurowym,
- potencjalne blokady kont i zakłócenia operacyjne dla użytkowników.
Rekomendacje
Organizacje korzystające z Microsoft Entra ID powinny rozszerzyć scenariusze detekcyjne o analizę logów logowania pod kątem brakującej nazwy aplikacji oraz nietypowych lub nierozpoznanych identyfikatorów aplikacji. Szczególną uwagę warto zwrócić na zdarzenia oznaczone kodem AADSTS700016, ponieważ w tym kontekście mogą one wskazywać nie tylko na nieudaną próbę dostępu, ale również na użycie poprawnych poświadczeń z fałszywym client_id.
Zespół SOC powinien korelować takie zdarzenia z szerszym kontekstem operacyjnym:
- dużą liczbą prób wobec wielu użytkowników,
- nietypowymi agentami użytkownika,
- wysoką rotacją adresów IP i wykorzystaniem infrastruktury proxy,
- masowymi próbami wobec kont o przewidywalnych schematach nazewniczych.
Równolegle warto ograniczać skutki wykorzystania skradzionych haseł poprzez konsekwentne egzekwowanie MFA, wdrażanie odpornych na phishing metod uwierzytelniania oraz monitoring anomalii tożsamościowych. Polityki Conditional Access nie powinny opierać się wyłącznie na wybranych aplikacjach, ale także na kontekście użytkownika, urządzenia, ryzyku sesji i źródle logowania.
Od strony hardeningu zalecane jest również:
- strojenie alertów dla uwierzytelnień bez nazwy aplikacji,
- budowa reguł wykrywających masowe użycie unikalnych
client_id, - analiza blokad kont jako potencjalnego skutku enumeracji lub password sprayingu,
- weryfikacja, czy logi Entra trafiają do SIEM z pełnym zestawem pól wymaganych do korelacji,
- testowanie detekcji przeciw technikom obchodzącym monitorowanie per aplikacja.
Podsumowanie
OAuth Client ID Spoofing w Microsoft Entra ID to technika, która łączy prostotę wykonania z wysoką skutecznością operacyjną. Umożliwia cichą enumerację użytkowników, rozpoznawanie poprawności haseł i jednoczesne ograniczanie widoczności działań w logach.
Skala zaobserwowanych kampanii sugeruje, że nie jest to jednorazowy eksperyment, lecz rozwijający się element arsenału wykorzystywanego przeciw środowiskom tożsamościowym w chmurze. Dla obrońców oznacza to konieczność aktualizacji reguł detekcyjnych, reinterpretacji wybranych kodów błędów oraz większego nacisku na monitoring anomalii związanych z tożsamością.
Źródła
- Cybersecurity Dive — Hackers find a new trick to collect Microsoft Entra user data without raising red flags — https://www.cybersecuritydive.com/news/microsoft-entra-user-enumeration-bypass-proofpoint/825052/
- Proofpoint — OAuth Client ID Spoofing: Why Fake Client IDs Are Gaining Traction for Stealthy Enumeration — https://www.proofpoint.com/us/blog/threat-insight/oauth-client-id-spoofing-why-fake-client-ids-are-gaining-traction-stealthy