Entra ID OAuth-Redirects für Phishing missbraucht

Einführung: warum das wichtig ist

OAuth-Links zu bekannten Identity Providern (IdPs) wie Microsoft Entra ID genießen bei Benutzern oft Vertrauen und werden in manchen Fällen auch von Sicherheitskontrollen weniger strikt behandelt. Microsofts aktuelle Forschung hebt ein „by design“-OAuth-Redirect-Verhalten hervor, das missbraucht wird, um Benutzer von legitimen Login-Domains zu Angreifer-Infrastruktur umzuleiten—und so Phishing sowie Malware-Auslieferung zu ermöglichen, während es wie ein normaler Sign-in-Flow aussieht.

Das ist besonders relevant für IT-Admins in Behörden und Organisationen des öffentlichen Sektors, die in der beobachteten Aktivität gezielt angegriffen wurden.

Was ist neu / Kernerkenntnisse

Das Microsoft Defender Security Research Team beobachtete phishinggetriebene Ausnutzung der OAuth-Redirect-Mechanik über Signale aus E-Mail, Identity und Endpoint hinweg:

• Missbrauch von Silent OAuth Flows: Angreifer erstellen OAuth-Authorization-URLs mit Parametern wie prompt=none, um eine stille Authentifizierungsprüfung zu erzwingen (ohne UI).
• Absichtlich ungültige Scopes, um einen Fehlerpfad zu erzwingen: Requests enthalten scope=<invalid_scope> (oder andere Auslöser für Fehlschläge), um zuverlässig einen OAuth-Fehler zu erzeugen.
• Fehlergetriebener Redirect zu einer vom Angreifer kontrollierten URI: Wenn der IdP einen Fehler zurückgibt (zum Beispiel interaction_required), wird der Browser zur registrierten Redirect URI der App weitergeleitet, die der Angreifer so konfiguriert, dass sie auf Phishing-Seiten oder Malware-Download-Seiten zeigt.
• Für den Redirect ist kein Token-Diebstahl erforderlich: Der Angreifer versucht nicht zwingend, OAuth erfolgreich abzuschließen; der Redirect ist das eigentliche Ziel.
• Missbrauch des State-Parameters zur Personalisierung: Der state-Parameter—eigentlich für die Korrelation von Request/Response gedacht—wurde zweckentfremdet, um die E-Mail-Adresse des Opfers (im Klartext, Hex, Base64 oder mit Custom-Encoding) zu übergeben, damit Phishing-Seiten Identifikatoren automatisch vorausfüllen können.
• Kampagnen-Delivery-Muster: Phishing-Köder umfassten E-Signatur-Anfragen, Finanz-/Social-Security-Themen, Dokumentfreigaben, Teams-/Meeting-Inhalte und Passwort-Reset-Aufforderungen. Einige nutzten PDF-Anhänge mit eingebetteten Links und sogar .ics-Kalendereinladungen.
• Nachgelagerte Tooling: Post-Redirect-Seiten nutzten häufig Phishing-Frameworks wie EvilProxy (attacker-in-the-middle), die darauf ausgelegt sind, Credentials und Session-Cookies abzugreifen, teils ergänzt um CAPTCHA-/Interstitial-Schritte.

Auswirkungen auf IT-Administratoren und Endbenutzer

• Höheres Click-through-Risiko: Links beginnen auf vertrauenswürdigen IdP-Domains (zum Beispiel login.microsoftonline.com), was das Vertrauen der Benutzer erhöht.
• Druck auf Defense-Bypass: Klassische URL-Reputationsprüfungen fokussieren sich möglicherweise auf die initiale Domain und übersehen das spätere Ziel.
• Sichtbarkeit über mehrere Ebenen erforderlich: Microsoft weist darauf hin, dass Defender Signale über E-Mail, Identity und Endpoint hinweg korreliert hat—ein Hinweis darauf, dass Detektion über eine einzelne Kontrolle nicht ausreichen kann.
• Anhaltende Bedrohung: Microsoft Entra hat beobachtete bösartige OAuth-Anwendungen deaktiviert, aber verwandte Aktivität hält an—Monitoring bleibt erforderlich.

Maßnahmen / nächste Schritte

1. Suchen Sie in Logs und Proxy-Telemetrie nach verdächtigen OAuth-Authorize-Mustern, insbesondere:
   • prompt=none kombiniert mit ungewöhnlichen/ungültigen scope-Werten
   • Häufige OAuth-Fehlschläge, gefolgt von Redirects zu nicht-unternehmensbezogenen Domains
   • Verwendung von /common/ in unerwarteten, hochvolumigen Phishing-Kontexten
2. Überprüfen und beschränken Sie App-Consent und App-Registrierungen:
   • Auditieren Sie neu erstellte Apps und Redirect URIs auf nicht vertrauenswürdige Domains
   • Verschärfen Sie, wer in Entra ID Anwendungen registrieren/Redirect URIs ändern darf
3. Stärken Sie Phishing-Schutz über „Trusted Domain“-Checks hinaus:
   • Stellen Sie sicher, dass URL-Detonation/Safe-Link-Tools Redirects nachverfolgen
   • Schulen Sie Benutzer: „Startet bei Microsoft Sign-in“ garantiert keine Sicherheit
4. Validieren Sie Conditional Access und Session Controls:
   • Überwachen Sie Sign-in- und OAuth-Error-Telemetrie auf Anomalien und gezielte Benutzergruppen
5. Nutzen Sie Defender-Korrelation:
   • Nutzen Sie Microsoft Defender for Office 365 + Defender for Identity/Endpoint, um E-Mail-Köder, Sign-in-Verhalten und Endpoint-Payload-Aktivität zu korrelieren.