Microsoft OAuth-Phishing: Wie Angreifer Standard-Protokollverhalten für Malware-Kampagnen nutzen

Microsofts Sicherheitsteam hat eine Phishing-Kampagne offengelegt, die gezielt OAuth-konforme Weiterleitungsmechanismen ausnutzt. Im Fokus stehen Behörden und öffentliche Einrichtungen. Obwohl Microsoft Entra die identifizierten schadhaften OAuth-Anwendungen inzwischen deaktiviert hat, betont das Unternehmen, dass die zugehörigen Aktivitäten fortbestehen und eine kontinuierliche Überwachung erfordern. Die Kampagne wurde durch Microsoft Defender in E-Mail-, Identitäts- und Endpunktsignalen erkannt und dokumentiert.

Angriffsmethodik: Protokollverhalten statt Software-Schwachstellen

Das charakteristische Merkmal dieses Angriffsmusters liegt darin, dass keine klassischen Sicherheitslücken in Software ausgenutzt werden. Stattdessen setzen die Täter auf das standardisierte Fehlerverhalten des OAuth-2.0-Protokolls – einem weit verbreiteten Autorisierungsstandard, der von Diensten wie Microsoft Entra ID und Google Workspace genutzt wird.

OAuth sieht vor, dass Identitätsanbieter Nutzer unter bestimmten Bedingungen – etwa bei Authentifizierungsfehlern oder definierten Ablaufszenarien – auf vorab registrierte Weiterleitungs-URIs umleiten. Genau diesen Mechanismus machen sich die Angreifer zunutze. Sie legen OAuth-Anwendungen in selbst kontrollierten Mandanten an und hinterlegen dort Weiterleitungs-URIs, die auf von ihnen betriebene Server verweisen, auf denen Schadsoftware bereitliegt. Da die initiale URL eine bekannte und als vertrauenswürdig eingestufte Domain eines großen Identitätsanbieters trägt, fällt sie weder klassischen E-Mail-Sicherheitsfiltern noch aufmerksamen Nutzern sofort als verdächtig auf.

Fünfstufiger Angriffsverlauf

Microsoft beschreibt den vollständigen Ablauf in fünf klar abgrenzbaren Phasen, die zusammen einen durchgängigen Angriffspfad vom E-Mail-Eingang bis zur Kompromittierung des Endgeräts ergeben.

Phase 1: Phishing-E-Mail mit OAuth-URL

In der ersten Phase versenden die Angreifer Phishing-E-Mails, deren Inhalte auf alltägliche oder beruflich relevante Themen ausgerichtet sind: E-Signatur-Anfragen, Sozialversicherungsmitteilungen, Finanzdokumente oder politische Inhalte sollen die Empfänger zum Klicken auf den enthaltenen Link bewegen. Die schadhaften OAuth-URLs sind entweder direkt im E-Mail-Text eingebettet oder befinden sich in PDF-Anhängen, während der E-Mail-Text selbst leer bleibt – eine Methode, die darauf abzielt, textbasierte Sicherheitsfilter zu umgehen.

Für den Versand nutzten die identifizierten Akteure sowohl frei verfügbare Massenversand-Dienste als auch selbst entwickelte Lösungen auf Basis von Python und Node.js. Teilweise kamen Cloud-basierte E-Mail-Dienste und virtuelle Maschinen zum Einsatz. Einige Kampagnen enthielten zudem gefälschte Kalender-Einladungen im ICS-Format oder besprechungsbezogene Nachrichten, um einen legitimen Arbeitskontext zu simulieren und die Interaktionsbereitschaft der Empfänger zu erhöhen.

Um die Glaubwürdigkeit auf der späteren Phishing-Seite zu steigern, übermittelten die Angreifer die Ziel-E-Mail-Adresse über den OAuth-Parameter state – eigentlich vorgesehen zur Korrelation von Anfrage und Antwort. So konnte das Adressfeld auf der Phishing-Seite automatisch vorausgefüllt werden. Zur Verschleierung wurden verschiedene Kodierungsmethoden eingesetzt, darunter Klartext, Hexadezimaldarstellung, Base64 sowie benutzerdefinierte Schemata.

Phase 2: Stille OAuth-Prüfung

Ein Klick auf den Link löst einen OAuth-Autorisierungsfluss aus, der durch gezielt falsch gesetzte Parameter so konstruiert ist, dass er zwingend scheitern muss. Der Parameter prompt=none weist den Identitätsanbieter an, keine Benutzeroberfläche anzuzeigen – stattdessen soll der bestehende Sitzungsstatus stillschweigend geprüft werden. Gleichzeitig wird ein absichtlich ungültiger Bereich (scope) übergeben, der einen Fehler provoziert. Weitere Fehlerauslöser können sein: Der Nutzer ist nicht angemeldet, die Browsersitzung kann nicht abgerufen werden, oder der Anwendung fehlt ein Dienstprinzipal im Mandanten des Nutzers.

Aus Sicht der Angreifer ist dieser fehlgeschlagene Vorgang dennoch informativ: Er verrät, ob das Benutzerkonto existiert und ob stilles Single Sign-on aktiv oder blockiert ist – wertvolle Metainformationen für die weitere Vorgehensweise. Dieses Vorgehen ist nicht auf Microsoft oder Google beschränkt; prinzipiell lässt es sich bei jedem OAuth-kompatiblen Dienst anwenden.

Grafik Quelle: Microsoft

Phase 3: OAuth-Fehlerumleitung zur Angreifer-Infrastruktur

Schlägt die stille Authentifizierung fehl, gibt der Identitätsanbieter einen OAuth-Fehler zurück – und leitet den Browser des Nutzers dabei an die registrierte Weiterleitungs-URI der schadhaften Anwendung weiter. Der Fehlercode 65001 zeigt an, dass der Nutzer der Anwendung keine Ressourcenzugriffsrechte erteilt hat. Ein Zugriffstoken wird dabei nicht ausgestellt, was jedoch für die Angreifer in dieser Kampagne zweitrangig ist: Das eigentliche Ziel ist die Weiterleitung auf eine vom Angreifer kontrollierte Seite.

Da die Weiterleitungs-URIs jederzeit ausgetauscht werden können, sobald Sicherheitsfilter eine bestimmte Domain blockieren, ergibt sich für die Täter eine flexible und schwer zu unterbrechende Angriffsinfrastruktur.

Grafik Quelle: Microsoft

Phase 4: Landing Page und Malware-Verteilung

Auf der vom Angreifer kontrollierten Seite angekommen, werden die Opfer je nach Kampagne unterschiedlich weiterbehandelt. Ein Teil der dokumentierten Fälle leitete die Nutzer zu Phishing-Frameworks wie EvilProxy weiter – proxybasierte Man-in-the-Middle-Toolkits, die Anmeldedaten und Sitzungscookies abfangen. Zusätzliche Verschleierungsebenen wie CAPTCHA-Abfragen oder Zwischenseiten erschweren dabei die automatische Erkennung durch Sicherheitssysteme.

In einer gesondert identifizierten Kampagne mit Fokus auf Malware-Verteilung wurden die Opfer auf einen /download/XXXX-Pfad weitergeleitet, von dem automatisch eine ZIP-Datei auf das Zielgerät heruntergeladen wurde. Die archivierten Inhalte umfassten LNK-Verknüpfungsdateien sowie HTML-Smuggling-Loader – beides gängige Methoden, um Sicherheitskontrollen beim Dateidownload zu umgehen.

Phase 5: Endpunkt-Kompromittierung und Persistenz

Das Öffnen der LNK-Datei löst einen PowerShell-Befehl aus, der zunächst eine Erkundungsphase des betroffenen Systems einleitet. Dabei werden Standardbefehle wie ipconfig /all und tasklist ausgeführt, um Netzwerkkonfiguration und laufende Prozesse zu inventarisieren. Im Anschluss extrahiert PowerShell mithilfe des Windows-Bordmittels tar drei Dateien aus dem Archiv: die legitime Anwendungsdatei steam_monitor.exe, die schadhafte Bibliothek crashhandler.dll sowie die verschlüsselte Datei crashlog.dat.

Die legitime EXE-Datei wird dann gestartet und lädt dabei über DLL-Side-Loading die schadhafte Bibliothek. Diese entschlüsselt die dritte Datei und führt die finale Payload direkt im Arbeitsspeicher aus – eine Technik, die klassische dateibasierte Erkennung durch Sicherheitssoftware erschwert. Abschließend wird eine ausgehende Verbindung zu einem externen Command-and-Control-Server aufgebaut, der die weitere Steuerung des kompromittierten Systems ermöglicht. Microsoft beobachtete in diesem Zusammenhang Aktivitäten, die auf Vorstufen einer Ransomware-Attacke oder sogenannte Hands-on-Keyboard-Angriffe hindeuten.

Schutzmaßnahmen und Handlungsempfehlungen

Microsoft empfiehlt Organisationen ein mehrstufiges Maßnahmenpaket. Auf der Identitäts- und Anwendungsebene sollten Unternehmen die Zustimmungsrechte von Nutzern für OAuth-Anwendungen einschränken, bestehende Anwendungsberechtigungen regelmäßig prüfen und nicht mehr verwendete oder überprivilegierte Apps konsequent entfernen. Ergänzend dazu sollten Richtlinien für bedingten Zugriff und domänenübergreifende Erkennungsmechanismen für E-Mails, Identitäten und Endpunkte eingerichtet sowie erweiterte Protokollierung und Überwachung aktiviert werden.

Als konkrete Indikatoren für laufende Angriffe benennt Microsoft folgende Muster, nach denen Sicherheitsteams aktiv suchen sollten:

OAuth-URLs mit dem Parameter prompt=none in E-Mails mit klassischen Phishing-Themen wie Dokumentenfreigabe, Passwortzurücksetzung oder HR-Mitteilungen; unerwartete Weiterleitungen zu unbekannten Domains im Anschluss an eine OAuth-Interaktion; sowie E-Mail-Adressen, die im state-Parameter der OAuth-URL – offen oder verschlüsselt – mitgeführt werden. Auch eine Überprüfung und Härtung der bestehenden E-Mail-Sicherheitsrichtlinien wird empfohlen.

Einordnung

Die dokumentierten Kampagnen stehen stellvertretend für eine breitere Entwicklung in der Bedrohungslandschaft: Angreifer weichen zunehmend auf Protokollmissbrauch und die Ausnutzung von Vertrauensbeziehungen aus, anstatt auf bekannte Software-Schwachstellen zu setzen. Da OAuth in RFC 6749 spezifiziert ist und das beschriebene Fehler- und Weiterleitungsverhalten standardkonform ist, lässt sich das grundlegende Problem nicht durch ein einfaches Sicherheits-Update lösen. RFC 9700 weist in Abschnitt 4.11.2 ausdrücklich auf das Risiko hin, dass Autorisierungsserver als offene Weiterleitungspunkte missbraucht werden können – durch den gezielten Einsatz ungültiger Parameter wie scope oder prompt=none.

Microsoft sieht in domänenübergreifenden XDR-Erkennungen, einer klareren Governance rund um OAuth-Weiterleitungsverhalten und einer engeren Zusammenarbeit innerhalb der Sicherheitsgemeinschaft die wesentlichen Ansatzpunkte, um den Missbrauch einzudämmen, ohne die Interoperabilität zu beeinträchtigen, die OAuth als offener Standard ermöglicht.

Empfehlung:

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk