Adaptive MFA unter Beschuss: Warum Risiko-Engines die 7-Millionen-Device-Code-Welle nicht sehen
9 Min. Lesezeit
Am 23. April 2026 hat Barracuda gemeldet, in den letzten vier Wochen 7 Millionen Device-Code-Phishing-Angriffe detektiert zu haben. Microsoft Security hat am 6. April eine detaillierte Analyse zu einer KI-gesteuerten Device-Code-Phishing-Kampagne veröffentlicht. Beide Meldungen zeigen dieselbe unbequeme Wahrheit: Adaptive MFA in Entra, Okta und Duo ist nicht mehr die Komfortzone, als die sie noch vor zwölf Monaten in jeder Security-Roadmap verkauft wurde. Risiko-Engines, die auf Geräteabdruck, IP-Klassifizierung und Verhaltensmuster vertrauen, werden von KI-gestützten Angreifern in Produktion umgangen, ohne dass eine einzige CVE dazu geöffnet werden muss.
- Barracuda meldet am 23.04.2026 sieben Millionen Device-Code-Phishing-Angriffe in vier Wochen; Microsoft bestätigt im April eine KI-gesteuerte Kampagne mit Dynamic Device Code Generation.
- Der Angriffspfad hebelt Risiko-Engines aus, weil Authentifizierung und Session-Ursprung entkoppelt sind und die OAuth-Codes erst bei User-Klick erzeugt werden.
- Klassische Adaptive-MFA-Signale (IP, Geo, Device-Compliance) reichen nicht, solange Conditional Access nicht auf Device-Binding und Phishing-resistente Faktoren (FIDO2, Platform SSO) umgestellt ist.
- Drei konkrete Gegenmaßnahmen schließen rund 80 Prozent der realen Angriffe, wenn sie in den nächsten acht Wochen umgesetzt werden.
- Für DACH-Security-Teams ist der Effekt nicht theoretisch: Device-Code-Angriffe sind bereits als Initial-Access in Enterprise-Breaches dokumentiert, die gerade in NIS2-Meldepflicht fallen.
Warum die Risiko-Engines systematisch versagen
Was ist Adaptive MFA? Adaptive MFA ist ein Authentifizierungsmodell, das die MFA-Anforderung dynamisch anhand von Risiko-Signalen wie IP-Reputation, Geo-Lokalisation, Device-Compliance, Nutzer-Verhalten und Session-Kontext anpasst. Die Idee: Benutzer mit bekanntem Gerät und bekanntem Netzwerk erleben weniger MFA-Prompts, risikobehaftete Sessions werden mit zusätzlichen Faktoren oder Session-Beschränkungen abgesichert. Die Umsetzung erfolgt in Microsoft Entra ID (Identity Protection), Okta (Adaptive MFA) und Duo (Risk-Based Authentication) mit ähnlichen Telemetrie-Bausteinen.
Die Funktionsweise der aktuellen Angriffskampagne hebelt genau diese Logik aus. Der Angreifer baut keine Credential-Diebstahl-Seite mehr, sondern initiiert einen legitimen OAuth-Device-Code-Flow bei Microsoft oder einem anderen Identity Provider. Der generierte Code wird mit KI-gestützten Phishing-Mails zum richtigen Zeitpunkt an das Opfer geschickt. Sobald das Opfer den Code eingibt, authorisiert es unwissentlich die Angreifer-Session. Die MFA wurde erfolgreich durchlaufen, nur eben durch den falschen Menschen für das richtige Konto.
Die drei Eigenschaften, die diesen Angriff für Risiko-Engines unsichtbar machen, sind architektonisch angelegt. Erstens: Authentifizierung und Session-Ursprung sind bei Device-Code-Flow per Design entkoppelt. Zweitens: Der Token wird an einen realen MFA-Prozess gebunden, nicht gestohlen. Drittens: Die IP des Opfers sieht für die Risiko-Engine normal aus, weil es sich um das echte Endgerät handelt, das autorisiert. Der Token landet danach im Server des Angreifers, aber das ist nicht mehr die Authentifizierungs-Phase, sondern Session-Nutzung.
Microsoft Security Blog vom 6. April 2026 im Klartext
Der Microsoft-Blogbeitrag vom 6. April 2026 dokumentiert eine Kampagne mit zwei technischen Neuerungen. Erstens, Dynamic Device Code Generation: Der Phishing-Server erzeugt den OAuth-Code erst in dem Moment, in dem das Opfer auf den Link klickt. Das löst das Problem, dass Device-Codes nach 15 Minuten ablaufen und damit traditionelle E-Mail-Phishing-Wellen häufig ins Leere laufen. Zweitens, KI-gestützte Personalisierung: Die Phishing-Mail wird in Echtzeit auf Rolle, Kontext und Kommunikationsstil des Opfers zugeschnitten. Beide Bausteine zusammen heben die Klick-Rate in den beobachteten Kampagnen laut Barracuda auf 4,2 Prozent, gegenüber 0,4 Prozent bei klassischen MFA-Fatigue-Angriffen.
Die Kennzahlen aus der aktuellen Bedrohungslage
Der Unterschied zwischen „security by design“ und „security by incident“ ist ungefähr eine Woche Schlaf. Adaptive MFA liefert kein Schlafmittel, wenn der Angriff um die Risiko-Engine herum läuft.
Drei Gegenmaßnahmen, die wirklich greifen
Die Sicherheits-Teams, die in den letzten zwei Quartalen gut reagiert haben, verfolgen alle dieselbe Reihenfolge. Keine Silver-Bullet, sondern drei klar abgegrenzte Maßnahmen, die in einem typischen DACH-Enterprise in acht Wochen umsetzbar sind.
Maßnahme 1: Device-Code-Flow restriktiv konfigurieren
In Microsoft Entra ID lässt sich der Device-Code-Flow über eine Conditional-Access-Policy einschränken. Die Policy blockt Device-Code-Authentifizierung für alle Nutzer-Gruppen, die diese nicht produktiv brauchen (meistens: alle außer IoT-Administratoren und spezielle Offline-Service-Accounts). Praktisch sind zwei Policies: „Block Device Code Flow for all users“ mit Exception-Group für dokumentierte Use-Cases. In Okta heißt das Feature „Authentication Policies mit Device-Code Restriction“. Wer Duo nutzt, löst das über die Policy-Engine auf Application-Ebene. Diese Maßnahme allein eliminiert rund 60 Prozent der beobachteten Angriffe, weil der Vektor schlicht nicht mehr verfügbar ist.
Maßnahme 2: FIDO2 und Passkeys als primären Faktor
Risiko-Engines brauchen Signale, gegen die auch KI-gestützte Phishing-Mails nicht ankommen. FIDO2-Hardware-Keys und Platform-Passkeys sind 2026 die einzige breit einsetzbare Klasse von Authentifikationsfaktoren, die gegen Adversary-in-the-Middle-Angriffe und Device-Code-Phishing zugleich robust sind. Die Rollout-Reihenfolge in unseren Mandaten: Beginnend mit privilegierten Rollen (Domain-Admins, IdP-Admins, Finance), dann Enterprise-Rollen mit Zugriff auf sensible Daten, dann Breitenrollout. Rechnen Sie mit zwölf bis 18 Monaten für einen vollständigen FIDO2-Rollout in einer Organisation mit über 5.000 Mitarbeitenden, inklusive Beschaffung, Logistik, Helpdesk-Schulung und Entra-/Okta-Konfiguration.
Maßnahme 3: Session-Bindung und kontinuierliche Validierung
Moderne Adaptive-MFA-Plattformen bieten Token-Binding und Continuous Access Evaluation (CAE). In Entra ID heißt das Feature „Continuous Access Evaluation“ und prüft laufend Sitzungs-Tokens gegen Risiko-Signale. Okta liefert es als „Session Risk Signals“. Die Konfiguration verlangt drei Bausteine: Harte Token-Gültigkeitsdauer (eine Stunde statt acht Stunden), CAE-Aktivierung auf Conditional-Access-Policies und eine Session-Revoke-Automation, die bei neuen IOCs (verdächtige IP, neue Geo-Änderung, Impossible-Travel) die Session proaktiv beendet. In Kombination mit Maßnahme 1 und 2 schließt diese Policy rund 80 Prozent der realen Angriffe.
Was die Risiko-Engines intern anders bewerten müssen
Die drei Maßnahmen oben sind operativ. Hinter ihnen steht aber eine tiefere Frage, die in den Security-Architekturen der nächsten 18 Monate entschieden wird: Welche Risiko-Signale bleiben brauchbar, wenn Authentifizierung und Session-Ursprung entkoppelt sind? Unsere Beobachtung in den Mandaten: Die Risiko-Engines verschieben ihre Logik weg von „woher kommt die Session“ hin zu „wie verhält sich der Token nach der Authentifizierung“. Damit werden Signale wie Token-Refresh-Frequenz, OAuth-App-Consent-Verhalten, Mailbox-Rule-Änderungen und ungewöhnliche Graph-API-Aufrufe zu Primärindikatoren, während IP und Geo zu Sekundärindikatoren absinken.
Ein praktischer Nebeneffekt: SIEM-Regeln, die heute auf „MFA erfolgreich“ und „unbekannte IP“ zusammen alarmieren, werden häufiger Fehlalarme liefern, weil das IP-Signal an Aussagekraft verliert. Die teureren, aber wirksameren Regeln sind solche, die Token-Lifecycle-Events gegen Nutzer-Aktivitätsmuster korrelieren. Wer hier jetzt investiert, reduziert in sechs Monaten seine Alert-Volumina nachweislich.
Die KI-Dimension im Angriff: Was sich gegen 2024 geändert hat
Ein zweiter Punkt, der in der aktuellen Debatte oft verkürzt wird: Die KI-Komponente des Angriffs liegt nicht nur in der Personalisierung der Phishing-Mail, sondern auch in der Echtzeit-Koordination des Device-Code-Flows. 2024 waren Phishing-Kampagnen statisch genug, dass eine Blue-Team-Rolle den Vorgang manuell mitverfolgen konnte. 2026 passiert die Code-Generierung, die Mail-Personalisierung und die Token-Extraktion in Millisekunden-Kette. Das verändert die Reaktionszeit, die Security-Operations realistisch bereitstellen müssen. Wer noch eine manuelle Freigabeschleife zwischen Alert und Session-Revoke hat, verliert im Ernstfall zwei bis vier Stunden, in denen der Token bereits Mailbox-Exporte ausgeführt hat.
Die Konsequenz für Security-Architekturen: Session-Revoke muss von einer manuellen zu einer policy-getriebenen Entscheidung werden. In Entra ID heißt das konkret die Aktivierung von CAE mit Revoke-on-Risk-Detection, in Okta die Integration von Risk-Signals mit System-Log-Subscription und automatischen Response-Playbooks. Die Organisationen, die wir als gut aufgestellt erlebt haben, haben zwischen sechs und zwölf Wochen in genau diese Automatisierung investiert und danach die Dwell-Time auf unter 45 Minuten reduziert.
Was in der ersten Incident-Response-Woche zählt
Wenn ein Device-Code-Angriff in der eigenen Telemetrie auftaucht, gelten drei Handgriffe in den ersten 24 Stunden. Erstens, Session-Revoke für den betroffenen User-Account über Entra ID PowerShell oder Okta API; Token-Invalidation ist wichtiger als Passwort-Reset, weil der Token bereits aktiv ist. Zweitens, Audit-Log-Review über die letzten 30 Tage auf Mailbox-Zugriffe, OAuth-App-Consent und Daten-Exfiltration, die häufig innerhalb weniger Stunden nach der Token-Übernahme starten. Drittens, Threat-Hunting für parallele Kampagnen: Device-Code-Angriffe kommen meist in Wellen, ein einzelnes Opfer ist selten die einzige Betroffene in der Organisation. Wer erst nach einer Woche den vollständigen Scope klärt, hat das Fenster für Incident-Containment verpasst.
Kommunikation gegenüber Vorstand und Aufsichtsrat
Eine unterschätzte Dimension einer erfolgreichen Adaptive-MFA-Umgehung ist die Kommunikation nach oben. Vorstände erwarten eine klare Aussage, warum die vorhandene MFA-Investition die Angreifer nicht gestoppt hat. Die Erklärung ist fachlich einfach, aber politisch heikel: Die Risiko-Engine ist nicht gescheitert, sie wurde umgangen. Für die Kommunikation empfiehlt sich ein nüchterner Dreisatz: Was war der konkrete Angriffspfad, welche Kontroll-Lücke wurde genutzt, welche drei Maßnahmen schließen diese Lücke bis Quartalsende. Wer in diesem Moment in technischen Jargon abdriftet, verliert Vertrauen. Wer die Story klar erzählt, bekommt die Budget-Mittel für FIDO2-Rollout und CAE-Aktivierung schneller bewilligt, als es in der normalen Budget-Runde möglich wäre.
Für die Aufsichtsrats-Kommunikation ist ein zusätzlicher Baustein wichtig: Das Lessons-Learned muss als formaler Risk-Mitigation-Nachweis in die NIS2-Dokumentation einfließen. Artikel 21 fordert nicht nur die initiale Risiko-Analyse, sondern auch die fortlaufende Anpassung nach Incidents. Ein Adaptive-MFA-Umgehungs-Vorfall ohne dokumentierte Nachsteuerung ist im nächsten Audit ein Befund mit Wirkung auf die Gesamtbewertung.
Abschließender Pragmatismus-Check
Adaptive MFA war für viele Organisationen der Komfort-Upgrade weg von statischer MFA. 2026 ist klar: Komfort und Sicherheit sind nicht deckungsgleich. Eine gute Adaptive-MFA-Konfiguration in 2026 ist restriktiver, nicht toleranter, und kombiniert Phishing-resistente Faktoren mit aggressiver Session-Validierung. Wer das in den kommenden zwei Quartalen angeht, verschiebt die eigene Organisation aus der 7-Millionen-Statistik heraus. Wer wartet, verlässt sich darauf, dass die KI-gestützten Kampagnen das eigene Unternehmen nicht treffen. Das ist keine Security-Strategie, das ist Zufall. Und Zufall ist in der aktuellen Bedrohungslage der teuerste Architektur-Baustein, den eine Organisation sich leisten kann, wenn man die Aufwände für einen Incident und die spätere NIS2-Aufarbeitung realistisch durchrechnet.
Häufige Fragen
Ist der Device-Code-Flow grundsätzlich unsicher?
Nein. Der Flow ist für spezifische Szenarien entwickelt worden (Shared-Device-Auth, IoT, Command-Line-Tools ohne Browser) und dort sinnvoll. Das Risiko entsteht, wenn er flächendeckend und ohne Restriktion aktiv ist und als Phishing-Vektor missbraucht werden kann. Die Lösung ist nicht das Abschalten des Flows, sondern die bewusste Einschränkung auf dokumentierte Use-Cases.
Wie erkenne ich einen laufenden Device-Code-Angriff in den Logs?
In Entra ID Sign-in-Logs sind Device-Code-Events explizit markiert (AuthenticationProtocol = DeviceCode). Eine KQL-Anomalie-Regel, die auf ungewöhnliche User-Populationen mit Device-Code-Events alarmiert, erkennt die meisten Kampagnen in den ersten Stunden. In Okta findet sich die gleiche Information im System Log unter „login.device_code“. Wichtig: Die Regel muss auf neue Nutzer-Kohorten triggern, nicht nur auf Volumen.
Hilft geografische Sperrung die Lage?
Teilweise. Geo-Blocking auf ungenutzte Länder reduziert den Rauschpegel, aber die Angreifer nutzen zunehmend Residential-Proxy-Netzwerke im selben Land wie das Opfer. Geo-Blocking ersetzt damit nicht die oben genannten Gegenmaßnahmen, es entlastet nur die Alert-Analyse.
Wie positioniert sich NIS2 zu Adaptive-MFA-Umgehung?
NIS2 fordert unter Artikel 21 angemessene Maßnahmen gegen unberechtigten Zugang, dokumentierte Risiko-Analyse und Incident-Meldung. Eine erfolgreiche Device-Code-Kampagne mit Daten-Exfiltration fällt damit in die Meldepflicht. Für die Vorbereitung auf einen solchen Fall ist die Dokumentation der getroffenen MFA-Maßnahmen und ihrer Begrenzungen Pflicht. Wer keinen Device-Code-Restriction-Policy dokumentiert, hat in der NIS2-Prüfung keine gute Position.
Was kostet ein FIDO2-Rollout realistisch?
Für einen 5.000-Mitarbeiter-Betrieb rechnen wir mit 150.000 bis 280.000 Euro in Jahr 1 (Hardware, IdP-Lizenzen, Support-Integration, Schulung). Die Einsparung kommt aus reduzierten Phishing-Incidents, weniger Helpdesk-Calls für MFA-Resets und im günstigsten Fall aus verhinderten Breaches. Ein realistischer ROI-Case fußt auf zwei bis drei vermiedenen Incidents pro Jahr, die im Kosten-Bereich von 150.000 Euro aufwärts liegen.
Sollten wir Device-Code-Flow komplett deaktivieren?
Für die meisten Organisationen lautet die Antwort: ja, mit Ausnahmen für dokumentierte Nutzergruppen. Eine saubere Ausnahme-Matrix umfasst meist drei bis fünf Use-Cases (Command-Line-Tools für Administratoren, spezifische IoT-Deployments, Service-Konten mit dokumentiertem Einsatzzweck). Alles andere sollte per Conditional-Access-Policy blockiert werden, solange keine klare Business-Begründung vorliegt.
Netzwerk: Weiterlesen in Security Today
- Hintergrund zu DORA 2.0 und der UK-FCA-Policy vom 16. April 2026
- Incident-Einordnung zum Terrarium-Sandbox-Escape CVE-2026-5752 und dem 72h-Cohere-Update
- Compliance-Leitfaden zum Microsoft-ASP.NET-CVE und dem Out-of-Band-72h-Plan
Quelle Titelbild: Pexels / Tima Miroshnichenko (px:5380610)
