Device-Code-Phishing: Forensik gegen den perfekten MFA-Bypass
13.07.2026 oauthdevice-code-phishingidentity-forensikmfa-bypass
Ein RFC-Standard als Angriffswerkzeug
Seit Februar 2026 verbreitet sich mit rasanter Geschwindigkeit eine Angriffstechnik, die kein einziges Sicherheitsupdate stoppen kann – weil sie keine Schwachstelle ausnutzt, sondern ein legitimes Protokollmerkmal. Push Securitys Threat-Research-Team dokumentierte einen 37,5-fachen Anstieg von Device-Code-Phishing-Seiten bis zum 4. April 2026, was auf den kommerziellen Start von EvilTokens zurückgeführt wird – eine Phishing-as-a-Service-Plattform, die Mitte Februar 2026 auf Telegram erschien. Das Besondere: Device-Code-Phishing missbraucht einen legitimen OAuth-2.0-Standard (RFC 8628), sodass keine Schwachstellen gepatcht werden müssen und keine Indikatoren in klassischer Credential-Theft-Telemetrie auftauchen – weder gestohlene Zugangsdaten noch abgefangene Session-Cookies.
Der Trick nutzt den für Geräte ohne Tastatur oder Browser konzipierten OAuth Device Authorization Grant: Ein Angreifer fordert bei Microsoft einen Gerätecode an und bringt das Opfer per Phishing-Mail dazu, diesen Code auf der echten Microsoft-Anmeldeseite einzugeben. Der Angriff hebelt MFA nicht aus, er leitet sie um: Das Opfer durchläuft eine echte, MFA-verifizierte Authentifizierung auf legitimer Microsoft-Infrastruktur, doch die resultierenden Tokens werden dem Client des Angreifers zugeteilt statt dem Gerät des Opfers. Bereits bekannt wurde die Technik durch die russische Gruppe Storm-2372, die seit August 2024 Köder nutzte, die Messaging-App-Erlebnisse wie WhatsApp, Signal und Microsoft Teams imitierten. Mit EvilTokens wurde daraus ein Massenphänomen: Eine im März 2026 gestartete Kampagne kompromittierte Sektoren wie Bauwesen, Non-Profit-Organisationen, Immobilien, verarbeitendes Gewerbe, Finanzdienstleistungen, Gesundheitswesen, Rechtswesen und Behörden in fünf Ländern. Auffällig ist auch die Infrastrukturwahl: Die Angreifer missbrauchten Railway.com, eine Developer-PaaS-Plattform, als Token-Harvesting-Engine und nutzten deren sauberen IP-Ruf, um Microsofts Risikobewertung zu umgehen.
Warum die klassische Forensik hier blind ist
Für Incident Responder ist das eine neue Kategorie von Problem. Es gibt keine mehrfachen fehlgeschlagenen Logins, keine Änderungen an Zugangsdaten, keine verdächtige Objekterstellung – das einzige potenzielle Signal ist ein nicht-interaktiver Token-Refresh von einer unerwarteten IP, und auch nur, wenn man gezielt danach sucht. Anders als bei klassischem Adversary-in-the-Middle-Phishing über Reverse-Proxys wie EvilProxy, das Sessions durch einen Reverse-Proxy abfängt und Cookies nach der MFA erbeutet – wofür Domains, Zertifikate und aktive Server nötig sind, die alle eine forensische Spur hinterlassen, bleibt beim Device-Code-Angriff schlicht keine Angreiferinfrastruktur übrig, die man untersuchen könnte.
Der zentrale forensische Ansatzpunkt liegt in den Entra-ID-Sign-in-Logs: Jeder Sign-in mit AuthenticationProtocol == “deviceCode” sollte als verdächtig markiert und untersucht werden. Wichtig dabei: Security-Teams müssen auch die nicht-interaktiven Sign-in-Logs überwachen – die Token-Refresh-Aktivität des Angreifers erscheint ausschließlich dort, und viele SOCs prüfen diese nicht routinemäßig. Post-Compromise-Verhalten folgt oft einem klaren Muster: In einigen Fällen registrierten Angreifer innerhalb von zehn Minuten nach dem initialen Breach neue Geräte unter dem kompromittierten Konto, um einen Primary Refresh Token zu generieren – der langfristigen, SSO-fähigen Zugriff bietet und einzelne Token-Widerrufe überlebt. Anschließend folgt gezielte Aufklärung: Mit den gestohlenen Tokens fragten Angreifer die Microsoft-Graph-API ab, um interne Organisationsstrukturen, Nutzerrollen und Berechtigungszuweisungen automatisiert zu kartieren.
Remediation: Warum Passwort-Reset nicht reicht
Der wichtigste forensische und operative Fallstrick betrifft die Nacharbeit. Ein Nutzer, dessen Passwort nach einem Phishing-Vorfall zurückgesetzt wird, behält einen ausstehenden, vom Angreifer gehaltenen Refresh Token, der für sein volles Zeitfenster gültig bleibt, sofern er nicht explizit widerrufen wird – die häufigste erste IR-Maßnahme, der Credential-Reset, stellt somit keine Behebung des Device-Code-Phishing-Kompromisses dar. Notwendig ist der gezielte Aufruf der Microsoft-Entra-API: Der revokeSignInSessions-Endpunkt invalidiert alle aktiven Refresh Tokens eines Kontos; sein Fehlen in Standard-Credential-Reset-Prozeduren stellt bei vielen Organisationen wahrscheinlich eine strukturelle Lücke im Incident-Response-Workflow dar. Selbst dieser Schritt ist nicht sofort wirksam: Beobachtungen aus jüngeren Kampagnen zeigen, dass eine Standard-Session-Widerrufung oft nur Refresh Tokens invalidiert, während bestehende Access Tokens bis zu einer Stunde aktiv bleiben – Microsoft empfiehlt daher, das betroffene Konto vorübergehend zu deaktivieren, um sofortige Eindämmung zu gewährleisten.
Verschärft wird die Lage durch Automatisierung auf Angreiferseite: EvilTokens integriert Large Language Models – Metas Llama 3.1 und 3.3 sowie OpenAIs GPT-4o mini – um Post-Compromise-E-Mail-Triage und BEC-Szenarien automatisiert zu generieren, wodurch Token-Diebstahl mit KI-gestützter Monetarisierung in Maschinengeschwindigkeit gekoppelt wird. Für DFIR-Teams bedeutet das: Playbooks müssen Token-Forensik, nicht-interaktive Logs und expliziten Token-Widerruf als Standardschritte enthalten – sonst bleibt der Angreifer, unsichtbar für jede klassische Post-Incident-Prüfung, munter im Postfach sitzen.
← Zurück zur Übersicht