Knight Office zeigt, warum gestohlene Microsoft-365-Sitzungen ein Identitätsvorfall sind

Knight Office macht deutlich: MFA bestätigt eine Anmeldung, schützt aber nicht zwangsläufig jede Sitzung, die danach entsteht. In dem von Huntress untersuchten Vorfall fing ein Adversary-in-the-Middle-Angriff (AiTM) Sitzungsmaterial von Microsoft 365 ab. Danach registrierten die Angreifer ein nicht autorisiertes Gerät in Microsoft Entra ID. Operativ ist das deshalb kein bloßer Passwortdiebstahl, sondern ein Identitätskompromittierungsfall. 640

So lief die Angriffskette ab

Am Anfang stand eine DocuSign-ähnliche Phishing-Mail. Der Link führte zunächst über einen Trackingdienst von Monday.com und danach über eine kompromittierte Joomla-Website. Damit wurde das eigentliche Phishing-Ziel vor Reputationsprüfungen und einer einfachen Linkanalyse verborgen. 6

Beim AiTM-Verfahren sitzt ein Reverse Proxy zwischen Opfer und dem echten Microsoft-Anmeldedienst:

1. Das Opfer gibt seine Zugangsdaten ein und schließt die MFA-Abfrage regulär ab.
2. Der Proxy leitet diese Schritte in Echtzeit an Microsoft weiter.
3. Nach erfolgreicher Anmeldung fängt der Angreifer das an den Browser ausgegebene Sitzungscookie oder anderes Tokenmaterial ab.
4. Dieses bereits authentifizierte Sitzungsmaterial wird über die Infrastruktur des Angreifers wiederverwendet, um auf das Konto zuzugreifen.

Das ist kein Brechen der MFA-Kryptografie. Gestohlen wird vielmehr der Autorisierungszustand, den Microsoft nach der MFA-Prüfung ausgestellt hat. Microsoft definiert Token-Diebstahl entsprechend als Kompromittierung und Wiederverwendung von Tokens eines Nutzers, der die Mehrfaktorauthentifizierung möglicherweise bereits erfüllt hat. 40

Warum ein Passwort-Reset den Vorfall nicht zwingend beendet

Eine gestohlene Browsersitzung oder ein Zugriff über Refresh-Token kann Angreifern weitere Aktivitäten ermöglichen, ohne dass erneut ein Passwort oder eine MFA-Bestätigung abgefragt wird – bis die betroffenen Tokens widerrufen werden. Microsoft empfiehlt bei Token-Diebstahl ausdrücklich, betroffene Nutzer oder Geräte zu sperren und aktuelle Tokens zu widerrufen. 40

Bei Knight Office verschärft die beobachtete Folgeaktivität das Risiko: Laut Huntress wurde ein nicht autorisierter Host in Microsoft Entra ID aufgenommen und eine von Angreifern kontrollierte Windows-Hello-for-Business-Anmeldung eingerichtet. 6 Dadurch kann ein zusätzlicher Anmeldeweg entstehen. Selbst wenn die ursprüngliche Websitzung widerrufen oder das Passwort zurückgesetzt wurde, müssen Verantwortliche daher prüfen, ob unautorisierte Geräte oder neue Anmeldemethoden zurückbleiben.

Ein vergleichbarer Persistenzmechanismus ist aus der Forschung zu Device-Code-Phishing bekannt. Microsoft berichtete, dass ein über einen missbrauchten Device-Code-Flow erlangtes Refresh-Token für den Zugriff auf die Geräteregistrierung und zur Anmeldung eines vom Angreifer kontrollierten Geräts in Entra ID verwendet werden kann. 28

Device-Code-Phishing ist verwandt, aber nicht dasselbe wie AiTM

AiTM-Phishing vermittelt eine laufende Anmeldung und stiehlt die daraus resultierende Sitzung. Device-Code-Phishing missbraucht dagegen einen legitimen OAuth-Autorisierungsablauf für Geräte: Der Angreifer startet die Anfrage, verleitet das Opfer zur Eingabe eines Codes und zur Anmeldung und erhält Tokens für seinen kontrollierten Client, sofern das Opfer die Freigabe erteilt. 22

Beide Verfahren verfolgen dasselbe Ziel: nicht nur Passwörter, sondern direkt nutzbare Autorisierungsartefakte zu erlangen. Erkennungsprogramme sollten daher beide Wege abdecken. Die Erkennungsregel von Elastic verweist bei Device-Code-Anmeldungen auf erfolgreiche interaktive Entra-Anmeldungen mit dem Microsoft Authentication Broker sowie Anfragen an Microsoft-eigene Ressourcen wie Exchange Online, Microsoft Graph oder SharePoint. 17

Knight Office im Kontext von Phishing-as-a-Service

Die Huntress-Untersuchung dokumentiert für Knight Office eine reale Angriffskette aus Dokumentenköder, mehrstufigen Umleitungen, Abgriff von Sitzungstokens und nicht autorisierter Entra-Geräteregistrierung. Wiederholte Token-Wiedergaben in der Huntress-Telemetrie wurden einer einzelnen IP-Adresse zugeordnet. Daraus lässt sich jedoch keine globale Zahl betroffener Opfer ableiten. 6

Knight Office passt in einen wachsenden Markt für Phishing-as-a-Service-Kits, die auf Microsoft-365-Identitäten und Sitzungen zielen:

• Mirage2FA nutzt AiTM-Infrastruktur zum Abgriff von Zugangsdaten und authentifizierten Sitzungen. ANY.RUN meldete für 2024 bis 2026 insgesamt 9.332 potenzielle Kompromittierungsereignisse, darunter 4.561 Cookie-Diebstähle. Diese Werte stammen aus Telemetrie und sind keine bestätigte Opferzahl. 4
• Kali365 wurde erstmals im April 2026 beobachtet und vor allem über Telegram verbreitet. Das FBI warnte, dass das Kit Microsoft-365-OAuth-Zugriffs- und Refresh-Tokens erlangen kann. 1

Die gemeinsame Lehre: Sitzungs- und Tokenmissbrauch muss mit derselben Priorität behandelt werden wie ein Passwortkompromittierung.

Wichtige Detektionssignale in Entra ID und Microsoft 365

Entscheidend sind Korrelationen – nicht ein einzelner Alarm.

Verdächtige Wiederverwendung von Sitzungen erkennen

Untersucht werden sollten Anmeldungen, bei denen dasselbe Konto oder dieselbe Sitzung kurz nacheinander mit deutlich abweichenden IP-Adressen, Netzen, Regionen, Browsern oder Geräteeigenschaften auftaucht – besonders direkt nach einer erfolgreichen MFA-Abfrage. Microsoft verweist auf Erkennungen für anomale Tokennutzung und unbekannte Anmeldeeigenschaften bei Sitzungscookies. 38

Device-Code-Aktivitäten prüfen

Erfolgreiche Device-Code-Anmeldungen sollten daraufhin bewertet werden, ob Client, Quell-IP, angeforderte Ressource und Nutzerverhalten plausibel sind. In Entra-Anmeldeprotokollen können entsprechende Vorgänge unter anderem über authenticationProtocol: deviceCode und originalTransferMethod: deviceCodeFlow sichtbar sein. 26

Persistenzänderungen priorisieren

Besondere Aufmerksamkeit verdienen Entra-Audit-Ereignisse zu:

• neuen Geräteregistrierungen, Geräte-Joins, Eigentümerwechseln oder ungewöhnlichen Gerätekennungen;
• neu hinzugefügten Methoden für Windows Hello for Business, FIDO2/Passkeys, MFA oder Kontowiederherstellung;
• Einwilligungen für Anwendungen, Änderungen an Enterprise Applications, Service Principals oder privilegierten Rollen;
• Änderungen an Conditional Access, Named Locations, Föderation, Mailweiterleitungen und Posteingangsregeln.

Eine nicht autorisierte Geräteregistrierung direkt nach einer auffälligen Anmeldung ist ein hochprioritäres Signal für Identitätspersistenz. 2628

E-Mail- und Identitätsdaten zusammenführen

Eine DocuSign-ähnliche Nachricht allein kann Spam sein, ein neues Entra-Gerät allein legitim. Die Kombination aus verdächtiger E-Mail, Redirect-Kette, erfolgreicher MFA, anomaler Sitzungswiederverwendung sowie einer Geräte- oder Anmeldemethodenänderung ist erheblich aussagekräftiger.

Incident Response: Nicht nur das Passwort, sondern die Identität eindämmen

Bei einem vermuteten AiTM- oder Device-Code-Token-Diebstahl sollte das Team nach einem Identitäts-Containment-Plan vorgehen:

1. Betroffene Identität bei Bedarf sperren oder deaktivieren. Nutzer- und Gerätekonten zunächst deaktivieren, während Umfang und Ursache geklärt werden. 40
2. Aktuelle Sitzungen und Refresh-Tokens widerrufen. Den Entra-Prozess zur Sitzungswiderrufung verwenden und eine erneute Anmeldung erzwingen. Für Device-Code-Phishing empfiehlt Microsoft ausdrücklich revokeSignInSessions. 27
3. Passwort zurücksetzen – aber dort nicht aufhören. Ein Passwort-Reset ist eine ergänzende Maßnahme, kein Nachweis dafür, dass der Angreifer keinen Zugriff mehr hat. 4042
4. Persistenz entfernen. Nicht autorisierte Entra-Geräte identifizieren und entfernen, Gerätebesitz prüfen, kürzlich ergänzte Methoden für Windows Hello for Business, FIDO2, MFA, Wiederherstellung und Anwendungen entfernen sowie Einwilligungen kontrollieren. 628
5. Tenantweit suchen. Nach gleichen Köder-URLs, Umleitungsinfrastruktur, auffälligen Quell-IP-Adressen, Device-Code-Ereignissen, Anomalien nach MFA und neuen Geräteregistrierungen bei allen Nutzern suchen.
6. Geschäftliche Auswirkungen bewerten. Auditdaten zu Exchange, SharePoint, OneDrive, Teams, Microsoft Graph, OAuth und administrativen Vorgängen auf Datenzugriffe, Postfachregeln, Weiterleitungen, externes Teilen, missbräuchliche Einwilligungen, Rechteausweitungen und SSO-verbundene Anwendungen prüfen.
7. Beweise vor der Bereinigung sichern. Phishing-Mails und Header, Mail-Traces, Redirect-Ketten, Entra-Anmelde- und Audit-Protokolle, Geräteobjekte, OAuth-Einwilligungen sowie Browser- und Endpunkttelemetrie aufbewahren.

Exponierung vor dem nächsten Köder verringern

Phishing-resistente Anmeldungsmethoden sind insbesondere für Konten mit erhöhten Rechten wichtig, müssen aber Teil eines mehrschichtigen Schutzkonzepts sein. Microsoft nennt FIDO2-Sicherheitsschlüssel, Windows Hello for Business und zertifikatbasierte Authentifizierung; für nicht verwaltete Geräte empfiehlt das Unternehmen zusätzlich Maßnahmen, die die nutzbare Sitzungsdauer begrenzen. 39

Organisationen sollten außerdem bewerten, ob Device-Code-Flows im eigenen Umfeld nötig sind, unautorisierte Geräteregistrierungen begrenzen, Conditional Access anhand konformer Geräte und Risikosignale durchsetzen und sicherstellen, dass der Betrieb Sitzungen schnell widerrufen sowie Änderungen an Identitätsobjekten untersuchen kann.

Die zentrale Erkenntnis aus Knight Office lautet nicht, dass MFA versagt hat. Eine erfolgreiche MFA-Bestätigung kann vielmehr der Beginn der Kompromittierung sein, wenn Angreifer die danach ausgestellte Sitzung stehlen. Ein Vorfall ist erst dann vollständig eingedämmt, wenn Sitzungen, Geräte, Anmeldemethoden und delegierte Zugriffe im Tenant geprüft und bereinigt wurden.