Vishing-Gruppen dringen über private Telefone in Microsoft 365 ein, ohne Unternehmensgeräte anzutasten

Bedrohungsakteure rufen Mitarbeiter auf deren privaten Telefonen an oder schreiben ihnen und geben sich als interner IT-Support aus, um Microsoft-365-Identitäten und authentifizierte Sitzungen abzugreifen. Nach dem Eindringen nutzen sie legitime Cloud-Schnittstellen, um Unternehmensumgebungen zu erfassen und unauffällig Daten aus SharePoint, OneDrive und Exchange abzuschöpfen.

Die Aktivitäten wurden am 10. September 2026 gemeldet. Microsoft beobachtet diese Kampagnen über private Geräte seit Mai und führt die Betreiber unter den Bezeichnungen Storm-3032 und Storm-3121.

Die Methode ist besonders gefährlich, weil die erste Phase außerhalb der Sichtweite vieler Sicherheitslösungen in Unternehmen stattfindet. Die Angreifer müssen nicht unbedingt einen verwalteten Laptop kompromittieren, Malware einschleusen oder eine Nachricht über das E-Mail-System des Unternehmens versenden.

Stattdessen missbrauchen sie das Vertrauen der Mitarbeiter.

Der Angriff beginnt außerhalb des Unternehmensperimeters

Zu den Zielen gehören Führungskräfte, Administratoren und Mitarbeiter mit erweiterten Microsoft-365-Berechtigungen. Solche Konten können mehr Benutzer, Gruppen, Websites, Anwendungen, Berechtigungen, Kommunikationsinhalte und Geschäftsdokumente offenlegen als die Identität eines gewöhnlichen Mitarbeiters.

Ein Angreifer kontaktiert die private Mobilfunknummer des Opfers per Sprachanruf oder SMS. Der Anrufer gibt sich als Helpdesk des Unternehmens aus und behauptet, der Mitarbeiter müsse eine Authentifizierungseinstellung aktualisieren, da er sonst den Zugriff auf die Arbeitsdienste verlieren könnte.

Häufige Vorwände sind:

• Einen Passkey registrieren oder ersetzen
• Eine MFA-Konfiguration ändern
• Einstellungen für Single Sign-on aktualisieren
• Einen angeblich unterbrochenen Kontozugriff wiederherstellen

Anschließend erhält das Opfer einen Link zu einer gefälschten Microsoft-Anmeldeseite. Schadensdomänen können den Namen des Arbeitgebers mit Begriffen aus dem Bereich der Authentifizierung kombinieren, etwa nach dem Muster company[.]add-passkey[.]com.

Die Kampagne kann ein Adversary-in-the-Middle- beziehungsweise AiTM-Phishing-System einsetzen, um Zugangsdaten und authentifizierte Sitzungstoken abzufangen. Außerdem kann sie die Device-Code-Authentifizierung missbrauchen, indem das Opfer dazu gebracht wird, eine Sitzung zu autorisieren, die der Angreifer an anderer Stelle initiiert hat.

In einer geringeren Zahl von Fällen nutzen die Betreiber ein kompromittiertes Mitarbeiterkonto, um einen weiteren Mitarbeiter zu kontaktieren. Nachrichten von einer vertrauten internen Identität können die Authentifizierungsanfrage glaubwürdiger erscheinen lassen.

Das Telefon selbst bleibt möglicherweise kompromittiert. Der Angriff gelingt, weil der Benutzer betrügerischen Anweisungen folgt und eine legitime Authentifizierungshandlung für die falsche Partei ausführt.

Warum BYOD eine Überwachungslücke schafft

E-Mail-Gateways, Endpoint-Detection-and-Response-Plattformen und Kontrollen für verwaltete Browser bekommen die ursprüngliche Täuschung möglicherweise nie zu sehen. Der Anruf oder die SMS geht auf einem privaten Gerät ein, das nicht in den Sicherheits-Stack der Organisation eingebunden ist.

Dadurch haben Ermittler einen schwierigen Ausgangspunkt. Die frühesten Hinweise können aus der Erinnerung eines Mitarbeiters an ein Telefongespräch oder eine SMS stammen – statt aus einer gespeicherten E-Mail, einer Endpoint-Warnung oder einem abgefangenen Anhang.

Incident-Response-Teams müssen diesen Bericht anschließend mit nachfolgenden Identitäts- und Cloud-Ereignissen in Verbindung bringen. Relevante Telemetriedaten umfassen:

• Ungewöhnliche Anmeldungen
• Versuche zur Device-Code-Authentifizierung
• Token-Nutzung von unerwarteten Standorten oder Clients
• Änderungen an registrierten Authentifizierungsmethoden
• Registrierung neuer MFA-Geräte
• Aufzählung über Microsoft Graph
• Zugriffe auf SharePoint, OneDrive oder Exchange
• Wiederholte kleine Downloads aus Cloud-Repositories

Nachdem der Angreifer die Kontrolle über eine Identität erlangt hat, kann er ein MFA-Gerät unter seiner Kontrolle registrieren. Dieser Schritt schafft Persistenz und kann dafür sorgen, dass späterer Zugriff stärker wie eine normale Kontonutzung wirkt.

Ein pauschales Verbot von Bring-your-own-Device-Modellen würde das Problem nicht vollständig lösen. Die Schwachstelle liegt vor allem in Authentifizierungsabläufen, Kontoberechtigungen und dem Vertrauen der Benutzer – nicht in Malware, die auf dem Telefon des Mitarbeiters läuft.

Microsoft Graph macht aus einer gestohlenen Identität ein Aufklärungswerkzeug

Nach der Authentifizierung wurden Storm-3032 und Storm-3121 dabei beobachtet, wie sie die Microsoft Graph API zur Erkundung von Microsoft-365-Umgebungen verwendeten. Bei Graph handelt es sich um eine standardmäßige Programmierschnittstelle. Die Angreifer müssen daher keine Aufklärungswerkzeuge im Unternehmensnetzwerk installieren.

Je nach den Berechtigungen der kompromittierten Identität können Graph-Anfragen Folgendes offenlegen:

• Benutzer und Gruppen
• SharePoint-Websites
• Anwendungen und andere Ressourcen
• Speicherorte von Inhalten
• Zugriffsrechte und Berechtigungsbeziehungen
• Weitere Konfigurationsdetails von Microsoft 365

Anfragen an Endpunkte wie /users, /groups und /sites sind nicht grundsätzlich bösartig. Unternehmen und freigegebene Anwendungen verwenden sie regelmäßig, weshalb Warnungen auf Basis eines einzelnen API-Aufrufs nur begrenzten Nutzen haben.

Entscheidend ist das Muster, nicht der Endpunkt.

Ein Benutzer oder eine Anwendung, die plötzlich zahlreiche Bereiche der Umgebung abfragt, eine ungewöhnliche Abfolge von Aufzählungsanfragen ausführt oder die Erkundung mit verdächtigen Authentifizierungsaktivitäten verbindet, sollte untersucht werden. Bei den Baselines muss die jeweilige Rolle der Identität berücksichtigt werden, da eine für ein Automatisierungskonto normale Graph-Aktivität bei einer Führungskraft höchst ungewöhnlich sein kann.

Die Angreifer nutzen dieses Inventar, um wertvolle Dateien, Nachrichten und Zugriffswege zu identifizieren. Microsoft hat Datendiebstahl aus SharePoint, OneDrive und Exchange sowie aus weiteren Microsoft-365-Repositories beobachtet.

Die Exfiltration ist darauf ausgelegt, unauffällig zu bleiben. Statt ein großes Archiv in einem einzigen Vorgang herunterzuladen, rufen die Akteure über einen längeren Zeitraum regelmäßig kleine Datenmengen ab. So können sie Schwellenwerte umgehen, die auf plötzliche hohe Transfermengen ausgerichtet sind, und sich zugleich in die normale Cloud-Nutzung einfügen.

Access Broker könnten Konten an Erpressungsgruppen weitergeben

Microsoft geht davon aus, dass die Betreiber den erlangten Zugriff möglicherweise an nachgelagerte Erpressungsgruppen wie ShinyHunters verkaufen oder übertragen. Allerdings wurde kein bekannter Unternehmensangriff direkt einer dieser Kampagnen zum Erstzugriff zugeschrieben.

Diese Unterscheidung schränkt die derzeit möglichen Schlussfolgerungen ein. Die beobachteten Aktivitäten belegen einen gangbaren Weg zu Aufklärung, dauerhaftem Zugriff und Datendiebstahl. Sie beweisen jedoch nicht, dass Storm-3032 oder Storm-3121 für einen bestimmten öffentlich bekannten Einbruch verantwortlich waren.

Die möglichen geschäftlichen Auswirkungen bleiben erheblich. Eine kompromittierte Administratoren- oder Führungskräfteidentität könnte interne Kommunikation, sensible Dokumente, Organisationsbeziehungen und Sicherheitskonfigurationen offenlegen. Der Zugriff könnte außerdem eine spätere Erpressung ermöglichen, wenn die gestohlenen Informationen dazu verwendet werden, das betroffene Unternehmen unter Druck zu setzen.

Hierbei handelt es sich nicht um eine Software-Schwachstelle. Es gibt weder eine zugehörige CVE noch eine betroffene Produktversion, einen Sicherheitspatch oder eine Frist aus der CISA-Liste der bekannten ausgenutzten Schwachstellen. Die Kampagne missbraucht Social Engineering, gültige Authentifizierungsfunktionen, übermäßige Berechtigungen und Lücken bei der Cloud-Überwachung.

Die Berichterstattung zu den Erkenntnissen von Microsoft beschreibt die Kampagnen als Bedrohung auf der Identitätsebene und nicht als Kompromittierung, bei der die Kontrolle über einen Unternehmensendpunkt erforderlich wäre.

Abwehrmaßnahmen müssen Identitäten über Geräte und Cloud-Dienste hinweg verfolgen

Die zentrale Empfehlung von Microsoft lautet, phishing-resistente MFA für jede Anmeldung vorzuschreiben. Wenn sie für den betroffenen Benutzer korrekt durchgesetzt wird, sollte sie diese Angriffskette verhindern, statt lediglich eine weitere Abfrage zu erzeugen, deren Bestätigung ein Anrufer dem Opfer einreden kann.

Unternehmen sollten außerdem die Device-Code-Authentifizierung überall dort blockieren, wo kein dokumentierter betrieblicher Bedarf besteht. Wenn bestimmte Abläufe sie erfordern, sollten Conditional-Access-Richtlinien festlegen, wer diesen Ablauf von welchen Geräten und unter welchen Bedingungen nutzen darf.

Weitere vorrangige Maßnahmen sind:

1. Sensible Anwendungen auf verwaltete Geräte beschränken. Diese Kontrolle sollte dort eingesetzt werden, wo der Wert der Daten die betrieblichen Kosten rechtfertigt.
2. Berechtigungen für Microsoft Graph reduzieren. Benutzer und Anwendungen sollten nur die für ihre Aufgaben erforderlichen Scopes erhalten.
3. Änderungen an Authentifizierungsmethoden überwachen. Neue MFA-Registrierungen nach ungewöhnlichen Anrufen, SMS oder Anmeldungen sollten umgehend geprüft werden.
4. Identitäts- und Cloud-Telemetrie korrelieren. Device-Code-Ereignisse, Token-Aktivitäten, Graph-Abfragen und Downloads liefern gemeinsam aussagekräftigere Hinweise.
5. Exfiltration mit geringem Datenvolumen erkennen. Die Überwachung sollte kumulierte und wiederholte Zugriffe berücksichtigen, nicht nur einzelne große Übertragungen.
6. Privilegierte Konten überprüfen. Das Prinzip der geringsten Berechtigungen reduziert die Menge an Informationen und Inhalten, die nach der Kompromittierung einer Identität verfügbar ist.
7. Ein Verfahren zur Verifizierung durch den Helpdesk etablieren. Mitarbeiter benötigen einen vertrauenswürdigen Kanal, um unerwartete Anfragen zu Passkeys, MFA oder SSO zu bestätigen.

Schulungen sollten eine klare Regel vermitteln: Ein unaufgeforderter Anrufer darf einen Mitarbeiter niemals dazu auffordern, sich über einen an ein privates Telefon gesendeten Link zu authentifizieren. Benutzer sollten das Gespräch beenden und die IT über eine bekannte interne Telefonnummer oder ein internes Portal kontaktieren.

Das Beenden des Anrufs ist nur die erste Schutzschicht. Verantwortliche für die Abwehr müssen außerdem davon ausgehen, dass einige Mitarbeiter den Anweisungen folgen werden, und Kontrollen aufbauen, die eine daraus entstehende Kompromittierung der Identität eindämmen können, bevor die Aufklärung über Graph in anhaltenden Datendiebstahl übergeht.