Token-Spraying in Microsoft 365: Warum MFA allein nicht reicht

Kategorien: Datenschutz

Ein Versuch zeigt, dass MFA gestohlene Sitzungen nicht verhindert: Über 200.000 fehlgeschlagene Anmeldeversuche, 497 erfolgreiche Anmeldungen, und Mails zu Gehalt und Bonus verschwinden in versteckten Regeln. Im Mittelpunkt stehen die Fragen, woran sich das erkennen lässt, warum die große Verbreitung der Plattform den Angriff lohnend macht und was im Ernstfall zuerst zu tun ist.

Worum es bei Token-Spraying geht

Token-Spraying in Microsoft 365 ist der Name für ein Verfahren, das der Sicherheitsanbieter Huntress in einer Kampagne beobachtet hat. Angreifer erraten dabei keine Passwörter. Sie stehlen Sitzungs-Token, nachdem sich ein Mitarbeiter ordnungsgemäß mit Passwort und Multi-Faktor-Authentifizierung (MFA) angemeldet hat, und spielen diese Token kurz darauf von eigener Infrastruktur aus wieder ein. Der Name ist an das Password Spraying angelehnt, bei dem ein Passwort gegen viele Konten probiert wird. Hier werden gestohlene Anmeldenachweise breit gestreut und wiederverwendet.

Die Angaben zur Kampagne stammen von Huntress und aus einem Bericht von The Hacker News. Sie beruhen auf Beobachtungen bei Kunden eines Sicherheitsanbieters und sagen nichts über alle Mandanten aus.

Token-Spraying in Microsoft 365: Was Huntress beobachtet hat

Huntress beschreibt die Kampagne im Bericht Token Replay and Spray. Das genaue Veröffentlichungsdatum des Berichts ist nicht gesichert, belegt ist der Beobachtungszeitraum vom 14.07.2026 bis zum 22.09.2026. In dieser Zeit sah Huntress Angriffe auf 79 Organisationen, mehr als 200.000 fehlgeschlagene Anmeldeversuche und 497 erfolgreiche Anmeldungen. Mindestens 48 gefälschte Geräte wurden in Entra-Verzeichnissen angelegt. In 19 Organisationen wurden vorhandene MFA-Methoden entfernt und durch eine neue ersetzt.

Die Zahl von 97 kompromittierten Konten nennt nach vorliegendem Stand nur The Hacker News. Sie ließ sich im Huntress-Bericht nicht bestätigen und wird deshalb hier als Angabe dieses Berichts geführt. Die Zahlen für die einzelnen Angriffswellen weichen in der Huntress-Darstellung zudem leicht voneinander ab. Für eine Einordnung genügt die Größenordnung: Mit 79 betroffenen Organisationen, 497 erfolgreichen Anmeldungen und mehreren Angriffswellen über rund zehn Wochen handelte es sich nicht um einen Einzelfall, sondern um eine Serie.

Wie sich Token-Spraying von Password Spraying unterscheidet

Beim Password Spraying fallen viele Fehlversuche auf, denn die meisten Passwörter sind falsch. Beim Token-Spraying sind die Anmeldenachweise gültig. Die Fehlversuche in der Kampagne kamen laut Huntress aus Netzen der Angreifer, ein großer Teil von einem Hoster in Deutschland. Das sagt nichts über andere Kunden dieses Anbieters. Eine Sperre einzelner Adressen hilft außerdem wenig, weil die Angreifer ihre Adressen in Wellen wechselten und zwischen den Wellen ein bis zwei Wochen Ruhe herrschte.

Wie Token-Replay die MFA aushebelt

Das Verfahren wird auch Token-Replay genannt, also das erneute Abspielen eines gestohlenen Tokens. Der Ablauf lässt sich in vier Schritten beschreiben.

1. Köder: Ein Mitarbeiter erhält eine Phishing-Mail oder wird per Social Engineering auf eine fremde Seite gelenkt. Wie solche Mails Vertrauen erschleichen, beschreibt der Beitrag zur Echtheit elektronischer Nachrichten.
2. Abfangen: Ein Adversary-in-the-Middle-Relay (AiTM) steht zwischen Mitarbeiter und echter Microsoft-Anmeldeseite. Passwort und MFA-Abfrage laufen durch das Relay, und dieses speichert anschließend das Token. Beim Device-Code-Phishing wird das Opfer stattdessen dazu gebracht, einen Code auf der echten Microsoft-Seite einzugeben, mit dem sich der Angreifer ein Token holt.
3. Wiederverwendung (Replay): Wenige Minuten bis etwa eine Stunde später nutzt der Angreifer das Token von eigenen Servern. Weder Passwort noch eine zweite MFA-Abfrage sind nötig.
4. Verfestigung: Der Angreifer registriert eine eigene Authenticator-App, entfernt bestehende MFA-Methoden oder legt ein gefälschtes Gerät an. Beides übersteht eine Passwortänderung.

Wichtig ist die Einordnung: Die MFA wurde nicht geknackt. Sie wurde vom Mitarbeiter korrekt ausgeführt. Gestohlen wird das Ergebnis, das Token. Deshalb lässt sich MFA hier nur dann umgehen, wenn das Token auch außerhalb des Geräts des Mitarbeiters funktioniert. Codes, SMS und Push-Bestätigungen helfen gegen das Erraten von Passwörtern, nicht aber gegen diese Art des Diebstahls.

Huntress fand zwei Werkzeugfamilien. Die eine ist ein Skript, das sich mit dem User-Agent „node“ meldet und Token-Anfragen über die Office- und Authentication-Broker-Anwendungen stellt. Die andere spielt Browser-Sitzungen ab. Anmeldungen der zweiten Art sehen aus wie gewöhnliche Browser-Zugriffe und fallen entsprechend weniger auf.

Monokultur Microsoft: Warum Microsoft 365 das lohnendste Ziel ist

Microsoft 365 ist in Deutschland und weltweit in unzähligen Betrieben im Einsatz. Aus Sicht der Angreifer ist das ein wirtschaftliches Argument: Ein Angriff, der einmal gebaut wurde, lässt sich gegen sehr viele Mandanten wiederholen. Die Anmeldeseiten sehen überall gleich aus, die Anwendungskennungen sind dieselben, die Fehlercodes ebenfalls. Was bei einem Betrieb funktioniert, funktioniert mit kleinen Anpassungen bei vielen weiteren.

Die Kampagne zeigt diese Skalierung. Gestohlene Token wurden automatisiert und binnen Minuten verwendet, verteilt über 79 Organisationen. Die Angreifer priorisierten laut Huntress nicht nach der Zahl der Fehlversuche, sondern danach, wo gültige Anmeldedaten vorlagen. Das ist die Arbeitsweise eines Massengeschäfts, nicht die einer gezielten Operation gegen einen einzelnen Betrieb.

Verbreitung ist der Verstärker, nicht die alleinige Ursache

Das ist keine Pauschalverurteilung. Microsoft liefert die Gegenmittel selbst: Conditional Access, Security Defaults und Token Protection. Das Risiko entsteht, wenn diese Werkzeuge nicht oder nur teilweise genutzt werden. Angreifer richten ihre Automatisierung auf die Voreinstellungen aus, weil diese bei den meisten Mandanten gelten. Jede Abweichung, etwa eine gerätegebundene Anmeldung oder ein gesperrter Device-Code-Flow, kostet Angreifer Aufwand und nimmt der Massenverwertung die Grundlage.

Auch die Verbreitung von Copilot und weiteren Diensten hinter denselben Konten vergrößert den Hebel eines übernommenen Kontos. Eine kritische Einordnung dazu liefert der Beitrag Copilot unter der Lupe. Ein einzelnes Konto öffnet in Microsoft 365 Mail, Dateien, Kalender und Chat zugleich.

Lohnbetrug als Ziel: Was nach der Übernahme geschieht

Nach der Übernahme legten die Angreifer in der Kampagne versteckte Posteingangsregeln an. Diese verschoben oder löschten Mails mit Begriffen aus dem Zahlungsverkehr, etwa zu Gehalt, Einzahlungen oder Bonus. Die Zielordner trugen unauffällige Namen wie „RSS Feeds“ oder „Conversation History“. In einem Fall wurde eine Gehaltsmail an einen externen Steuerberater gesendet. Antworten wurden als gelesen markiert und weggeschoben, damit das Opfer sie nicht bemerkt.

Dahinter steht Business E-Mail Compromise (BEC): Es geht darum, Überweisungen umzuleiten oder Gehaltskonten ändern zu lassen. In einem anderen Fall wurde ein Postfach für den Versand von Spam an Hunderte externe Empfänger missbraucht, bis Entra ID Protection das Konto als hochriskant einstufte.

Für kleine Betriebe ist das besonders heikel. In Buchhaltung und Personalstelle arbeiten oft nur wenige Personen. Ein geändertes Konto fällt spät auf, und die Lohnabrechnung läuft häufig über Dritte. Die Geschäftsführung entscheidet dann über den Rückruf von Zahlungen und die Information von Bank, Steuerberater und Lohnbüro. Das gehört in den Notfallplan, nicht erst in die Krise.

Typische Spuren: neue Authenticator-App, unbekannte Entra-Geräte, Posteingangsregeln

Die Kampagne hinterlässt Spuren in Microsoft Entra ID, der Benutzerverwaltung hinter Microsoft 365, die sich ohne Spezialwerkzeug prüfen lassen. Die folgende Tabelle fasst die wichtigsten zusammen. Die Namensmuster stammen aus dem Huntress-Bericht und können sich ändern.

Der Fehlercode 53003 verdient Beachtung. Eine Blockade durch Conditional Access gilt gewöhnlich als Erfolg der Richtlinie. Sie zeigt aber auch, dass jemand außerhalb des Betriebs gültige Anmeldedaten oder ein gültiges Token besitzt. Ein solcher Eintrag ist ein Anlass, das Konto zu prüfen. Posteingangsregeln, die per Programmierschnittstelle angelegt wurden, erscheinen in der Oberfläche nicht immer. Sichtbar werden sie über das Exchange Admin Center oder PowerShell.

Kleine Betriebe ohne Protokollüberwachung sehen vieles erst im Nachhinein. Wie lange Anmeldeprotokolle aufbewahrt werden, hängt von der Lizenz ab und sollte vorab geklärt sein, denn ohne Protokoll bleibt der Umfang eines Vorfalls offen.

Conditional Access: Device-Code-Flow sperren und MFA für alle Client-Typen

Der Device-Code-Flow ist ein Anmeldeverfahren für Geräte ohne Tastatur oder Browser. Angreifer missbrauchen ihn im Device-Code-Phishing, indem sie Nutzer dazu bringen, einen Code auf einem anderen Gerät einzugeben. Microsoft empfiehlt in der Dokumentation zum Blockieren von Authentifizierungsabläufen, möglichst nahe an eine vollständige Sperre zu kommen und den Flow nur in gut dokumentierten Ausnahmen zuzulassen, etwa für Altwerkzeuge, die sich nicht aktualisieren lassen.

Die Richtlinie wird im Entra Admin Center unter Entra ID, Conditional Access, Richtlinien angelegt. Als Bedingung dient „Authentifizierungsabläufe“ mit der Auswahl „Device code flow“, als Zugriffssteuerung „Zugriff blockieren“. Microsoft empfiehlt, die Richtlinie zuerst im Modus „Nur Bericht“ laufen zu lassen und erst danach zu aktivieren. Ausgenommen werden zwei Notfallkonten, deren Liste regelmäßig zu prüfen ist.

Lizenz: Conditional Access oder Security Defaults

Conditional Access erfordert nach Microsoft Learn mindestens Microsoft Entra ID P1 (Voraussetzung laut Dokumentation zu Authentifizierungsstärken). Betriebe ohne diese Lizenz haben die Security Defaults, die laut Microsoft keine Lizenz erfordern. Zu den dort aufgeführten Schutzmaßnahmen gehören die MFA-Registrierung für alle Benutzer, das Blockieren von Altprotokollen und das Blockieren des Device-Code-Flows. Außerdem schreibt Microsoft, dass ab dem 01.07.2026 alle neuen Entra-Mandanten den Device-Code-Flow im Rahmen der Security Defaults blockieren. Die Security Defaults lassen sich laut Microsoft nicht anpassen, nur ein- oder ausschalten. Wer Ausnahmen oder feinere Regeln braucht, benötigt Conditional Access.

MFA für alle, ohne Ausnahmen für Apps oder Clients

Eine Basisrichtlinie sollte MFA für alle Benutzer, alle Ressourcen und alle Client-Typen verlangen oder den Zugriff sperren. Genau diese Forderung steht im Huntress-Bericht, und Lücken entstehen häufig durch gut gemeinte Ausnahmen, etwa „nur für Admin-Portale“ oder „nur im Browser“. Altprotokolle wie IMAP, POP3 und SMTP-Authentifizierung kennen keine MFA und gehören gesperrt.

Gegen das Abfangen durch AiTM schützen phishing-resistente Verfahren wie FIDO2-Sicherheitsschlüssel oder Windows Hello for Business deutlich besser als Codes, SMS oder Push-Bestätigungen. Microsoft nennt als Merkmal der Stufe „Phishing-resistente MFA“ eine Interaktion zwischen Authentifizierungsmethode und Anmeldeoberfläche (Authentifizierungsstärken). Eine ausdrückliche Aussage zu AiTM enthält diese Seite nicht, die Einordnung ist daher eine Schlussfolgerung des Autors. Wie sich eine Basisrichtlinie mit Authentifizierungsstärke anlegt, beschreibt die Seite MFA für alle Benutzer. Sinnvoll ist, bei Administratoren zu beginnen.

Token-Schutz und seine Grenzen

Token Protection ist eine Sitzungssteuerung in Conditional Access. Sie akzeptiert nur Anmelde-Token, die kryptografisch an ein registriertes Gerät gebunden sind. Ein gestohlenes Token funktioniert dann auf einem anderen Gerät nicht. Laut Microsoft Learn (Stand der Seite August 2026) ist die Funktion für native Anwendungen unter Windows, iOS, iPadOS und macOS allgemein verfügbar und gilt für Exchange Online, SharePoint Online und Teams. Windows 365 und Azure Virtual Desktop kommen unter Windows hinzu. Eine eigene Lizenzangabe enthält die Seite nicht, die Lizenzanforderung ist daher gesondert zu klären. Als Funktion von Conditional Access setzt Token Protection nach eigener Ableitung des Autors mindestens Entra ID P1 voraus. Das ist kein Zitat von Microsoft.

Die Grenzen sind klar benannt. Browserbasierte Anwendungen werden nur in einer Vorschau und nur für ausgewählte Web-Apps unterstützt, die Azure Resource Manager nutzen. Outlook im Web ist damit nicht abgedeckt. Zudem müssen Geräte bei Entra registriert, eingebunden oder hybrid eingebunden sein. Bei Apple-Geräten sind verwaltete Geräte mit Single-Sign-On-Erweiterung nötig. Für Betriebe mit privaten Geräten ist das eine echte Hürde.

Token Protection mindert Token-Replay, schließt das Risiko aber nicht. Microsoft empfiehlt eine Pilotgruppe, den Modus „Nur Bericht“ und die Auswertung der Anmeldeprotokolle vor einer breiten Einführung. Ergänzend helfen ein konformes Gerät als Zugriffsbedingung, die Einschränkung der Zustimmung zu neuen Apps und die regelmäßige Prüfung neuer Unternehmensanwendungen. Phishing-resistente MFA und gerätebezogene Zugriffe verringern das Risiko, die Überwachung erkennt, was trotzdem durchkommt.

Notfallablauf: Sitzungen widerrufen, Geräte und MFA-Methoden bereinigen

Die folgende Reihenfolge ist eine Empfehlung des Autors, abgeleitet aus der Microsoft-Dokumentation zum Widerruf von Zugriffen und dem Huntress-Bericht. Sie ist keine behördliche Vorgabe. Der allgemeine Ablauf nach einem erfolgreichen Angriff ist im Beitrag Ransomware: Ablaufplan für die ersten 60 Minuten beschrieben und lässt sich in Teilen übertragen.

1. Konto sperren und Sitzungen widerrufen: Im Entra Admin Center unter Benutzer wird „Konto aktiviert“ abgewählt und „Sitzungen widerrufen“ gewählt, per PowerShell mit Revoke-MgUserSignInSession. Neue Token werden dadurch verhindert.
2. Passwort zurücksetzen: In hybriden Umgebungen empfiehlt Microsoft, das Passwort im lokalen Active Directory zweimal zurückzusetzen. Danach werden Sitzungen erneut widerrufen.
3. MFA-Methoden prüfen: Unbekannte Methoden, besonders eine neue Authenticator-App, werden entfernt. Die Einrichtung durch den echten Nutzer erfolgt erst danach und möglichst mit Rückbestätigung per Telefon.
4. Geräte prüfen: Unbekannte registrierte Geräte werden deaktiviert und gelöscht. Sie sind ein Hinweis auf Persistenz.
5. Postfach bereinigen: Regeln, Weiterleitungen, Delegierungen und Transportregeln werden geprüft und entfernt. Gesendete und gelöschte Elemente werden nach Auffälligkeiten durchgesehen.
6. Apps prüfen: Unbekannte Unternehmensanwendungen und App-Einwilligungen werden entfernt.
7. Umfang klären: Anmeldeprotokolle ab dem frühesten verdächtigen Zeitpunkt werden ausgewertet. Auch andere Konten derselben Abteilung kommen in Betracht, denn die Kampagne betraf oft mehrere Konten je Organisation.
8. Geschäftsfolgen klären: Wurden Bankverbindungen, Gehaltsdaten oder Rechnungen verändert? Bank, Steuerberater und Lohnbüro werden informiert, Zahlungen angehalten, Änderungswünsche telefonisch rückbestätigt. Das entscheidet die Geschäftsführung.
9. Meldepflicht bewerten: Ob eine Meldung an die Aufsichtsbehörde nötig ist, hängt vom Risiko ab. Die Frist beträgt 72 Stunden nach Kenntnis (Artikel 33 DSGVO). Das ist keine Rechtsberatung.

Warum der Widerruf nicht sofort wirkt

Nach Microsoft sind Access-Token standardmäßig eine Stunde gültig. Der Widerruf sperrt neue Token und macht Refresh-Token ungültig, bereits ausgestellte Access-Token laufen aber bis zu ihrem Ablauf weiter. Bei Anwendungen mit eigenen Sitzungscookies muss die Anwendung selbst den Zugriff beenden. Die kontinuierliche Zugriffsauswertung (Continuous Access Evaluation, CAE) verkürzt diese Zeit bei Exchange Online, SharePoint Online und Teams auf wenige Minuten, nach Microsoft mit einer Verzögerung von bis zu 15 Minuten. Huntress beschreibt, dass Access-Token bis zu rund 90 Minuten gültig blieben und ein Passwort-Reset allein weder Fake-Geräte noch MFA-Methoden entfernt. Beides gehört zusammen: Der Klick auf „Sitzungen widerrufen“ ist ein Anfang, kein Abschluss.

Was Admins und Geschäftsführer diese Woche prüfen können

• Ist der Device-Code-Flow gesperrt oder sind die Security Defaults aktiv?
• Verlangt eine Richtlinie MFA für alle Benutzer, Ressourcen und Client-Typen ohne App-Ausnahmen?
• Sind Altprotokolle wie IMAP, POP3 und SMTP-Authentifizierung gesperrt?
• Existieren zwei Notfallkonten, die von Richtlinien ausgenommen und getrennt gesichert sind?
• Wurden Authentifizierungsmethoden, Geräte und Posteingangsregeln in Buchhaltung und Personalstelle gesichtet?
• Ist geklärt, wer bei Verdacht entscheidet und welcher Dienstleister auch außerhalb der Geschäftszeit erreichbar ist?

Beim IT-Dienstleister zählen Reaktionszeit, Zugriff auf Protokolle, Kenntnis der Richtlinien und eine schriftliche Dokumentation der Ausnahmen. Ein externer Blick auf die Konfiguration kann sinnvoll sein, etwa durch die Security-Checks. Auch die eigene Website und die Mail-Domain gehören zur Angriffsfläche. Der Webseiten-Check betrachtet die Außensicht der Website, prüft aber keine Entra-Einstellungen.

Die Verbreitung macht Microsoft 365 zum Standardziel. Wer die Voreinstellungen schärft, Geräte und Methoden im Blick behält und den Notfall vorab durchspricht, nimmt der Automatisierung die Grundlage. Nüchtern betrachtet ist das weniger eine Frage von Panik als von Konfiguration und Routine.