Forschende von Huntress haben eine umfangreiche Kampagne zur Kompromittierung von Microsoft 365-Konten offengelegt, bei der Angreifer gestohlene Authentifizierungs-Token erneut abspielten, anstatt Passwörter zu erraten. Nach Angaben von Huntress wurden vom 14. Juli bis 22. September 2026 bei mehr als 200.000 fehlgeschlagenen Versuchen 497 erfolgreiche Anmeldungen in den Systemen von 79 Organisationen verzeichnet. Die Angreifer registrierten außerdem mindestens 48 gefälschte Geräte in den Microsoft Entra ID-Verzeichnissen der betroffenen Unternehmen. Die Kampagne umging Multi-Faktor-Authentifizierung (MFA) und erfordert von Organisationen eine sofortige Überprüfung der registrierten Geräte, der MFA-Methoden und der Regeln für die Verarbeitung eingehender E-Mails.
Mechanismus der Attacke: vom Abfangen bis zum Replay
Die Kampagne nutzte die Technik adversary-in-the-middle (AitM) – der Angreifer platzierte eine zwischengeschaltete Anmeldeseite zwischen dem Opfer und der legitimen Microsoft-Infrastruktur. Wenn sich der Nutzer authentifiziert hatte, einschließlich der Eingabe des MFA-Codes, fing der Zwischenserver das von Microsoft ausgestellte Zugriffstoken – den „Nachweis der Anmeldung“ – ab. Dieses Token wurde anschließend von der Infrastruktur der Angreifer innerhalb weniger Minuten erneut verwendet, ohne dass eine erneute MFA-Abfrage erforderlich war.
Nach Angaben von Huntress stammten die Token aus mehreren Quellen: AitM-Relays hinter gefälschten Anmeldeseiten, Phishing über den Mechanismus von Gerätecodes (device-code phishing) und Social Engineering während eines legitimen Anmeldevorgangs. Die Forschenden nannten diesen Ansatz token spraying – in Anlehnung an password spraying, jedoch werden statt Passwörtern massenhaft gestohlene Token über zahlreiche Organisationen hinweg wiederverwendet.
Die Angriffs-Infrastruktur war in zwei Ebenen aufgeteilt: AitM-Relays zum Abfangen der Sitzungen und separate Hosts für das Replay der Token. Das Replay erfolgte aus dem Bereich 193.26.115[.]0/24, der mit dem deutschen Hosting-Anbieter 1337 Services GmbH in Verbindung steht. Über den Zeitraum von 10 Wochen nutzten die Angreifer nacheinander sechs IP-Adressen in diesem Block.
Persistenz und Post-Exploitation
Nachdem sie Zugriff erlangt hatten, verschafften sich die Angreifer umgehend eine dauerhafte Präsenz in den kompromittierten Umgebungen. Nach Daten von Huntress wurden in 19 Organisationen bestehende MFA-Methoden innerhalb von drei Stunden nach der ersten Anmeldung gelöscht und durch neue ersetzt. In einem Fall, der am 21. Juli 2026 beobachtet wurde, wurde eine neue Authentifikator-App mit dem Namen „iPhone 13“ weniger als 51 Minuten nach Übernahme der Sitzung aktiviert.
Parallel dazu registrierten die Angreifer gefälschte Geräte in den Entra-ID-Verzeichnissen der Opfer. Wie die Forschenden anmerken, bietet ein registriertes Gerät eine beständigere Möglichkeit zur Anforderung von Token als eine gestohlene Sitzung und verbleibt im Verzeichnis, bis es manuell entfernt wird.
In der Post-Exploitation-Phase legten die Angreifer versteckte Regeln für die Verarbeitung eingehender E-Mails mit Namen wie „.“, „sss“, „s“, „d“, „iT“ an. Diese Regeln löschten oder verschoben E-Mails, die Schlüsselwörter im Zusammenhang mit Gehalt, Boni und Direktüberweisungen enthielten, in wenig auffällige Ordner (RSS Feeds, Conversation History). In einem der kompromittierten Postfächer markierte eine Regel alle eingehenden E-Mails als gelesen und löschte sie, woraufhin das Postfach für den Versand von Spam an Hunderte externe Empfänger genutzt wurde.
Wirksamkeit von Conditional Access
Die Daten von Huntress zur September-Phase der Kampagne zeigen ein charakteristisches Bild: Von einer einzigen Adresse aus wurden 303 erfolgreiche Anmeldungen bei 29 Organisationen durchgeführt, während dieselbe Adresse 1.052 blockierte Versuche verzeichnete – doch sämtliche Blockierungen entfielen nur auf vier Organisationen mit konfigurierten Richtlinien für bedingten Zugriff (Conditional Access Policies). In den übrigen 29 Organisationen stand der Anmeldung nichts im Weg. Dies zeigt, dass MFA für sich genommen nicht vor Token-Replay schützt – es sind zusätzliche Richtlinien für bedingten Zugriff erforderlich.
Bezug zu früheren Kampagnen
Die beschriebene Kampagne fügt sich in einen anhaltenden Trend von Angriffen auf Microsoft-Cloud-Dienste durch Sitzungsübernahme ein. Zuvor haben wir bereits über die Kampagne Payroll Pirates, die AitM-Phishing gegen Microsoft 365 einsetzte, sowie über die Plattform NovaCookies zum Diebstahl von Microsoft-365-Sitzungen berichtet. Die aktuelle Kampagne unterscheidet sich durch den Umfang der Automatisierung und die Trennung der Infrastruktur für Abfangen und Replay, was die Erkennung erschwert.
Indikatoren einer Kompromittierung
Huntress hat die folgenden IP-Adressen veröffentlicht, die mit der Infrastruktur für das Replay von Token in Verbindung stehen:
193.26.115[.]221– Host für Replay und Registrierung von Geräten (Phase 1, Juli–August)193.26.115[.]199– Host für Sitzungs-Replay (Phase 1)193.26.115[.]16– Host für Replay und Device-Code-Phishing (Phase 2)193.26.115[.]21,193.26.115[.]72,193.26.115[.]210
Weitere mit der Kampagne verknüpfte Adressen: 124.198.132[.]33, 45.83.31[.]44, 192.159.99[.]172, 185.238.2[.]195, 167.148.41[.]96.
Empfehlungen zur Reaktion
Huntress betont, dass ein Passwort-Reset für sich genommen nicht ausreicht – er entfernt weder von Angreifern registrierte Geräte und MFA-Methoden, noch wird das Zugriffstoken ungültig, das etwa 90 Minuten nach dem Reset gültig bleibt. Empfohlene Maßnahmen:
- Alle aktiven Sitzungen widerrufen und das Passwort zurücksetzen – genau in dieser Reihenfolge
- Entra-ID-Geräte überprüfen – unbekannte Einträge vom Typ
DESKTOP-*löschen - MFA-Methoden auditieren – unbekannte Authentifikator-Apps entfernen
- Regeln für die E-Mail-Verarbeitung prüfen – nach Regeln mit einbuchstabigen oder nur aus Punkten bestehenden Namen suchen
- Registrierte Unternehmensanwendungen überprüfen und nicht autorisierte Einträge entfernen
- Richtlinien für bedingten Zugriff konfigurieren – für alle Benutzer, alle Cloud-Anwendungen und alle Typen von Clientanwendungen ausnahmslos MFA verlangen (oder blockieren)
- Device-Code-Authentifizierung über Conditional Access einschränken
Organisationen, die Microsoft 365 nutzen, sollten umgehend die Anmeldeprotokolle auf Authentifizierungen aus dem Bereich 193.26.115[.]0/24 überprüfen, einen Audit der registrierten Geräte und MFA-Methoden in Entra ID durchführen und sicherstellen, dass Richtlinien für bedingten Zugriff alle Anwendungstypen und Benutzer ohne Ausnahmen abdecken. Das Blockieren nur des Replay-IP-Bereichs beseitigt die Bedrohung nicht – die Infrastruktur zum Abfangen der Token befindet sich auf separaten Adressen, und die Angreifer wechseln ihre Hosts regelmäßig.
