Passkey-Phishing trifft Microsoft Cloud: Die Identitätsschicht bricht

Jeder Platform-Lead, der in den letzten zwölf Monaten eine Passkey-Einführung genehmigt hat, muss diese Entscheidung diese Woche neu bewerten. Microsoft hat nun zwei aktive Kampagnen dokumentiert, die den Passkey-Enrollment-Flow selbst als Angriffsfläche nutzen – und die Ökonomie des Verteidigungsstacks hat sich gerade verschoben. Das Versprechen der Anbieter, dass Passkeys das Phishing-Risiko eliminieren, war immer nur halb wahr; die andere Hälfte ist nun in den Vorfallsdaten sichtbar.

Was ist passiert

Zwischen dem 3. und 5. August 2026 schickten Bedrohungsakteure über mehr als eine Million Spam-E-Mails durch Drittanbieter-Infrastruktur, gaben sich als CEOs von Zielunternehmen aus und drängten Buchhaltungsteams dazu, ACH-Zahlungen für eine gefälschte ServiceNow-Jahresabrechnung zu überweisen. Wie The Hacker News berichtete, nutzten die Angreifer generative KI zur Erstellung maßgeschneiderter E-Mail-Vorlagen, registrierten Impersonation-Domains wie service-nowinc[.]com und domainlify[.]net und fügten in Signaturen echte Namen von CEOs, CFOs und Geschäftsführern aus öffentlichen Quellen ein. Hauptziel waren US-amerikanische Unternehmen aus den Bereichen IT-Dienstleistungen, Konsumgüter, Immobilien und diskrete Fertigung.

Die zweite Kampagne, die seit Mai 2026 läuft, ist die architektonisch interessantere. Angreifer rufen eine persönliche Telefonnummer an oder schicken eine SMS, geben vor, vom internen IT-Helpdesk zu stammen, und weisen die Zielpersonen an, ihren Passkey, MFA- oder SSO-Konfiguration zu aktualisieren. Opfer werden auf gefälschte Microsoft-Anmeldeseiten umgeleitet und übergeben entweder Zugangsdaten über einen Adversary-in-the-Middle-Proxy oder genehmigen einen Device-Code-Authentifizierungsflow, der dem Angreifer ein Token gewährt, ohne jemals ein Passwort preiszugeben.

Sobald die Angreifer eingedrungen sind, folgt ein konsistentes Muster: verdächtiger Anmeldevorgang, dann registriert der Angreifer seine eigene Authentifizierungsmethode (eine neue Telefonnummer, eine Authenticator-App oder ein Software-OTP), gefolgt von intensiver Microsoft Graph-Aktivität, SharePoint- und OneDrive-Downloads sowie Postfach-Sammlung über REST-APIs. Microsoft beschreibt dies als automatisierte Datenerhebung aus kompromittierten Cloud-Identitäten über Proxy-Infrastruktur. Die Aktivitäten überschneiden sich mit einem Cybercrime-Cluster, der unter verschiedenen Namen wie Cordial Spider, O-UNC-045, PREY-0058 und UNC6671 verfolgt wird; Microsoft schreibt den initialen Zugang Storm-3121 und Storm-3032 zu. Storm-3121 ist mit ShinyHunters und der Falcon-Erpressung verbunden; Storm-3032 (UNC6671) hat sich von der BlackFile-Gruppe getrennt und operiert nun unter der Helix-Erpressungsmarke.

Technische Analyse

Die zentrale Täuschung nutzt eine Lücke zwischen der Art, wie Identitätsanbieter Passkeys beschreiben, und der Art, wie Endnutzer sie erleben. Ein Passkey ist auf der kryptografischen Ebene phishing-resistent: Der private Schlüssel verlässt niemals das Gerät, und der Browser bindet die Assertion an den Ursprung. Diese Eigenschaft ist real. Was nicht phishing-resistent ist, sind der Enrollment-Prozess, der Recovery-Flow und das mentale Modell des Nutzers davon, was "einen Passkey aktualisieren" überhaupt bedeutet. Angreifer haben diese Lücke identifiziert und nutzen sie konsequent aus.

Die Liste der registrierten Domains zeigt, wie gezielt vorgegangen wird: passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, syncmykey[.]com, portalsetuphub[.]com. Das Muster sind unternehmensspezifische Subdomains auf generischen Passkey-Themenwurzeln, sodass ein Ziel acme.passkeyhelpdesk[.]com sieht und die Marke erkennt, nicht die Domain. Das zu Google gehörende Mandiant hat dieselbe Technik letzten Monat für UNC6671 gemeldet.

Zwei Angriffspfade tragen die Hauptlast. Im AitM-Pfad leitet das gefälschte Portal die echte Microsoft-Anmeldung weiter und erfasst sowohl Zugangsdaten als auch den Session-Cookie nach der MFA. Im Device-Code-Pfad initiiert der Angreifer eine Geräteautorisierungsanfrage gegen Microsofts eigene Endpunkte und bringt das Opfer durch Social Engineering dazu, den Code des Angreifers auf einer legitimen Microsoft-Seite einzugeben. Dieser zweite Flow ist der, den CISOs verstehen müssen: Das Opfer besucht nie eine Phishing-Seite, gibt nie Zugangsdaten auf etwas Verdächtigem ein, und MFA wird normal abgeschlossen. Microsofts eigene Infrastruktur stellt dem Gerät des Angreifers ein gültiges Token aus. Dies entspricht Techniken, die unter MITRE ATT&CK für Phishing und den Missbrauch gültiger Konten katalogisiert sind – aber die Device-Code-Variante umgeht die meisten Conditional-Access-Richtlinien, die die Anmeldeseite selbst als Vertrauensgrenze betrachten.

Persistenz ist die zweite Phase. Microsoft beobachtete, dass der Akteur unmittelbar nach dem ersten Zugang eine neue MFA-Methode unter seiner Kontrolle registrierte und so einen sitzungslangen Angriff in einen dauerhaften Zugang umwandelte. In einem dokumentierten Vorfall nutzten Angreifer Zugangsdaten aus einem früheren Ereignis, um eine telefonbasierte Methode zu registrieren und MFA bei späteren Anmeldungen vollständig zu umgehen. In einem anderen Fall folgte auf eine anomale Anmeldung von einem nicht verwalteten Gerät bei Microsoft Office Home eine Graph-API-Ausweitung in SharePoint Online und OneDrive.

Wer ist betroffen

Beginnen wir mit der Finanzabteilung. Die ACH-Kampagne zielte gezielt auf Kreditorenbuchhaltungsteams in US-amerikanischen Unternehmen aus den Bereichen IT-Dienstleistungen, Konsumgüter, Immobilien und diskrete Fertigung. In diesen Teams ist die durchschnittliche Betriebszugehörigkeit der Buchhalter kürzer als die durchschnittliche Lieferantenbeziehung, und eine ServiceNow-Erneuerungsrechnung von jemandem, dessen Name und E-Mail-Domain mit dem CEO übereinstimmt, wirkt absolut plausibel. Jeder CFO, dessen Lieferanten-Onboarding-Prozess noch auf E-Mail-basierten Genehmigungen beruht, deckt damit einen Schaden, der in den meisten Ländern nicht durch die Cyber-Police abgedeckt wird.

Zweitens betroffen: Identitätsteams in jeder Organisation, die kürzlich Passkeys als „phishing-resistente" Kontrolle eingeführt hat. Die Board-Präsentation sagte, Passkeys lösen Phishing. Die Vorfallsdaten sagen, Passkeys lösen eine enge Variante des Credential-Diebstahls, öffnen aber gleichzeitig zwei neue Social-Engineering-Vektoren: Enrollment-Manipulation und Recovery-Missbrauch. Der VP Engineering, der die Identity-Roadmap verantwortet, muss dem Prüfungsausschuss erklären, warum die Kontrolle, die als abschließend verkauft wurde, nun auf registrierten Lookalike-Domains gefälscht wird.

Drittens – und das ist der unterschätzte Punkt – Microsoft 365-Tenants, die Graph-API-Aktivitäten als Hintergrundrauschen behandeln. Das beobachtete Muster umfasst hohe Graph-Aufruf-Volumina, SharePoint- und OneDrive-Massendownloads sowie Postfach-Enumeration über REST-Endpunkte. Wenn Ihr SIEM keine Graph-Aufruf-Raten pro Identität als Baseline erfasst und nicht bei der Registrierung neuer MFA-Methoden von nicht verwalteten Geräten alarmiert, haben Sie keine Erkennungsoberfläche für diese Kampagne. Der Head of Platform, dessen Logging-Budget in den letzten vier Quartalen zweimal gekürzt wurde, wird bald herausfinden, was gestrichen wurde.

Jedes CFO-/General-Counsel-Gespann sollte seinen CISO diese Woche fragen: Was ist unser dokumentierter Prozess, wenn ein Mitarbeiter einen verdächtigen Anruf von jemandem meldet, der behauptet, aus der IT zu sein – und umfasst dieser Prozess die automatische Ungültigmachung jeder Authentifizierungsmethode, die in den letzten vierundzwanzig Stunden registriert wurde? Wenn die Antwort ein Achselzucken oder ein Policy-PDF ist, das seit dem Onboarding niemand gelesen hat, brennt das Incident-Response-Retainer bereits.

Playbook für Sicherheitsteams

Unterbinden Sie die benutzerinitiierte MFA-Registrierung von nicht verwalteten Geräten. Wenn ein Passkey, eine Telefonnummer oder eine Authenticator-App von einem privaten Gerät außerhalb Ihres MDM zu einer Unternehmensidentität hinzugefügt werden kann, haben Sie den Persistenz-Kampf bereits verloren. Leiten Sie die Registrierung über ein verwaltetes Gerät oder eine persönliche Helpdesk-Verifizierung, und akzeptieren Sie die damit verbundene Reibung.

Alarmieren Sie bei der Registrierung neuer Authentifizierungsmethoden als erstklassige Erkennung, nicht als Compliance-Checkbox. Das Signal ist eindeutig: Eine Telefonnummer, die von einer privaten IP innerhalb weniger Minuten nach einer Anmeldung aus einer neuen Region hinzugefügt wird, ist kein False Positive. Verknüpfen Sie den Alarm mit automatischer Sitzungsrevokation und erzwingen Sie eine erneute Authentifizierung über einen Kanal, den der Angreifer nicht kontrolliert.

Deaktivieren Sie Device-Code-Authentifizierungsflows für Benutzerkonten, sofern kein dokumentierter Geschäftsbedarf besteht. Die meisten Unternehmen haben ihn einmalig für ein CLI-Tool aktiviert und die Richtlinie nie wieder überprüft. Conditional Access kann ihn auf bestimmte Anwendungen und vertrauenswürdige Netzwerke einschränken. Tun Sie das diese Woche.

Auf der ACH-Seite: Schreiben Sie eine Out-of-Band-Verifizierung für jede Lieferantenzahlungsänderung oder neue Rechnung über einem Schwellenwert vor, den Ihr CFO festlegt. Rückruf auf eine hinterlegte Nummer – nicht auf eine Nummer aus der E-Mail. Das ist eine Kontrolle aus den 1990er-Jahren, die einen Angriff aus dem Jahr 2026 stoppt, weil der Angriff selbst aus den 1990er-Jahren stammt – nur mit KI-Politur.

Suchen Sie schließlich nach dem Domain-Muster. Blockieren Sie ausgehende DNS-Anfragen an die von Microsoft veröffentlichten Passkey-Themenwurzeln und fügen Sie eine Proxy-Regel für jede Subdomain hinzu, die den eigenen Unternehmensnamen auf einer in den letzten neunzig Tagen registrierten Domain enthält. Diese eine Regel hätte einen bedeutenden Anteil der beobachteten Einbrüche verhindert.

Wichtigste Erkenntnisse

• Passkeys sind kryptografisch phishing-resistent, aber Enrollment- und Recovery-Flows bleiben vollständig social-engineerbar – und Angreifer haben diese Lücke industrialisiert.
• Device-Code-Phishing umgeht MFA, ohne Zugangsdaten oder Cookies zu stehlen; die meisten Conditional-Access-Richtlinien erkennen dies standardmäßig nicht.
• Die ACH-Kampagne erreichte in drei Tagen über eine Million Postfächer – mit generativer KI für Vorlagen und öffentlichen Quellen für die Führungskräfteimitation.
• Persistenz entsteht durch angreifer-registrierte MFA-Methoden, die unmittelbar nach dem ersten Zugang hinzugefügt werden; die Erkennung neuer Methoden-Registrierungen ist nun eine erstklassige Kontrolle.
• Der Bedrohungscluster umfasst Storm-3121, Storm-3032, UNC6671, Cordial Spider und ist mit ShinyHunters, Falcon und der Helix-Erpressungsmarke verbunden – initialer Zugang hier finanziert nachgelagert Ransomware.

Teams, die in den nächsten 90 Tagen Passkey-Deployments evaluieren, sollten sich jetzt eine andere Frage stellen. Nicht „eliminiert das Phishing", sondern „wer verantwortet den Enrollment-Prozess, und was kostet es uns, diesen Prozess für Angreifer feindselig zu gestalten?" Die Antwort wird sich in Headcount, in der Neugestaltung von Helpdesk-Prozessen und in einem Anbietergespräch über Conditional-Access-Lizenzen zeigen, für das niemand ein Budget eingeplant hat.