Badacze cyberbezpieczeństwa zidentyfikowali rosnącą technikę ataków w chmurze, znaną jako podszywanie się pod identyfikator klienta OAuth (OAuth client ID spoofing), która pozwala atakującym sondować środowiska Microsoft Entra ID, omijając typową telemetrię logowania.
Według Proofpoint co najmniej dwa odrębne klastry zagrożeń zastosowały tę technikę w kampaniach na dużą skalę. Aktywność pozwala atakującym wyliczać konta użytkowników i weryfikować skradzione poświadczenia bez generowania zdarzeń udanego logowania, na których obrońcy często opierają wykrywanie.
Problem nie jest klasycznym exploitem oprogramowania.
To słabość w sposobie, w jaki można nadużywać odpowiedzi uwierzytelniania i zachowania mechanizmu logowania.
Czym jest podszywanie się pod identyfikator klienta OAuth?
Identyfikatory klienta OAuth to globalnie unikalne identyfikatory przypisywane aplikacjom, które żądają dostępu do danych użytkownika.
W normalnych przepływach uwierzytelniania parametr client_id identyfikuje aplikację wysyłającą żądanie. Zespoły bezpieczeństwa często wykorzystują tę informację, aby zrozumieć, która aplikacja uczestniczy w próbie logowania.
W tych kampaniach atakujący wysyłają żądania uwierzytelniania, używając sfałszowanych lub fikcyjnych identyfikatorów klienta OAuth.
Analizując odpowiedzi z błędami zwracane przez Microsoft Entra ID, atakujący mogą wywnioskować, czy:
- konto użytkownika istnieje
- hasło jest poprawne
- lista poświadczeń zawiera użyteczne wpisy
Niebezpieczne jest to, że może się to odbywać bez generowania zdarzenia udanego logowania, które normalnie zaalarmowałoby obrońców.
Dlaczego to ma znaczenie
Logi logowania Entra ID są jednym z głównych źródeł, z których obrońcy korzystają, aby wykrywać złośliwą aktywność uwierzytelniania.
Powszechnie służą do wychwytywania:
- password spraying
- prób ataku siłowego (brute force)
- enumeracji użytkowników
- podejrzanego dostępu aplikacji
- prób uzyskania początkowego dostępu
Podszywanie się pod identyfikator klienta OAuth osłabia tę widoczność.
Gdy używane są sfałszowane identyfikatory klienta, log logowania może rejestrować wyłącznie identyfikator aplikacji, bez odpowiadającej mu nazwy aplikacji. Oznacza to, że wykrywanie zależne od znanych nazw aplikacji, określonych wzorców aplikacji lub zasad dostępu warunkowego powiązanych z aplikacjami może przeoczyć tę aktywność.
Atakujący mogą rozdrabniać próby uwierzytelniania na wiele fikcyjnych aplikacji, co utrudnia korelowanie aktywności.
Jak atakujący wykorzystują tę lukę
Proofpoint twierdzi, że najnowsze kampanie wykorzystują żądania HTTP POST do punktu końcowego tokenów OAuth 2.0 Microsoft z przepływem Resource Owner Password Credentials.
Zamiast używać zarejestrowanej aplikacji, atakujący podają sfałszowane identyfikatory klienta. Odpowiedź zawiera kody błędów Entra ID, które mogą ujawniać przydatne informacje o stanie konta lub poświadczeń.
Pozwala to atakującym sprawdzać na dużą skalę ogromne listy skradzionych poświadczeń.
Technika daje im sposób na wskazanie obiecujących kont do późniejszego dostępu, przy jednoczesnym zmniejszeniu szans na wywołanie tradycyjnych alertów logowania.
Zaobserwowano dwie duże kampanie
Proofpoint zidentyfikował dwie duże kampanie, które niezależnie od siebie zastosowały podszywanie się pod identyfikator klienta OAuth około końca 2025 roku.
Pierwszy klaster, śledzony jako UNK_pyreq2323, działał od stycznia do marca 2026 roku. Używał ponad 700 000 sfałszowanych identyfikatorów klienta z infrastruktury AWS i atakował ponad 1 milion kont w prawie 4000 tenantów. Proofpoint poinformował, że aktywność spowodowała blokady kont u około 28% atakowanych użytkowników z powodu nieudanych prób.
Drugi klaster, śledzony jako UNK_OutFlareAZ, rozpoczął działalność w grudniu 2025 roku i korzystał z infrastruktury Cloudflare. Atakował ponad 2 miliony użytkowników z użyciem 3,7 miliona losowych sfałszowanych identyfikatorów aplikacji.
Obie kampanie używały poprawnych identyfikatorów klienta w stylu UUID i wykazywały oznaki pracy na podstawie wcześniej przygotowanych list nazw użytkowników.
Ich zachowanie jednak się różniło. UNK_pyreq2323 modyfikował końcowe cyfry znanych identyfikatorów aplikacji i ponownie wykorzystywał sfałszowane identyfikatory dla wielu użytkowników. UNK_OutFlareAZ generował unikalny identyfikator klienta dla każdego żądania.
Taki poziom zróżnicowania utrudnia wykrywanie.
Dlaczego dostęp warunkowy może nie wystarczyć
Wiele organizacji używa zasad dostępu warunkowego (Conditional Access), aby kontrolować, którzy użytkownicy i które aplikacje mogą uzyskiwać dostęp do zasobów w chmurze.
Jednak podszywanie się pod identyfikator klienta OAuth może omijać część logiki powiązanej z aplikacją.
Jeśli zasada jest powiązana z konkretną aplikacją, sfałszowany lub fikcyjny identyfikator klienta może jej nie uruchomić w oczekiwany sposób. Tworzy to lukę dla atakujących, którzy celowo unikają kierowania ataku na jedną znaną tożsamość aplikacji.
Nie oznacza to, że dostęp warunkowy jest nieskuteczny.
Oznacza to, że zasady trzeba projektować z myślą o szerszych nadużyciach uwierzytelniania, a nie tylko o znanych nazwach aplikacji.
Na co powinni zwracać uwagę obrońcy
Zespoły bezpieczeństwa powinny patrzeć poza udane logowania i znane nazwy aplikacji.
Przydatne obszary wykrywania obejmują:
- duże wolumeny nieudanych żądań tokenów
- rekordy logowania z identyfikatorami aplikacji, ale bez nazwy aplikacji
- dużą liczbę unikalnych identyfikatorów klienta
- nietypową aktywność Resource Owner Password Credentials
- skoki liczby blokad kont
- powtarzające się wzorce błędów AADSTS
- próby uwierzytelniania od dostawców hostingu w chmurze
- aktywność rozproszoną na wiele fikcyjnych aplikacji
- wzorce enumeracji obejmujące cały tenant
- próby, które nie pasują wyraźnie do normalnego użycia aplikacji
Kluczem jest wykrywanie wzorca nadużycia, a nie tylko etykiety aplikacji.
Zalecane działania obronne
Organizacje korzystające z Microsoft Entra ID powinny przejrzeć monitorowanie uwierzytelniania i zakres dostępu warunkowego.
Zalecane działania obejmują:
- monitorowanie nieudanych prób uwierzytelniania, a nie tylko udanych logowań
- wykrywanie brakujących lub pustych nazw aplikacji w telemetrii logowania
- alertowanie na identyfikatory klienta OAuth o wysokiej liczności (high-cardinality)
- przegląd użycia ROPC i ograniczanie przepływów opartych na hasłach tam, gdzie to możliwe
- wymuszanie uwierzytelniania wieloskładnikowego odpornego na phishing dla wrażliwych użytkowników
- badanie masowych blokad kont
- stosowanie zasad dostępu warunkowego szeroko, a nie tylko do wybranych aplikacji
- monitorowanie prób uwierzytelniania z nietypowej infrastruktury chmurowej
- korelowanie logów Entra z telemetrią sieci, tożsamości i punktów końcowych
- przegląd mechanizmów wykrywania zależnych od wyświetlanych nazw aplikacji
Uwierzytelnianie bezhasłowe i odporne na phishing może znacząco zmniejszyć wartość skradzionych haseł, nawet jeśli atakujący potrafią je zweryfikować.
Podsumowanie
Podszywanie się pod identyfikator klienta OAuth pokazuje, jak ewoluują ataki na tożsamość w chmurze.
Atakujący nie tylko próbują kraść hasła. Uczą się również nadużywać przepływów uwierzytelniania, odpowiedzi z błędami i założeń dotyczących logowania, aby weryfikować poświadczenia, pozostając poniżej tradycyjnych progów wykrywania.
Monitorowania tożsamości w chmurze nie można opierać wyłącznie na udanych logowaniach, znanych nazwach aplikacji ani standardowych alertach uwierzytelniania. Atakujący celują w luki między uwierzytelnianiem, telemetrią a zaufaniem do aplikacji.
Aby się przed tym bronić, organizacje potrzebują szerszej widoczności żądań tokenów, wzorców nieudanego uwierzytelniania, zachowania OAuth i nietypowych identyfikatorów aplikacji w swoich środowiskach Entra ID.
