Moderne Identitätsangriffe umgehen herkömmliche Schutzmechanismen immer geschickter: Angreifer müssen keine MFA-Müdigkeit mehr erzwingen, wenn Mitarbeiter autorisierte API-Berechtigungen freiwillig selbst abtreten. Die im MITRE ATT&CK Framework unter T1566.002 (Consent Phishing) geführte Angriffsmethode missbraucht native OAuth-2.0-Delegierungsmechanismen, um persistente Zugriffe auf Clouddaten zu erlangen.
Anatomie des Angriffs: Die Täuschung im OAuth-Workflow
Bei einem typischen Consent-Phishing-Angriff registriert der Bedrohungsakteur eine mandantenfähige (Multi-Tenant) Applikation in seinem eigenen Microsoft Entra ID Tenant. Er wählt einen vertrauenserweckenden Namen (z. B. «OneDrive Compliance Sync» oder «HR Portal Freigabe») und richtet eine kontrollierte Weiterleitungs-URI ein. Das Opfer wird über Phishing-E-Mails oder Teams-Nachrichten auf die offizielle Anmeldeseite login.microsoftonline.com gelenkt.
Nach erfolgreicher MFA-Authentifizierung erscheint die legitime Microsoft Entra ID Zustimmungsmaske. Klickt der Anwender auf «Zustimmen», überträgt er weitreichende delegierte Rechte an die bösartige Anwendung, ohne sein Kennwort preisgeben zu müssen. Der Angreifer erhält im Hintergrund ein Refresh Token und ein Access Token, mit denen er unmittelbar auf die Microsoft Graph API des Opfers zugreifen kann.
Der native tote Winkel und kritische Telemetrie
Da der Angriff auf legitimen Token-Ausstellungen basiert, greifen herkömmliche Conditional Access-Richtlinien für Folgezugriffe häufig ins Leere. Über den Berechtigungsbereich offline_access kann der Angreifer über externe IP-Adressen dauerhaft auf OneDrive-Dateien und E-Mails zugreifen, ohne dass der Benutzer erneut zur Authentifizierung aufgefordert wird. Microsoft Purview zeichnet diese Ereignisse im Audit-Log auf, doch ohne automatisierte Erkennungsregeln bleiben diese Berechtigungsvergaben oft monatelang unbemerkt.
Erkennung mit Advanced Hunting (KQL)
Mit der folgenden KQL-Abfrage in Advanced Hunting identifizieren Sie verdächtige Benutzerzustimmungen für Apps mit kritischen Zugriffsrechten auf Unternehmensdaten:
CloudAppEvents
| where ActionType in~ ("Consent to application", "Add delegated permission grant")
| extend Target = parse_json(RawEventData.Target)
| extend AppName = tostring(Target[0].DisplayName),
AppId = tostring(Target[0].Id)
| extend ModProps = parse_json(RawEventData.ModifiedProperties)
| mv-expand ModProps
| where ModProps.DisplayName =~ "ConsentAction.Permissions"
| extend GrantedScopes = tostring(ModProps.NewValue)
| where GrantedScopes has "offline_access"
and GrantedScopes has_any ("Files.ReadWrite", "Files.ReadWrite.All", "Mail.ReadWrite", "FullControl")
| project Timestamp, ConsentedBy = AccountDisplayName, IPAddress,
AppName, AppId, GrantedScopes, UserAgent, ReportIdSOAR-Remediation mit Akuity SOC
Wird eine riskante OAuth-Zustimmung registriert, ermöglicht Akuity SOC eine blitzschnelle, automatisierte Abwehrreaktion:
- Zero-Trust In-App-Qualifizierung: Der integrierte KI-Assistent von Akuity SOC führt
audit_enterprise_apps_permissionsin unter 2 Sekunden aus. Er bewertet riskante Scopes (Files.ReadWrite.All,offline_access) und das Fehlen verifizierter Herausgeber ohne Datenabfluss an externe Webtools. - Sofortige 1-Klick-SOAR-Reaktion: Auslösen der Server Action
revokeOAuthApp()direkt aus dem Incident-Graph, um den schädlichen Service Principal umgehend zu entfernen und sämtliche aktiven Refresh Tokens in Entra ID zu widerrufen. - Kritische Sicherheitskontrollen: Jede administrative Aktion erfordert eine MFA-AAL2-Bestätigung des Analysten und wird revisionssicher nach NIS-2- und SOC-2-Type-II-Kriterien protokolliert.
Erkennen und entfernen Sie bösartige Unternehmens-Apps mit nur einem Klick über die agentenlose SOAR-Orchestrierung von Akuity SOC.
Starten Sie Ihre 14-tägige Testversion (ohne Kreditkarte) →Häufig gestellte Fragen (FAQ)
Warum stellt der Scope offline_access ein so großes Sicherheitsrisiko dar?
Der Scope offline_access erlaubt der Anwendung den Erhalt von Refresh Tokens. Der Angreifer kann dadurch fortlaufend neue Access Tokens generieren und auf Ressourcen zugreifen, selbst wenn der betroffene Benutzer offline ist.
Wie kann Consent Phishing in Microsoft Entra ID präventiv eingeschränkt werden?
Administratoren sollten die Richtlinien für Benutzereinwilligungen so konfigurieren, dass Zustimmungen für nicht verifizierte Herausgeber gesperrt sind. Zudem sollte der Admin-Einwilligungsworkflow (Admin Consent Workflow) aktiviert werden.