Passkey-Phishing gegen Microsoft 365: Was Sie heute in Entra ID prüfen sollten

Betroffen ist jede Organisation, die Microsoft 365 mit Entra ID betreibt und deren Mitarbeitende telefonisch erreichbar sind. Das ist praktisch jedes Unternehmen. Nicht betroffen ist die Passkey-Technik selbst: Sie ist in diesen Kampagnen weder umgangen noch gebrochen worden. Wer heute einen Tenant verantwortet, prüft am besten drei Dinge: ob der Device-Code-Flow noch erlaubt ist, wer in den letzten Wochen neue Authentifizierungsmethoden registriert hat und ob die Registrierung von Security-Info überhaupt an Bedingungen geknüpft ist.

Die Klarstellung vorweg, weil sie in der Berichterstattung leicht untergeht: In den von Microsoft Threat Intelligence beschriebenen Fällen findet keine echte Passkey-Registrierung statt. Das Wort Passkey dient ausschließlich als Köder. Angreifer rufen an oder schreiben eine SMS, behaupten, der Passkey oder die MFA-Methode müsse dringend aktualisiert werden, und führen das Opfer dann in einen ganz anderen Ablauf: entweder auf eine Adversary-in-the-Middle-Seite oder in den Geräteanmeldungsfluss von Microsoft. Passkeys bleiben die phishing-resistente Methode, die sie sind. Der Angriff funktioniert gerade deshalb, weil sie einen guten Ruf haben und ihre Einführung in vielen Firmen gerade läuft.

Was Microsoft beobachtet hat

Microsoft Threat Intelligence hat die Aktivität am 9. September 2026 veröffentlicht, BleepingComputer hat sie am 11. September aufgegriffen. Beobachtet wird die Kampagne seit Mai 2026. Microsoft ordnet sie mehreren Akteuren zu, die im selben Erpressungsökosystem arbeiten.

Akteur	Einordnung laut Microsoft	Verbindung
Storm-3121	Initial-Access-Aktivität	mündet in Erpressung unter den Namen ShinyHunters und Falcon
Storm-3032	Abspaltung der Gruppe BlackFile	operiert heute unter dem Namen Helix
UNC6671	Tracking-Bezeichnung von Google Threat Intelligence	Überschneidung mit dem Cluster, Google verknüpft BlackFile, Helix, Falcon, Pink und Redact

Die Namensvielfalt ist für den Betrieb zweitrangig. Wichtiger ist, dass verschiedene Gruppen dasselbe Vorgehen benutzen, weil es funktioniert. Es handelt sich also nicht um einen einzelnen Vorfall, sondern um ein Muster, das sich weiter verbreiten wird.

Der Ablauf vom Anruf bis zum Datenabfluss

Der Einstieg erfolgt über einen Anruf oder eine SMS auf die private Telefonnummer der Mitarbeitenden. Das ist bewusst gewählt: Auf dem privaten Gerät greifen weder die Filter des Unternehmens noch die gewohnten Warnhinweise. Der Anrufer gibt sich als interner Helpdesk aus und baut Zeitdruck auf.

• Vishing oder Smishing auf die private Nummer, Vorwand ist ein angeblich fälliges Passkey-, MFA- oder SSO-Update.
• Weiterleitung auf eine Seite im Look der Microsoft-Anmeldung. Microsoft nennt unter anderem passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, keysyncos[.]com und oskeysync[.]com. Der Firmenname steht meist als Subdomain davor.
• Pfad A, Adversary-in-the-Middle: Zugangsdaten und Sitzungstoken werden im Vorbeigehen abgegriffen. Der erste Sign-in erscheint in den Entra-Protokollen als Anwendung OfficeHome von einem nicht verwalteten Gerät, die Sitzung blieb rund eine Stunde aktiv.
• Pfad B, Device-Code-Phishing: Das Opfer tippt einen vom Angreifer gelieferten Code auf der echten Microsoft-Seite ein. Das Token landet bei der angreifergesteuerten Anwendung, MFA wird dabei umgangen, und es muss kein einziges Cookie gestohlen werden.
• Ein dritter beobachteter Fall: Anmeldung mit zuvor erbeuteten Zugangsdaten, MFA bestätigt über eine schon Tage vorher registrierte PhoneAppOTP-Methode.
• Persistenz: Die Angreifer registrieren eigene Telefonnummern, Authenticator-Apps und Software-OTP als zusätzliche Methoden. Laut Microsoft überlebt diese Persistenz einen vollständigen Reset von Zugangsdaten und Sitzungen nicht.

Danach folgt die Erkundung über Microsoft Graph, teils automatisiert mit einem Node.js-System: Organisationen und Lizenzen, Nutzer, Gruppen und Mitgliedschaften, Verzeichnisrollen und privilegierte Konten, registrierte Authentifizierungsmethoden, Anwendungen und Service Principals, OAuth-Berechtigungen, SharePoint-Sites, OneDrive und Postfachinhalte.

Warum der Device-Code-Flow das eigentliche Problem ist

Der Geräteanmeldungsfluss existiert für Geräte ohne brauchbare Tastatur oder Browser, etwa Konferenzsysteme oder Kommandozeilenwerkzeuge. Das Gerät zeigt einen kurzen Code, der Nutzer gibt ihn an einer echten Microsoft-Adresse ein, und das Gerät erhält daraufhin ein Token.

Für Phishing ist das ideal, weil alles, was der Nutzer sieht, echt ist: echte Domain, echtes Zertifikat, echte Anmeldemaske. Es gibt keine gefälschte Seite, an der eine Prüfung scheitern könnte. Der Nutzer bestätigt seine MFA korrekt und übergibt das Ergebnis trotzdem an den Angreifer. Kein Passwortmanager und kein Passkey schützt davor, weil die Bindung an die Domain hier gar nicht geprüft wird. Die einzige wirksame Antwort ist, diesen Fluss abzuschalten, wo er nicht gebraucht wird. In den allermeisten Unternehmen wird er nicht gebraucht.

Was Sie heute in Ihrem Tenant prüfen

Die folgenden Schritte lassen sich innerhalb eines Vormittags abarbeiten und beantworten die Frage, ob Sie betroffen sind oder waren.

1. Device-Code-Flow prüfen und sperren. Im Entra Admin Center unter Schutz, Bedingter Zugriff eine neue Richtlinie anlegen. Zuweisung auf alle Nutzer, als Bedingung unter Authentifizierungsflüsse den Geräteanmeldungsfluss auswählen, Zugriffssteuerung auf Blockieren. Zusätzlich den Authentifizierungsübertragungsfluss aufnehmen. Erst im Nur-Bericht-Modus laufen lassen, die Treffer ansehen, Ausnahmen für echte Geräte über eine eigene Gruppe definieren, dann scharf schalten.
2. Registrierte Authentifizierungsmethoden durchsehen. Unter Schutz, Authentifizierungsmethoden, Benutzerregistrierungsdetails filtern und alle Registrierungen der letzten sechs bis acht Wochen ansehen. Achten Sie auf fremde Telefonnummern, auf zusätzliche Authenticator-Registrierungen bei Nutzern, die bereits eine hatten, und auf Software-OTP.
3. Sign-in-Logs gezielt filtern. Die relevanten Felder stehen unten in einem eigenen Abschnitt.
4. Security-Info-Registrierung absichern. Eine Richtlinie für die Benutzeraktion Sicherheitsinformationen registrieren: Anmeldehäufigkeit auf jedes Mal, verwaltetes Gerät oder benannter Standort verlangen, phishing-resistente MFA als Authentifizierungsstärke setzen. Dazu eine zweite Richtlinie, die die Registrierung bei hohem Anmelderisiko blockiert.
5. Zustimmung für Anwendungen einschränken. Benutzerzustimmung auf Administratorgenehmigung umstellen und die vorhandenen Service Principals mit hochprivilegierten Graph-Berechtigungen wie Mail.Read, Files.Read.All und Directory.Read.All durchgehen.
6. Zugriff von nicht verwalteten Geräten begrenzen. Für Exchange und SharePoint auf reinen Browserzugriff ohne Download und Synchronisierung beschränken, anonyme Freigabelinks in SharePoint und OneDrive abschalten.
7. Protokollierung einschalten. Microsoft Graph Activity Logs und Postfachüberwachung aktivieren, sonst fehlen genau die Daten, mit denen sich der Umfang eines Vorfalls später klären ließe.
8. Helpdesk-Prozess festziehen. Vor jedem vom Helpdesk angestoßenen Zurücksetzen von Zugangsdaten oder MFA eine belastbare Identitätsprüfung, und jedes solche Zurücksetzen alarmieren. Den Mitarbeitenden einen verifizierten Meldeweg geben, über den sie einen angeblichen Helpdesk-Anruf gegenprüfen können.

Welche Felder in den Entra-Sign-in-Logs zählen

Die interaktiven Anmeldeprotokolle liefern die Indikatoren, die Microsoft beschreibt. Sinnvoll ist ein Zeitraum ab Mai 2026, soweit die Aufbewahrung reicht.

Feld	Worauf achten	Warum
Anwendung	OfficeHome	Erster Sign-in nach erfolgreichem AiTM-Phishing erschien so
Geräteverwaltung	nicht verwaltet, nicht konform, nicht hybrid eingebunden	Angreifer melden sich von eigenen Systemen an
Authentifizierungsprotokoll	Device Code	Direkter Treffer auf Pfad B, gehört ohne Geschäftsbedarf nicht in den Tenant
Authentifizierungsdetails	PhoneAppOTP, SMS, Sprachanruf	Methoden, die die Angreifer nachträglich registriert haben
Benutzeragent	python-httpx	Beim Abzug der Daten verwendet, in normalem Büroverkehr untypisch
IP und Standort	Wechsel innerhalb weniger Minuten, Hosting-Provider	Unmögliche Ortswechsel und Rechenzentrums-IPs neben regulären Anmeldungen

Ergänzend im Unified Audit Log nach Massen an FileAccessed- und FileDownloaded-Ereignissen suchen. Der Abfluss lief bewusst langsam über Stunden bis mehrere Tage und blieb unter etwa 1.000 Dateien oder E-Mails pro Stunde, um unter Schwellenwerten zu bleiben. Ein Alarm, der erst bei mehreren tausend Zugriffen pro Stunde anschlägt, schweigt hier zuverlässig.

Wenn der Verdacht sich bestätigt

Microsoft nennt eine klare Reihenfolge, und die Reihenfolge ist wichtig: Ein Passwortwechsel allein hilft nicht, solange Token und fremde MFA-Methoden bestehen bleiben.

• Aktive Sitzungen und ausgestellte Token des betroffenen Kontos widerrufen.
• Zugangsdaten zurücksetzen.
• Alle vom Angreifer registrierten Authentifizierungsmethoden entfernen.
• Vom Angreifer angelegte Postfachregeln suchen und löschen, insbesondere Weiterleitungen und Regeln, die Nachrichten in selten geöffnete Ordner verschieben.
• Den Nutzer zur vollständigen Neuregistrierung seiner Authentifizierungsmethoden zwingen.
• Anschließend prüfen, welche Anwendungen und Service Principals in dem Zeitfenster Zustimmung erhalten haben.

Der gute Teil der Nachricht: Laut Microsoft überlebt die Persistenz dieser Akteure einen vollständigen Reset von Zugangsdaten und Sitzungen nicht. Es bleibt keine versteckte Hintertür, sofern der Reset konsequent durchgeführt wird.

Einordnung für kleine Unternehmen

Zwei Punkte machen die Kampagne für kleinere Organisationen besonders unangenehm. Erstens setzt sie am Telefon an, nicht an der Technik. Ein gut konfigurierter Tenant schützt nicht davor, dass jemand am Freitagnachmittag einen glaubwürdigen Anruf bekommt. Zweitens zielt sie auf eine laufende Umstellung: Wer gerade Passkeys einführt und das im Haus kommuniziert hat, liefert dem Angreifer die passende Geschichte frei Haus.

Daraus folgt nichts gegen Passkeys, im Gegenteil. Phishing-resistente Methoden per bedingtem Zugriff zu erzwingen, ist genau die Maßnahme, die Microsoft an erster Stelle empfiehlt. Nur sollte die Einführung begleitet werden von einer einfachen, oft wiederholten Ansage an alle Mitarbeitenden: Der Helpdesk ruft nie auf der privaten Nummer an und bittet nie darum, einen Code vorzulesen oder einzugeben. Wer unsicher ist, legt auf und meldet sich über den bekannten internen Weg. Diese eine Regel entwertet den gesamten Einstiegsvektor.

Passende Anleitungen auf S-EDV

• Microsoft 365: MFA und Conditional Access in Entra ID: die Grundlage, auf der die hier beschriebene Sperrrichtlinie gegen den Geräteanmeldungsfluss aufsetzt.
• Conditional Access fortgeschritten: Personas und Token Protection: zeigt, wie sich Richtlinien sauber nach Nutzergruppen schneiden lassen und wie Tokenschutz gegen gestohlene Sitzungen wirkt.
• Sichere Passwörter und Passkeys im Unternehmen: für die Einführung phishing-resistenter Anmeldung, die von dieser Kampagne ausdrücklich nicht ausgehebelt wird.

Quellen

• Microsoft Security Blog: Passkey-themed social engineering leads to identity and cloud compromise (09.09.2026)
• BleepingComputer: Passkey-themed phishing attacks lead to Microsoft 365 data theft (11.09.2026)
• Help Net Security: Angriffe über private Telefonnummern auf Microsoft 365 (10.09.2026)
• Dark Reading: Voice callers exploit BYOD to reach Microsoft 365 corporate data