Phishing mit echter Microsoft-Anmeldung — so sperren Sie den OAuth-Angriffspfad jetzt

Check Point Research hat eine aktive Phishing-Kampagne dokumentiert, bei der Angreifer mehr als 200 E-Mails an Mitarbeitende von rund 120 Organisationen weltweit verschickt haben — und die Opfer dabei zur Anmeldung auf die echte Microsoft-Infrastruktur leiten. Das klingt zunächst widersprüchlich. Ist es aber nicht: Die Kampagne nutzt keine gefälschte Loginseite, sondern das legitime Microsoft-Login als Türöffner. Was danach kommt, ist der eigentliche Angriff — bösartige App-Berechtigungen, die dauerhaften Zugang zum Konto sichern.

Der klassische Phishing-Ratschlag — „Prüfen Sie die URL, ob sie wirklich zu Microsoft gehört“ — greift hier ins Leere. Die URL ist echt. Die Loginseite ist echt. Die MFA-Bestätigung ist echt. Was anschließend erscheint, ist eine Einwilligungsseite: Eine externe OAuth-Anwendung fordert Zugriff auf das Microsoft-Konto an. Wer auf „Akzeptieren“ klickt, übergibt dem Angreifer delegierten Zugang — persistent, auch nach einer späteren Passwortänderung. OAuth-Token gehören der App, nicht dem Passwort.

Der Angriffsvektor verläuft laut Bericht über Microsoft Teams, was die Glaubwürdigkeit weiter erhöht: Eine scheinbar interne oder vertrauenswürdige Nachricht, ein Link, der zur echten Microsoft-Anmeldeseite führt — und wer gewohnheitsmäßig Drittanbieter-Apps in seinen M365-Workflow integriert, hat keinen natürlichen Grund zur Skepsis.

Was bestätigt ist

Nach Angaben von Check Point Research wurden mehr als 200 Phishing-E-Mails an Mitarbeitende von rund 120 Organisationen weltweit versendet. Die Kampagne nutzte legitime Microsoft-Infrastruktur — keine gefälschte Loginseite, keine imitierte Domäne. Der Schaden entsteht erst nach der Anmeldung, durch die Einräumung von OAuth-App-Berechtigungen an eine bösartige Drittanwendung.

Was derzeit offenbleibt

Welche Organisationen betroffen waren, ist öffentlich nicht bekannt. Wie viele der Phishing-Versuche zu einer tatsächlichen Zustimmung geführt haben, geht aus der Veröffentlichung nicht hervor. Ob eine bestimmte Angreifergruppe dahintersteckt, wird in den bisher bekannten Informationen nicht genannt.

Warum dieser Angriff anders ist

OAuth-Consent-Phishing ist kein neues Verfahren — aber die Kombination aus echtem Microsoft-Login, Teams als Angriffskanal und dem Erscheinungsbild einer harmlosen App-Integration macht den Angriff auch für technisch erfahrene Nutzer glaubwürdig. Klassische Gegenmaßnahmen greifen nicht: Kein Passwortmanager warnt, kein Anti-Phishing-Filter erkennt eine gefälschte Seite, weil es keine gibt. Die Gefahr liegt im „Weiter“-Klick nach dem Login — nicht im Login selbst.

Besonders gefährdet sind Umgebungen, in denen Nutzer regelmäßig Drittanbieter-Apps für M365 autorisieren — und in denen keine klare Richtlinie existiert, welche Apps zulässig sind.

Was Sie jetzt prüfen und einstellen sollten

Drei Konfigurationsänderungen reduzieren den Angriffspfad spürbar:

1. Nutzereinwilligung für OAuth-Apps einschränken. In Entra ID unter „Unternehmensanwendungen → Benutzereinstellungen → App-Einwilligungsrichtlinien“ prüfen, ob Nutzer Drittanbieter-Apps eigenständig Berechtigungen erteilen dürfen. Empfehlung: Nutzereinwilligung deaktivieren oder auf verifizierte Herausgeberorganisationen beschränken. Alle neuen App-Freigaben sollten über einen Admin-Genehmigungsprozess laufen.

2. Bestehende OAuth-Berechtigungen auditieren. In Entra ID unter „Unternehmensanwendungen → Alle Anwendungen“, gefiltert nach Nutzereinwilligung, sehen Administratoren, welchen Apps Zugriff gewährt wurde. Unbekannte oder verdächtige Einträge sofort widerrufen. Einzelne Nutzer können ihre eigenen App-Freigaben unter myapps.microsoft.com einsehen.

3. Microsoft Defender for Cloud Apps aktivieren. Das Tool erkennt anomale OAuth-App-Aktivitäten und kann verdächtige Berechtigungsanfragen in Echtzeit melden oder blockieren. Wer M365 E5 oder eine vergleichbare Lizenz nutzt, hat dieses Feature verfügbar — prüfen, ob es aktiv und konfiguriert ist.

Ergänzend empfiehlt sich ein Conditional-Access-Rahmen, der den Zugriff auf M365-Ressourcen auf verwaltete und konforme Geräte beschränkt. Das erschwert den Missbrauch delegierter App-Berechtigungen von unkontrollierten Endgeräten aus erheblich — und ist unabhängig vom konkreten Angriffsvektor sinnvoll.

Unsere Einschätzung aus dem Betrieb von Microsoft-365-Umgebungen heraus ist klar: Nutzereinwilligung für Drittanbieter-Apps gehört standardmäßig deaktiviert. Der Verwaltungsaufwand ist gering; das Risiko durch eine einzige unbedachte Zustimmung ist es nicht.

Quellen: Check Point Research via security-insider.de — „Phishing-Kampagne nutzt echte Microsoft-Anmeldung“ (https://www.security-insider.de/phishing-microsoft-teams-echte-login-seite-boesartige-app-berechtigungen-a-2fa1636d91b31c8388f4555881a3fc9f/)