BigBear-2.0-Phishing-Dienst übernahm Microsoft-365-Sitzungen bei 258 Organisationen

Eine als BigBear 2.0 bekannte Phishing-as-a-Service-Plattform kompromittierte Konten von Microsoft 365 bei 258 Organisationen. Dabei nutzte sie Adversary-in-the-Middle-Techniken, um authentifizierte Sitzungen zu stehlen, nachdem Benutzer die Multifaktor-Authentifizierung abgeschlossen hatten.

CloudSEK veröffentlichte die Erkenntnisse am 7. September 2026 um 11:39 Uhr, nachdem das Unternehmen Administratorzugriff auf die Steuerzentrale der Operation erlangt hatte. Die Forscher fanden 42 virtuelle Serverknoten, die jeweils für Angriffe auf die Microsoft-365-Authentifizierung konfiguriert waren.

Die Kampagne sammelte mehr als 5.000 Microsoft-365-bezogene Zugangsdaten und betraf Tausende IP-Adressen in mehr als 40 Ländern. Die Infrastruktur war nicht darauf ausgelegt, MFA zu knacken, sondern die Sitzung abzugreifen, die nach der Bestätigung durch Microsoft erstellt wurde.

Diese Unterscheidung macht den Angriff besonders gefährlich. Ein Benutzer kann ein korrektes Passwort eingeben, eine MFA-Anfrage bestätigen und dem Angreifer dennoch eine authentifizierte Cloud-Sitzung überlassen.

BigBear verwandelte erfolgreiche Anmeldungen in Sitzungen für Angreifer

BigBear 2.0 basiert auf Evilginx2, einem Phishing-Framework für Adversary-in-the-Middle-Angriffe (AiTM). Statt den Opfern ein vollständig gefälschtes Anmeldeformular zu präsentieren, schleust der Dienst den Datenverkehr zwischen dem Browser des Opfers und den legitimen Authentifizierungssystemen von Microsoft.

Das Opfer sieht einen Microsoft-365-Anmeldevorgang und übermittelt Benutzername und Passwort. BigBear leitet diese Daten an Microsoft weiter, bleibt dabei jedoch zwischen beiden Parteien positioniert.

Fordert Microsoft einen zusätzlichen Authentifizierungsfaktor an, führt das Opfer diesen Schritt über die vorgeschaltete Verbindung aus. BigBear kann dadurch Authentifizierungsdaten beobachten und das Sitzungscookie abgreifen, das nach erfolgreicher Anmeldung ausgestellt wird.

Ein Affiliate kann das gestohlene Cookie über die API von BigBear übermitteln und die authentifizierte Sitzung wiederverwenden. Da Microsoft das Passwort und die MFA-Abfrage bereits überprüft hat, kann der Angreifer möglicherweise auf das Konto zugreifen, ohne die Interaktion mit dem zweiten Faktor zu wiederholen.

Hierbei handelt es sich um Sitzungshijacking und nicht um eine kryptografische Umgehung von MFA. Der Authentifizierungsfaktor kann genau wie vorgesehen funktionieren, während die daraus entstehende Sitzung gestohlen wird.

Das betroffene Ökosystem umfasst:

• Microsoft 365
• Exchange Online
• Teams
• SharePoint
• OneDrive
• Entra ID authentication
• Über Single Sign-on der Organisation angebundene Anwendungen

Die Folgen hängen von den Berechtigungen des Opfers ab. Ein gewöhnliches Konto könnte E-Mails, Unterhaltungen, Dokumente und freigegebene Dateien offenlegen. Eine privilegierte Entra-ID-Identität könnte Zugriff auf administrative Ressourcen oder andere Anwendungen ermöglichen, die derselben Cloud-Identität vertrauen.

Für die gemeldeten Aktivitäten gilt keine CVE-Kennung. Es handelt sich um den Missbrauch einer vorgeschalteten Authentifizierung und gestohlener Sitzungscookies, nicht um eine offengelegte Softwareschwachstelle, die eine definierte Gruppe von Microsoft-365-Versionen betrifft.

Die Steuerzentrale verzeichnete kompromittierte Konten in mehr als 40 Ländern

Die umfassenderen Targeting-Daten von BigBear führten 461 Organisationen auf. CloudSEK bewertete, dass 258 davon mindestens eine abgeschlossene Kompromittierung durch die Umgehung von MFA mittels Sitzung Diebstahl erlitten hatten.

Die Steuerzentrale verzeichnete außerdem 3.331 eindeutige IP-Adressen von Opfern, verteilt auf mehr als 40 Länder. Eine IP-Adresse entspricht nicht zwangsläufig dem Konto einer einzelnen Person. Daher sollte diese Zahl nicht als exakte Anzahl der Opfer interpretiert werden.

CloudSEK meldete 5.137 exfiltrierte Zugangsdaten, aufgeschlüsselt in folgende Werte:

• 474 abgeschlossene Authentifizierungen, bei denen der MFA-Schutz umgangen wurde
• 1.032 Passwörter im Klartext
• 4.148 authentifizierte Sitzungscookies

Diese drei Werte ergeben zusammen 5.654 und nicht 5.137. Es ist nicht bekannt, ob sich die Kategorien überschneiden, ob einige Einträge dedupliziert wurden oder ob einer der gemeldeten Werte fehlerhaft ist. Die Abweichung ist weiterhin ungeklärt und sollte nicht einfach durch Annahmen korrigiert werden.

Zum Zeitpunkt der Veröffentlichung der Erkenntnisse war die Steuerzentrale noch erreichbar. Die zugehörige Phishing-Infrastruktur war Berichten zufolge jedoch seit fast drei Wochen offline. Das könnte die laufende Datensammlung unterbrochen haben, macht bereits erlangte Cookies, Passwörter oder Tokens jedoch nicht ungültig.

Zuvor gestohlene Zugangsdaten könnten weiterhin nutzbar sein, bis die Verteidiger Sitzungen widerrufen, Tokens ablaufen lassen, Zugangsdaten ändern oder neue Authentifizierungsanforderungen durchsetzen.

Affiliates erhielten gestohlene Zugangsdaten über Telegram

BigBear wurde als Multi-User-Dienst betrieben und war nicht einem einzelnen Angreifer vorbehalten. Die Steuerzentrale wurde Berichten zufolge an mindestens fünf Affiliate-Betreiber vermietet. Dadurch konnten Kunden Kampagnen durchführen, ohne eine eigene AiTM-Infrastruktur aufzubauen.

CloudSEK brachte diese Betreiber mit aktiven Telegram-Exfiltrations-Bots in Verbindung. Die Bots übermittelten abgefangene Zugangsdaten in Echtzeit an die Affiliates und verkürzten damit das Zeitfenster zwischen der Anmeldung eines Opfers und dem Versuch des Angreifers, die daraus resultierende Sitzung zu nutzen.

Die Plattform verwendete eine „offy“-Konfiguration, um ihren Proxy in den Microsoft-Authentifizierungsaustausch einzuschleusen. Außerdem lief sie über 42 VPS-Knoten, was auf ein Infrastrukturmodell hindeutet, das mehrere Kampagnen oder Kunden unterstützen sollte.

Eine Liste der Knotenadressen, Phishing-Domains, Datei-Hashes oder anderer direkt durchsuchbarer Indikatoren wurde nicht veröffentlicht. Organisationen können sich daher nicht allein auf die Sperrung bekannter BigBear-Infrastruktur verlassen.

Auch Identitäts- und Sitzungsverhalten müssen überwacht werden. Relevante Signale können eine ungewöhnliche Nutzung authentifizierter Sitzungen, Zugriffe von nicht verwalteten Geräten, unerwartete Aktivitäten in Postfächern oder Dateien, Berechtigungsänderungen sowie eine Token-Nutzung sein, die nicht dem üblichen Arbeitsverhalten eines Benutzers entspricht.

Residential Proxies und Eingriffe in WebAuthn erschwerten die Erkennung

BigBear unterstützte geografisch passende Residential-Proxy-Verbindungen in 69 Ländern. Dadurch konnten Affiliates Authentifizierungsdatenverkehr von privaten IP-Adressen in der Nähe des vermuteten Standorts eines Opfers erzeugen.

Diese Fähigkeit schwächt Kontrollen, die hauptsächlich auf geografischen Merkmalen basieren. Eine gestohlene Sitzung, die aus einem weit entfernten Land genutzt wird, kann einen Impossible-Travel- oder standortbasierten Alarm auslösen. Ein Residential Proxy in der erwarteten Region kann denselben Zugriff dagegen weniger auffällig erscheinen lassen.

Der Standort bleibt ein nützliches Signal, reicht allein jedoch nicht aus. Auch der Verwaltungsstatus des Geräts, Sitzungseigenschaften, Anwendungsaktivitäten, das Token-Verhalten und die Kontoberechtigungen sollten in Zugriffsentscheidungen einfließen.

CloudSEK entdeckte außerdem individuelles JavaScript, das die Browserunterstützung für FIDO2/WebAuthn beeinträchtigen sollte. Das mutmaßliche Ziel bestand darin, eine phishing-resistente Authentifizierung zu verhindern oder zu stören und die Opfer auf Methoden zu lenken, die sich leichter über einen AiTM-Proxy weiterleiten lassen.

Eine ordnungsgemäß durchgesetzte FIDO2/WebAuthn-Authentifizierung ist resistent gegen herkömmliches Credential-Phishing, da die Authentifizierung an die legitime Web-Origin gebunden ist. BigBear versuchte daher nicht, diesen Schutz direkt zu brechen, sondern offenbar, ihn während des Anmeldevorgangs des Opfers nicht verfügbar zu machen.

Organisationen sollten unerwartete WebAuthn-Fehler untersuchen, insbesondere wenn Benutzern anschließend eine schwächere Anmeldemethode angeboten wird. Die Zulassung eines Fallbacks kann einen großen Teil des Sicherheitsgewinns zunichtemachen, den der Einsatz phishing-resistenter Zugangsdaten bringt.

Verteidiger sollten Sitzungen widerrufen und nicht nur Passwörter ändern

Ein alleiniger Passwort-Reset entfernt einen Angreifer möglicherweise nicht, wenn dieser bereits ein gültiges Sitzungscookie besitzt. Incident-Responder sollten eine vermutete BigBear-Exposition sowohl als Kompromittierung von Zugangsdaten als auch als Diebstahl von Tokens behandeln.

Zu den empfohlenen Maßnahmen gehören:

1. Passwörter zurücksetzen, die mit offengelegten oder verdächtigen Konten verbunden sind.
2. Aktive Microsoft-365-Sitzungen widerrufen, damit abgefangene Cookies keinen Zugriff mehr ermöglichen.
3. Relevante Tokens ungültig machen oder erneuern, einschließlich der Tokens verbundener Cloud-Anwendungen.
4. Eine erneute Authentifizierung für privilegierte Identitäten, Administratoren und andere Konten mit hohem Auswirkungsgrad erzwingen.
5. Phishing-resistente FIDO2/WebAuthn-Methoden vorschreiben und schwächere Fallback-Optionen, soweit betrieblich möglich, einschränken.
6. Conditional-Access-Richtlinien verwenden, die verwaltete oder konforme Geräte für sensible Dienste voraussetzen.
7. Aktivitäten in Exchange Online, Teams, SharePoint, OneDrive und Entra ID überprüfen, die nicht zur Rolle oder Gerätehistorie des Benutzers passen.
8. Geografische Übereinstimmung nicht als Beweis für die Legitimität eines Zugriffs betrachten, da BigBear Residential Proxies unterstützt.

CloudSEK teilte mit, die Strafverfolgungsbehörden und mehrere betroffene Organisationen informiert zu haben. Die offengelegten Zugangsdaten wurden außerdem in Meldungen im Rahmen einer verantwortungsvollen Offenlegung berücksichtigt.

Die grundsätzliche Herausforderung besteht darin, dass sich bösartige Aktivitäten schwerer stoppen lassen, sobald sie innerhalb einer gültigen authentifizierten Sitzung stattfinden. Eine zitierte Bewertung des Blue Report 2026 ergab, dass nur 37 % der mit gültigen Zugangsdaten ausgeführten Angreiferaktionen in 338 Millionen Simulationen in Produktionsumgebungen von Kunden blockiert wurden. Dieses Ergebnis bezog sich nicht speziell auf BigBear, verdeutlicht jedoch, warum die Überwachung nach der Authentifizierung wichtig ist.

MFA bleibt notwendig, aber nicht jede MFA-Methode bietet denselben Schutz gegen AiTM-Phishing. Für Organisationen, die Diensten wie BigBear ausgesetzt sind, kombiniert das robustere Modell eine an die Origin gebundene Authentifizierung, Anforderungen an verwaltete Geräte, einen schnellen Widerruf von Sitzungen und eine Verhaltensüberwachung nach der Anmeldung.