OAuth-Token-Diebstahl: Wie Angreifer MFA aushebeln

7 Min. Lesezeit

Multi-Faktor-Authentifizierung verriegelt die Anmeldung. Sie schützt aber nicht den Schlüssel, der nach der Anmeldung ausgestellt wird. Genau hier setzen Angreifer jetzt an: Sie stehlen OAuth-Token, die eine bestandene MFA bereits enthalten, und greifen damit auf SaaS-Dienste zu, ohne je eine zweite Faktor-Abfrage auszulösen. Das OAuth-Phishing ist im vergangenen Jahr um das fast Neununddreißigfache gestiegen. Über tausend SaaS-Umgebungen waren betroffen.

Verwandt:Das Edge-Gerät als Ransomware-Eingangstor  /  Wenn das Schutzprodukt selbst die Lücke ist

Wie ein Token die MFA umgeht

Was ist ein OAuth-Token? Ein OAuth-Token ist ein digitaler Berechtigungsnachweis, den ein Dienst nach erfolgreicher Anmeldung ausstellt. Statt sich bei jeder Anfrage neu mit Passwort und zweitem Faktor anzumelden, legt die Anwendung dieses Token vor. Es bestätigt: Dieser Zugriff wurde bereits authentifiziert. Genau diese Bequemlichkeit ist die Schwachstelle.

Die Logik ist ernüchternd einfach. MFA wirkt im Moment der Anmeldung. Danach stellt der Dienst ein Sitzungs- oder OAuth-Token aus, das den authentifizierten Zustand repräsentiert. Wer dieses Token in die Hände bekommt, muss sich nicht mehr anmelden. Er legt den Schlüssel vor, den die MFA bereits abgesegnet hat. Die zweite Faktor-Stufe wird nicht geknackt, sie wird umgangen, weil sie zum Zeitpunkt des Angriffs längst Geschichte ist.

Besonders perfide ist der Missbrauch des Device-Code-Verfahrens. Eigentlich erlaubt es die Anmeldung von Geräten ohne Tastatur, etwa Smart-TVs. Angreifer leiten ihr Opfer dazu, einen Code zu bestätigen, der in Wahrheit dem Angreifer-Gerät Zugriff verschafft. Das Opfer durchläuft eine echte, legitime MFA, und genehmigt damit unwissentlich die fremde Sitzung. Aus Sicht des Dienstes ist alles korrekt, ein berechtigter Nutzer hat zugestimmt.

Warum klassische MFA hier ins Leere greift

Die unbequeme Erkenntnis: MFA wurde gegen ein anderes Problem gebaut. Sie verhindert, dass ein gestohlenes Passwort allein reicht. Gegen einen gestohlenen Token nach erfolgter Anmeldung hilft sie nicht, weil sie an dieser Stelle gar nicht mehr im Spiel ist. Wer MFA als abschließende Maßnahme betrachtet, verteidigt die Tür und übersieht, dass der Angreifer durch das offene Fenster der Sitzung kommt.

Das verschiebt die Verteidigung von der Anmeldung zur Sitzung. Es reicht nicht mehr, den Zugang einmal zu prüfen. Die Sitzung selbst muss überwacht und begrenzt werden. Ein Token, das unbegrenzt gilt und von jedem Ort akzeptiert wird, ist ein Dauerschlüssel. Ein Token, das nach kurzer Zeit verfällt, an Gerät und Standort gebunden ist und bei Auffälligkeit widerrufen wird, ist deutlich weniger wert, wenn es gestohlen wird.

Was ein SOC konkret tun sollte

Der erste Hebel ist die Token-Lebensdauer. Viele SaaS-Dienste erlauben großzügige Standardwerte, weil das die Nutzer selten zur erneuten Anmeldung zwingt. Genau diese Bequemlichkeit gehört geprüft. Kürzere Gültigkeit und erzwungene Re-Authentifizierung bei sensiblen Aktionen verkleinern das Zeitfenster, in dem ein gestohlenes Token nützt.

Der zweite Hebel ist Conditional Access. Ein Token sollte nicht von überall gelten. Wird dieselbe Sitzung plötzlich aus einem anderen Land oder von einem unbekannten Gerät genutzt, gehört sie hinterfragt, nicht stillschweigend akzeptiert. Diese Kontextprüfung ist die eigentliche Antwort auf den gestohlenen Token, weil sie nicht die Anmeldung absichert, sondern die Nutzung.

MFA verriegelt die Tür. Wenn der Angreifer den Schlüssel kopiert, der danach ausgegeben wird, nützt das beste Schloss nichts. Verteidigt werden muss die Sitzung, nicht nur der Login.

Der dritte Hebel betrifft das Device-Code-Verfahren selbst. Wo es nicht gebraucht wird, gehört es eingeschränkt oder abgeschaltet. Und die Belegschaft sollte wissen, dass die Aufforderung, einen Code zu bestätigen, denselben Argwohn verdient wie eine Passwort-Abfrage auf einer fremden Seite. Ein bestätigter Code kann eine fremde Sitzung autorisieren. Diese eine Information verhindert einen Großteil der Device-Code-Angriffe.

Keiner dieser drei Hebel schafft MFA ab. Sie bleibt die Basis. Aber sie ist die erste Verteidigungslinie, nicht die letzte. Wer die Sitzung nach der Anmeldung aus dem Blick verliert, hat die Verteidigung an der Stelle aufgegeben, an der die aktuellen Angriffe ansetzen. Die gute Nachricht: Token-Lebensdauer, Conditional Access und Device-Code-Hygiene sind konfigurierbar, nicht erst zu erfinden.

Häufige Fragen

Wird bei einem OAuth-Token-Diebstahl die MFA geknackt?

Nein, sie wird umgangen. Das Token entsteht nach erfolgreicher MFA und trägt den authentifizierten Zustand in sich. Wer es stiehlt, muss sich nicht mehr anmelden und löst deshalb keine neue Faktor-Abfrage aus.

Was ist Device-Code-Missbrauch?

Das Device-Code-Verfahren erlaubt die Anmeldung von Geräten ohne Tastatur. Angreifer bringen ein Opfer dazu, einen Code zu bestätigen, der in Wahrheit dem Angreifer-Gerät Zugriff verschafft. Das Opfer durchläuft eine echte MFA und genehmigt unwissentlich die fremde Sitzung.

Warum reicht MFA gegen diese Angriffe nicht?

MFA wirkt im Moment der Anmeldung. Der Angriff setzt danach an, bei der bereits ausgestellten Sitzung. An dieser Stelle ist die MFA nicht mehr beteiligt, deshalb kann sie den gestohlenen Token nicht aufhalten.

Welche Maßnahme hilft am schnellsten?

Die Token-Lebensdauer prüfen und kürzen sowie Conditional Access aktivieren. Beides verkleinert das Zeitfenster und den Geltungsbereich eines gestohlenen Tokens, ohne MFA zu ersetzen.

Sollte das Device-Code-Verfahren abgeschaltet werden?

Wo es nicht gebraucht wird, ja. Wo es nötig ist, sollte es eingeschränkt und überwacht werden. Zusätzlich hilft die Aufklärung der Belegschaft, dass ein zu bestätigender Code eine fremde Sitzung autorisieren kann.

Bildquelle: KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt

Hier schreibt Benedikt Langer für Sie

Mehr Artikel vom Autor Benedikt Langer