Passkeys gelten zu Recht als ein wichtiger Schritt weg von Passwörtern und klassischen MFA-Codes. Sie sind phishing-resistenter, komfortabler und reduzieren viele bekannte Angriffspfade. Genau deshalb ist eine aktuelle Angriffskampagne gegen Microsoft-365-Nutzer so lehrreich: Die Angreifer attackieren nicht die Kryptografie von Passkeys selbst, sondern den Registrierungsprozess – und das Vertrauen der Mitarbeitenden in vermeintliche IT-Sicherheitsanweisungen.
BleepingComputer berichtete am 8. Juli 2026 über eine Pishing-Kampagne, bei der Angreifer Microsoft-365-Nutzer telefonisch dazu bringen wollen, angeblich einen neuen Microsoft-Entra-Passkey zu registrieren. Die Kampagne wird mit einem Bedrohungsakteur in Verbindung gebracht, den Okta als O-UNC-066 verfolgt und der laut Bericht mit der Erpressungsgruppe „Pink“ assoziiert wird. (BleepingComputer)
Worum geht es?
Microsoft erlaubt Administratoren, sogenannte Registration Campaigns einzurichten. Damit können Nutzer während des Anmeldevorgangs dazu aufgefordert werden, stärkere Authentifizierungsmethoden wie Passkeys oder Microsoft Authenticator einzurichten. Laut Microsoft durchlaufen Nutzer dabei zuerst den normalen Login inklusive MFA und werden danach zur Einrichtung der Zielmethode aufgefordert. (Microsoft Learn)
Genau diese legitime Sicherheitsfunktion nutzen Angreifer als Vorwand. Sie rufen Mitarbeitende an, geben sich als IT- oder Security-Support aus und behaupten, dass aus Sicherheitsgründen ein neuer Passkey eingerichtet werden müsse. Danach verweisen sie auf eine täuschend echt wirkende Phishing-Seite, die den Microsoft-Entra-Registrierungsprozess imitiert und teilweise mit dem Branding der Zielorganisation angepasst ist. (BleepingComputer)
Wichtig: Das ist keine klassische technische Schwachstelle im Sinne eines CVE. Die Schwachstelle liegt in der Kombination aus Social Engineering, ungewohnten Passkey-Prozessen und unzureichend abgesicherter Registrierung neuer Authentifizierungsmethoden.
Wie wird der Angriff ausgenutzt?
Der Angriff funktioniert grob in fünf Schritten.
Zuerst wird das Opfer telefonisch kontaktiert. Der Angreifer schafft Dringlichkeit und Autorität: „Wir führen gerade ein Sicherheitsupdate durch“, „Ihr Konto muss auf Passkey umgestellt werden“ oder „Ohne Registrierung verlieren Sie den Zugriff“. Das ist typisch für Vishing – Voice Phishing –, bei dem der persönliche Anruf Vertrauen erzeugen soll.
Im zweiten Schritt landet der Nutzer auf einer Phishing-Seite. Diese sieht aus wie ein Microsoft- oder Entra-Portal und kann Logos, Farben oder Hintergründe der betroffenen Organisation enthalten. Okta beschreibt, dass der beobachtete Phishing-Kit nicht einfach ein transparenter Adversary-in-the-Middle-Proxy ist, sondern ein operatorgesteuertes PHP-Panel, mit dem der Angreifer den Ablauf nahezu in Echtzeit an die MFA-Methode des Opfers anpassen kann. (okta.com)
Drittens gibt der Nutzer seine Zugangsdaten und MFA-Informationen ein oder bestätigt eine Push-Anfrage. Der Angreifer nutzt diese Informationen parallel, um sich am echten Microsoft-365-Konto anzumelden. Je nach MFA-Methode wird das Opfer zur Eingabe eines SMS- oder TOTP-Codes bewegt oder dazu gebracht, eine Authenticator-Push-Anfrage zu bestätigen. (okta.com)
Viertens registriert der Angreifer einen eigenen Passkey im echten Konto. Während das Opfer glaubt, selbst einen neuen Passkey einzurichten, nutzt der Angreifer den erfolgreichen Zugriff, um eine Authentifizierungsmethode unter seiner Kontrolle hinzuzufügen. Das ist der kritische Punkt: Ein neu registrierter Passkey kann dem Angreifer künftig einen starken, komfortablen Zugang ermöglichen – ohne dass er jedes Mal erneut Passwort und MFA-Code abgreifen muss.
Fünftens wird das Opfer weiter beschäftigt. Laut Okta zeigt das Phishing-Kit unter anderem Microsoft-ähnliche Seiten, die den Nutzer auffordern, eine angebliche Wiederherstellungsphrase zu speichern oder Wörter daraus zu bestätigen. Solche BIP-39-Seed-Phrasen haben laut Okta keine direkte Rolle bei der legitimen Microsoft-Entra-Passkey-Registrierung. Sie dienen vermutlich als Ablenkung, während der Angreifer im Hintergrund die echte Registrierung abschließt. (okta.com)
Warum ist das gefährlich?
Passkeys sind grundsätzlich eine starke Schutzmaßnahme. Microsoft beschreibt Passkeys als phishing-resistent, weil sie auf origin-bound Public-Key-Kryptografie basieren: Der private Schlüssel verbleibt auf dem Gerät, der öffentliche Schlüssel liegt beim Dienst, und der Passkey funktioniert nur für die Website oder App, für die er erstellt wurde. (Microsoft Learn)
Der Angriff umgeht diese Stärke nicht kryptografisch. Er verschiebt den Angriff nach vorne in den Registrierungsprozess. Wenn ein Angreifer es schafft, während einer aktiven Social-Engineering-Session Zugriff auf das Konto zu erhalten und eine eigene Authentifizierungsmethode zu registrieren, wird aus einer eigentlich sicheren Methode ein Persistenzmechanismus.
Das macht solche Angriffe für Unternehmen besonders kritisch. Nach erfolgreicher Kontoübernahme können Angreifer schnell auf Microsoft-365-Daten zugreifen. BleepingComputer berichtet, dass die Pink-Gruppe nach Account-Zugriffen Daten aus SharePoint und OneDrive exfiltriert haben soll. (BleepingComputer)
Woran Mitarbeitende den Betrug erkennen können
Ein legitimer Passkey-Rollout sollte niemals überraschend per Telefon erzwungen werden. Warnsignale sind:
- Ein angeblicher IT-Mitarbeiter ruft ungefragt an und fordert zur sofortigen Passkey-Registrierung auf.
- Der Link enthält Begriffe wie „passkey“, führt aber nicht auf eine offizielle Microsoft- oder Unternehmensdomain.
- Der Anrufer bleibt während der Anmeldung in der Leitung und gibt genaue Anweisungen.
- Der Nutzer soll MFA-Codes, Nummern aus Push-Anfragen oder Bestätigungen weitergeben.
- Die Seite zeigt ungewöhnliche Schritte wie Recovery-Phrasen, Seed-Wörter oder vermeintliche Wiederherstellungsschlüssel.
- Die Registrierung findet nicht über den bekannten Microsoft-Flow oder das bekannte Unternehmensportal statt.
Die einfache Regel für Endanwender lautet: Wenn ein Anruf zur Änderung von Anmeldemethoden auffordert, auflegen und den internen IT-Support über einen bekannten, unabhängigen Kanal kontaktieren.
Wie Unternehmen sich schützen können
1. Passkey-Registrierung organisatorisch absichern
Passkeys sollten eingeführt werden – aber kontrolliert. Unternehmen brauchen klare Kommunikationsregeln: Wer kündigt Passkey-Rollouts an? Über welche Kanäle? Welche Links sind legitim? Wie sieht der echte Prozess aus? Mitarbeitende sollten vorab wissen, dass IT-Support niemals telefonisch nach MFA-Codes fragt oder Nutzer durch geheime Registrierungsprozesse führt.
2. Registrierung von Sicherheitsinformationen mit Conditional Access schützen
Microsoft bietet die Möglichkeit, die Registrierung von Sicherheitsinformationen über Conditional Access abzusichern. Damit kann der Registrierungsprozess ähnlich wie eine Anwendung behandelt und zum Beispiel an Bedingungen wie vertrauenswürdige Netzwerke, Gerätekonformität oder MFA-Anforderungen geknüpft werden. (Microsoft Learn)
Praktisch bedeutet das: Neue Authentifizierungsmethoden sollten nicht beliebig von jedem Ort und jedem Gerät aus registriert werden können. Gerade für privilegierte Nutzer sollte die Registrierung nur von verwalteten Geräten, vertrauenswürdigen Standorten oder über definierte Onboarding-Prozesse erlaubt sein.
3. Phishing-resistente MFA gezielt erzwingen
Microsoft Entra unterstützt Authentication Strengths, darunter eine phishing-resistente MFA-Stärke. Microsoft beschreibt diese als die restriktivste integrierte Option. Für Administratoren, privilegierte Rollen und sensible Anwendungen sollte eine solche Stärke konsequent geprüft und eingesetzt werden. (Microsoft Learn)
Wichtig ist aber: Phishing-resistente MFA schützt nur dann vollständig, wenn auch der Lifecycle der Authentifizierungsmethoden abgesichert ist. Wer neue Faktoren zu leicht registrieren kann, öffnet eine Seitentür.
4. Helpdesk-Verifikation standardisieren
Okta empfiehlt ausdrücklich, Verfahren zu etablieren, mit denen Nutzer die Identität von Helpdesk-Mitarbeitenden prüfen können. (okta.com)
Das kann zum Beispiel bedeuten:
- Rückruf nur über veröffentlichte interne Helpdesk-Nummern.
- Ticketnummern, die im internen Portal überprüfbar sind.
- Kein Support per privater Telefonnummer.
- Keine MFA-Bestätigung während eines ungeplanten Support-Anrufs.
- Klare Eskalationswege für verdächtige Anrufe.
Diese Prozesse müssen einfach sein. Wenn die sichere Alternative kompliziert ist, wählen Mitarbeitende im Stress den schnelleren, unsicheren Weg.
5. Authenticator- und Passkey-Lifecycle überwachen
Microsoft weist darauf hin, dass Administratoren Audit Logs, Sign-in Logs und Nutzerbenachrichtigungen verwenden können, um Passkey-Erstellung und -Nutzung zu überwachen. Zudem gibt es keine automatische Passkey-Ablaufzeit; Lifecycle-Hygiene bleibt also eine administrative Aufgabe. (Microsoft Learn)
Security-Teams sollten daher gezielt auf folgende Ereignisse achten:
- Neue Passkey- oder FIDO2-Registrierungen.
- Neue Authentifizierungsmethoden kurz nach verdächtigen Logins.
- Registrierungen aus ungewohnten Ländern, ASNs oder IP-Bereichen.
- Änderungen bei privilegierten Konten.
- Mehrere MFA-Fehlversuche vor erfolgreicher Registrierung.
- Datenzugriffe in SharePoint, OneDrive oder Exchange direkt nach Methodenänderungen.
6. Standort-, Geräte- und Risiko-Signale nutzen
Okta empfiehlt, Anfragen aus Regionen zu blockieren, in denen die Organisation keine Services anbietet, und sensible Anwendungen an Bedingungen wie verwaltete Geräte und Endpoint-Schutz zu knüpfen. (okta.com)
Für Microsoft-365-Umgebungen heißt das: Conditional Access sollte nicht nur „MFA ja/nein“ prüfen, sondern Kontext berücksichtigen. Ein Login von einem unbekannten Gerät aus einem ungewöhnlichen Land sollte nicht dieselben Möglichkeiten haben wie ein Login von einem verwalteten Unternehmensgerät im normalen Arbeitskontext.
Fazit
Passkeys bleiben eine sehr gute Sicherheitsmaßnahme. Der aktuelle Angriff zeigt aber: Starke Authentifizierung allein reicht nicht, wenn der Registrierungsprozess schwach ist.
Die eigentliche Lehre lautet: Unternehmen müssen nicht nur den Login schützen, sondern den gesamten Identity Lifecycle – vom Onboarding über die Registrierung neuer Faktoren bis zur Überwachung und Entfernung alter Methoden. Wer Passkeys einführt, sollte parallel Kommunikationsprozesse, Helpdesk-Verifikation, Conditional Access, Monitoring und Incident Response nachschärfen.
Denn Angreifer gehen dorthin, wo Sicherheit noch ungewohnt ist. Und gerade neue Sicherheitsfunktionen sind für Social Engineering attraktiv, solange Mitarbeitende nicht genau wissen, wie ein legitimer Prozess aussieht.