Passkey
Vishing-Angriffe auf Passkey-Registrierungen gefährden Microsoft-365-Konten
Passkey-Rollout als Einfallstor: Wie Cyberkriminelle die Registrierung per Vishing kapern
Passkeys sollen Passwörter ablösen und Phishing-Angriffe weitgehend ins Leere laufen lassen. Doch Cyberkriminelle greifen inzwischen genau den Moment an, in dem diese vermeintlich sichere Technologie eingerichtet wird. Statt Passkeys zu knacken, bringen sie ihre Opfer per Telefon dazu, den Angreifern selbst einen dauerhaften Zugang zum Unternehmenskonto einzurichten.
Arkadiusz Krowczynski, Principal Product Acceleration Specialist bei Okta erklärt die Vorgehensweise.
Aktuelle Analysen einer groß angelegten Angriffswelle zeigen, wie professionell Cyberkriminelle inzwischen legitime Sicherheitsinitiativen für ihre Zwecke instrumentalisieren. Eine unter der Bezeichnung O-UNC-066 und in Sicherheitskreisen auch als „Pink“ bekannte Gruppierung nimmt demnach seit April 2026 gezielt die Passkey-Registrierungsprozesse von Microsoft-365-Kunden ins Visier.
Betroffen sind große Unternehmen aus unterschiedlichen Branchen, darunter Lebensmittelindustrie, Technologie, Gesundheitswesen, Automobilbau, Bauwirtschaft und Luftfahrt. Das Ziel der Angriffe ist offenbar nicht nur der Zugriff auf sensible Unternehmensdaten. Die kompromittierten Konten sollen anschließend auch als Ausgangspunkt für Datendiebstahl, Erpressung und weitere Angriffe innerhalb der Organisation dienen.
Der Angriff ist besonders wirkungsvoll, weil er nicht gegen eine technische Schwachstelle gerichtet ist. Stattdessen missbrauchen die Täter das Vertrauen der Beschäftigten in die eigene IT-Abteilung.
Viele Unternehmen fordern ihre Mitarbeiter inzwischen aktiv dazu auf, Passkeys einzurichten. Administratoren können dazu sogenannte Nudge-Kampagnen aktivieren, die Nutzer beim regulären Login auf die Registrierung eines Passkeys hinweisen. Was eigentlich die Sicherheit erhöhen soll, liefert den Angreifern einen nahezu perfekten Vorwand.
Voice-Phishing nutzt legitime Sicherheitskampagnen als Vorwand
Die Täter registrieren Domains, die Begriffe wie „Passkey“ enthalten, und kontaktieren ausgewählte Beschäftigte telefonisch. Bei diesen Voice-Phishing-Angriffen, kurz Vishing, geben sie sich professionell als interner IT-Support aus. Sie behaupten, die Passkey-Registrierung müsse dringend abgeschlossen oder überprüft werden.
Die Glaubwürdigkeit entsteht durch den organisatorischen Kontext. Wer bereits interne E-Mails, Login-Hinweise oder Schulungen zur Einführung von Passkeys erhalten hat, hält einen entsprechenden Anruf möglicherweise für plausibel. Die Angreifer müssen deshalb keine vollkommen neue Geschichte erfinden. Sie knüpfen lediglich an eine reale Sicherheitsmaßnahme an.
Phishing in Echtzeit statt starrer Login-Maske
Folgen die Betroffenen den telefonischen Anweisungen, werden sie auf präparierte Webseiten geleitet. Die verwendeten Subdomains sind individuell auf das jeweilige Zielunternehmen zugeschnitten und imitieren bekannte Microsoft-365-Anmeldeseiten.
Firmenlogos, Hintergrundbilder und Designelemente aus offiziellen Content-Netzwerken sorgen dafür, dass die Seiten auf den ersten Blick authentisch wirken. Hinter der Fassade arbeitet jedoch kein gewöhnliches, vollständig automatisiertes Phishing-Kit.
Die Angreifer setzen offenbar nicht auf einen klassischen Adversary-in-the-Middle-Proxy, der Anmeldedaten und Sitzungstoken automatisch weiterleitet. Stattdessen wird das Opfer über ein manuell gesteuertes PHP-Panel nahezu in Echtzeit durch den Anmeldeprozess geführt.
Ein Heartbeat-Mechanismus fragt in Abständen von etwa einer Sekunde ab, welche Eingabemaske angezeigt werden soll. Der Täter kann dadurch im Hintergrund flexibel auf die jeweilige Authentifizierungssituation reagieren.
Verlangt das echte Unternehmensportal einen zeitbasierten Einmalcode, erscheint auf der Phishing-Seite ein entsprechendes Eingabefeld. Wird eine SMS-Bestätigung benötigt, zeigt das System eine Maske für den SMS-Code. Kommt eine Push-Benachrichtigung mit Number-Matching zum Einsatz, wird auch dieser Schritt nachgebildet.
Der Angreifer sieht die eingegebenen Informationen in seinem Kontrollpanel und überträgt sie parallel in den echten Login-Prozess. Währenddessen hält der vermeintliche Supportmitarbeiter das Opfer am Telefon, erklärt die einzelnen Schritte und zerstreut mögliche Zweifel.
So entsteht kein statischer Phishing-Angriff, sondern ein interaktives Social-Engineering-Szenario, bei dem technische Infrastruktur und telefonische Manipulation eng ineinandergreifen.
Die gefälschte Passkey-Registrierung
Der entscheidende Schritt erfolgt nach dem erfolgreichen Login. Das Opfer soll glauben, nun einen eigenen Passkey für sein Konto einzurichten. Tatsächlich registriert der Angreifer im Hintergrund jedoch einen von ihm kontrollierten Passkey.
Dafür nutzen die Täter eine grundlegende Wissenslücke: Viele Anwender wissen nicht, wie ein echter Passkey-Registrierungsprozess auf Betriebssystem- oder Geräteebene aussieht. Sie können deshalb nur schwer einschätzen, welche Dialoge legitim sind und welche lediglich nachgebildet wurden.
Das Phishing-Kit präsentiert den Nutzern eine gefälschte Seite, die angeblich zur Sicherung eines „Recovery Keys“ dient. Angezeigt wird eine Liste von Wörtern, die wie eine Wiederherstellungsphrase aus der Kryptowelt wirkt.
Technisch orientieren sich diese Wortlisten offenbar an BIP-39-Seed-Phrases. Für die tatsächliche Passkey-Registrierung besitzen sie jedoch keinerlei Bedeutung. Die Nutzer werden aufgefordert, die Begriffe zu notieren und anschließend zur Bestätigung eines der Wörter erneut einzugeben.
Dieser Schritt ist kein Sicherheitsmechanismus, sondern Ablenkung. Während das Opfer damit beschäftigt ist, die vermeintliche Wiederherstellungsphrase zu sichern, hinterlegt der Angreifer im echten Benutzerkonto seinen eigenen Passkey.
Anschließend zeigt die gefälschte Webseite eine Erfolgsmeldung an. Der Nutzer glaubt, die Registrierung ordnungsgemäß abgeschlossen zu haben. Tatsächlich hat er dem Angreifer einen neuen, kryptografisch abgesicherten Anmeldefaktor verschafft.
Eine dauerhafte Hintertür ohne Passwort und MFA-Gerät
Der registrierte Passkey kann dem Angreifer einen persistenten Zugriff auf das Konto ermöglichen. Das macht diesen Angriffsweg besonders gefährlich.
Nach der erfolgreichen Registrierung benötigt der Täter unter Umständen weder das ursprüngliche Passwort noch das Smartphone oder den bisherigen MFA-Faktor des Nutzers. Der neue Passkey wird vom Identitätssystem als legitime Authentifizierungsmethode behandelt.
Damit unterscheidet sich der Angriff grundlegend von vielen klassischen Phishing-Kampagnen. Gestohlene Passwörter können geändert, Sitzungen beendet und MFA-Codes ungültig werden. Ein unbemerkt registrierter Passkey bleibt dagegen so lange nutzbar, bis er im Konto erkannt und ausdrücklich entfernt wird.
Die Sicherheitsstärke des Passkeys wird damit gegen das betroffene Unternehmen gerichtet.Der Angreifer schafft sich keinen provisorischen Zugang, sondern eine vertrauenswürdige und phishing-resistente Authentifizierungsmethode für das kompromittierte Konto.
Das eigentliche Angriffsziel ist der Enrollment-Prozess
Der Fall zeigt eine zentrale Herausforderung moderner Identitätssicherheit: Je stärker ein Authentifizierungsverfahren ist, desto attraktiver wird der Prozess, mit dem es eingerichtet, zurückgesetzt oder wiederhergestellt wird.
Passkeys selbst bleiben ein wichtiger Baustein für eine passwortlose und phishing-resistente Authentifizierung. Unternehmen dürfen deren Einführung jedoch nicht auf die technische Aktivierung einer neuen Login-Methode reduzieren.
Der kritische Kontrollpunkt ist das Enrollment. Kann ein Nutzer aus einem unbekannten Netzwerk, auf einem nicht verwalteten Gerät und ohne zusätzliche Identitätsprüfung einen neuen Passkey registrieren, entsteht ein gefährlicher Umgehungsweg.
Cyberkriminelle müssen dann nicht die Kryptografie überwinden. Es genügt, den rechtmäßigen Nutzer so lange zu manipulieren, bis dieser die Registrierung des Angreifers unbewusst autorisiert.
Passkey-Registrierungen technisch begrenzen
Unternehmen sollten die Registrierung neuer Passkeys und MFA-Methoden deshalb an klare Bedingungen knüpfen. Enrollment-Prozesse sollten grundsätzlich nur aus vertrauenswürdigen Umgebungen heraus möglich sein. Dazu zählen beispielsweise:
- verwaltete und registrierte Endgeräte,
- bekannte Unternehmensnetzwerke,
- abgesicherte VPN-Verbindungen,
- zuvor verifizierte Benutzer-Sessions,
- starke risikobasierte Zugriffskontrollen.
Ist eine Registrierung außerhalb dieser Bedingungen erforderlich, sollte eine zusätzliche Identitätsprüfung erfolgen. Eine Möglichkeit ist ein befristeter Zugangscode, der erst nach einer verlässlichen Verifikation durch den Helpdesk ausgegeben wird.
Entscheidend ist, dass eine bereits kompromittierte Sitzung allein nicht ausreicht, um einen dauerhaften neuen Authentifizierungsfaktor hinzuzufügen.
Monitoring muss Faktorregistrierungen sichtbar machen
Auch das Security-Monitoring muss stärker auf Veränderungen an Benutzerkonten ausgerichtet werden. Viele Organisationen konzentrieren sich vor allem auf verdächtige Login-Versuche. Mindestens ebenso relevant sind jedoch neu registrierte Faktoren.
Alarmierungen sollten unter anderem ausgelöst werden, wenn:
- ein Passkey von einer unbekannten IP-Adresse registriert wird,
- die Registrierung aus einem ungewöhnlichen Land oder Standort erfolgt,
- ein nicht verwaltetes Gerät beteiligt ist,
- kurz nach einer Passwort- oder MFA-Anmeldung ein neuer Faktor hinzugefügt wird,
- mehrere Authentifizierungsmethoden in kurzer Zeit geändert werden,
- ein Helpdesk-Kontakt und eine Faktorregistrierung zeitlich zusammenfallen.
Darüber hinaus sollten Sicherheitsteams regelmäßig prüfen, welche Passkeys und MFA-Methoden in besonders privilegierten oder sensiblen Konten hinterlegt sind.
Technische Schutzmaßnahmen allein reichen nicht aus. Beschäftigte müssen verstehen, dass auch eine angebliche Sicherheitsmaßnahme Teil eines Angriffs sein kann.
Schulungen sollten daher nicht nur vor verdächtigen Links oder klassischen Phishing-Mails warnen. Sie müssen konkret erklären, wie legitime Passkey-Dialoge aussehen, welche Schritte bei einer Registrierung üblich sind und welche Aufforderungen niemals dazugehören.
Ein seriöser Passkey-Prozess verlangt keine Kryptowährungs-ähnliche Seed-Phrase. Der IT-Support sollte Nutzer nicht unaufgefordert telefonisch durch eine Anmeldung führen. MFA-Codes, Number-Matching-Werte und Wiederherstellungsinformationen dürfen nicht am Telefon weitergegeben oder auf einer vom Anrufer genannten Webseite eingegeben werden.
Helpdesk-Prozesse werden Teil der Sicherheitsarchitektur
Auch Supportorganisationen müssen auf Vishing-Kampagnen vorbereitet sein. Anfragen zur Einrichtung, Wiederherstellung oder Änderung von Authentifizierungsfaktoren sollten ausschließlich über definierte Ticketsysteme abgewickelt werden.
Telefonische Identitätsprüfungen dürfen nicht allein auf leicht verfügbarem Wissen wie Name, Abteilung, Personalnummer oder Geburtsdatum beruhen. Sinnvoller sind sichere Rückrufverfahren, Genehmigungen durch Vorgesetzte, Geräteprüfungen oder mehrstufige Verifikationsprozesse.
Ebenso wichtig ist eine klare Kommunikationsregel: Mitarbeiter müssen wissen, über welche Kanäle die IT tatsächlich Kontakt aufnimmt und wie sie einen unerwarteten Supportanruf unabhängig überprüfen können.
Fazit: Phishing-Resistenz beginnt vor der Anmeldung
Passkeys erschweren viele klassische Phishing-Angriffe erheblich. Sie beseitigen jedoch nicht das Risiko menschlicher Manipulation.
Die Angriffe der Gruppe O-UNC-066 zeigen, dass sich Social Engineering zunehmend auf die Einführungs-, Registrierungs- und Wiederherstellungsprozesse moderner Authentifizierung verlagert. Die Täter greifen nicht den Passkey selbst an, sondern die organisatorischen Abläufe rund um seine Einrichtung.
Unternehmen benötigen deshalb mehr als eine neue Authentifizierungstechnologie. Erforderlich ist ein abgesicherter Enrollment-Prozess, der Gerätezustand, Netzwerk, Identität und Risikosignale gemeinsam bewertet.
Die entscheidende Sicherheitsfrage lautet künftig nicht nur: Wer kann sich anmelden? Ebenso wichtig ist: Wer darf unter welchen Bedingungen eine neue Anmeldemethode registrieren.