Phishing Entra ID: nadużywanie przekierowań OAuth

Wprowadzenie: dlaczego to ma znaczenie

Linki OAuth do znanych dostawców tożsamości (IdP), takich jak Microsoft Entra ID, są często uznawane przez użytkowników za zaufane, a w niektórych przypadkach są traktowane bardziej liberalnie przez mechanizmy bezpieczeństwa. Najnowsze badania Microsoft pokazują, że zachowanie przekierowań OAuth działające „zgodnie z projektem” jest nadużywane do wysyłania użytkowników z legalnych domen logowania do infrastruktury atakujących — co umożliwia phishing i dostarczanie malware, a jednocześnie wygląda jak normalny proces logowania.

Jest to szczególnie istotne dla administratorów IT w organizacjach rządowych i sektora publicznego, które były konkretnie celem zaobserwowanej aktywności.

Co nowego / kluczowe ustalenia

Microsoft Defender Security Research Team zaobserwował phishingowe wykorzystanie mechanizmów przekierowań OAuth w sygnałach związanych z pocztą e-mail, tożsamością i endpointami:

• Nadużywanie cichych przepływów OAuth: Atakujący tworzą adresy URL autoryzacji OAuth z użyciem parametrów takich jak prompt=none, aby podjąć próbę cichego sprawdzenia uwierzytelnienia (bez interfejsu użytkownika).
• Celowo nieprawidłowe zakresy wymuszające ścieżkę błędu: Żądania zawierają scope=<invalid_scope> (lub inne wyzwalacze błędu), aby niezawodnie wygenerować błąd OAuth.
• Przekierowanie sterowane błędem do URI kontrolowanego przez atakującego: Gdy IdP zwraca błąd (na przykład interaction_required), przeglądarka jest przekierowywana do zarejestrowanego redirect URI aplikacji, które atakujący konfiguruje tak, aby wskazywało na strony phishingowe lub witryny pobierania malware.
• Do przekierowania nie jest wymagana kradzież tokenu: Atakujący niekoniecznie próbują pomyślnie zakończyć OAuth; głównym celem jest samo przekierowanie.
• Nadużywanie parametru state do personalizacji: Parametr state — przeznaczony do korelacji żądania i odpowiedzi — został wykorzystany ponownie do przekazywania adresu e-mail ofiary (w postaci jawnego tekstu, hex, Base64 lub niestandardowego kodowania), aby strony phishingowe mogły automatycznie uzupełniać identyfikatory.
• Wzorce dostarczania kampanii: Przynęty phishingowe obejmowały prośby o e-podpis, motywy finansowe i związane z ubezpieczeniem społecznym, udostępnianie dokumentów, treści związane z Teams/spotkaniami oraz monity resetowania hasła. Część z nich wykorzystywała załączniki PDF z osadzonymi linkami, a nawet zaproszenia kalendarzowe .ics.
• Narzędzia wykorzystywane dalej w łańcuchu ataku: Strony po przekierowaniu często używały frameworków phishingowych takich jak EvilProxy (attacker-in-the-middle), zaprojektowanych do przechwytywania poświadczeń i plików cookie sesji, czasami z dodatkowymi krokami CAPTCHA/interstitial.

Wpływ na administratorów IT i użytkowników końcowych

• Wyższe ryzyko kliknięcia: Linki zaczynają się w zaufanych domenach IdP (na przykład login.microsoftonline.com), co zwiększa zaufanie użytkowników.
• Presja na obchodzenie zabezpieczeń: Tradycyjne kontrole reputacji URL mogą skupiać się na domenie początkowej i nie wychwycić docelowego miejsca przekierowania.
• Potrzeba widoczności na wielu warstwach: Microsoft wskazuje, że Defender skorelował sygnały z obszarów email, identity, and endpoint, podkreślając, że wykrywanie oparte na pojedynczej kontroli może być niewystarczające.
• Trwające zagrożenie: Microsoft Entra wyłączył zaobserwowane złośliwe aplikacje OAuth, ale powiązana aktywność nadal trwa — monitoring jest wciąż wymagany.

Działania / kolejne kroki

1. Wyszukuj podejrzane wzorce OAuth authorize w logach i telemetrii proxy, w szczególności:
   • prompt=none połączone z nietypowymi/nieprawidłowymi wartościami scope
   • Częste błędy OAuth, po których następują przekierowania do domen spoza organizacji
   • Użycie /common/ w nieoczekiwanych kontekstach phishingowych o dużym wolumenie
2. Przejrzyj i ogranicz zgody aplikacji oraz rejestracje aplikacji:
   • Przeprowadź audyt nowo utworzonych aplikacji i redirect URI pod kątem niezaufanych domen
   • Zaostrz zasady określające, kto może rejestrować aplikacje / modyfikować redirect URI w Entra ID
3. Wzmocnij ochronę przed phishingiem poza kontrolami „zaufanej domeny”:
   • Upewnij się, że narzędzia do detonacji URL / safe links śledzą przekierowania
   • Uświadamiaj użytkownikom, że „zaczyna się od logowania Microsoft” nie gwarantuje bezpieczeństwa
4. Zweryfikuj Conditional Access i mechanizmy kontroli sesji:
   • Monitoruj telemetrię logowań i błędów OAuth pod kątem anomalii oraz ukierunkowanych grup użytkowników
5. Wykorzystaj korelację w Defender:
   • Korzystaj z Microsoft Defender for Office 365 + Defender for Identity/Endpoint do korelowania przynęty e-mail, zachowania podczas logowania i aktywności ładunku na endpointach.