Executive Summary
Seit April 2026 setzt ein als O-UNC-066 nachverfolgter Bedrohungsakteur, der eine DLS-Website namens „Pink“ betreibt (von Palo Alto Networks Unit 42 als „CL-CRI-1147“ bezeichnet), ein über ein Panel gesteuertes Phishing-Kit ein, das auf den Registrierungsprozess für Passkeys bei Microsoft-365-Kunden abzielt.
Okta hat beobachtet, dass sich dieses Aktivitätscluster gezielt gegen Unternehmen aus den Branchen Lebensmittel und Getränke, Technologie, Gesundheitswesen, Automobil, Bauwesen und Luftfahrt richtet. Die Hauptmotivation der Angreifer ist Datenerpressung.
Der Angreifende registriert Domains, die das Wort „Passkey“ enthalten, als Teil eines sprachgestützten Phishing-Betrugs („Vishing“). Anschließend werden die anvisierten Benutzenden telefonisch angerufen, um sie davon zu überzeugen, dass sie einen neuen Passkey registrieren müssen.
Nutzer:innen werden zu einem Phishing-Kit weitergeleitet, das den Microsoft-Passkey-Registrierungsprozess sehr genau nachahmt. Die Gestaltung zielt offenbar darauf ab, betroffenen Zielpersonen vorzuspiegeln, sie richteten gerade einen Passkey bei Microsoft ein – während die angreifende Seite gleichzeitig ihren eigenen Passkey im Microsoft-Konto der Betroffenen registriert.
Dieser Vorwand kommt genau zur richtigen Zeit – seit Mai 2026 können Microsoft-Administrator:innen Passkey-Registrierungskampagnen erstellen, die Nutzer:innen beim Sign-in daran erinnern oder sie „anstupsen“, Passkeys einzurichten, und unter bestimmten Umständen sind diese Hinweise standardmäßig aktiviert.
Angreifende haben dieses gut gemeinte Sicherheits-Upgrade als Vorwand genutzt, um den Registrierungsprozess zu missbrauchen und ihre Ziele voranzutreiben.
Unsere Analyse des Phishing-Kits ergab, dass es nicht versucht, die Föderation zu Identity-Drittanbietern wie Okta zu verarbeiten. In der Folge haben wir keine direkte Kompromittierung von Microsoft-Accounts beobachtet.
Wir haben dennoch in einem separaten Blogbeitrag Hinweise dazu veröffentlicht, wie sich Phishing-Resistenz bei der Registrierung und Wiederherstellung von Authentifikatoren anwenden lässt.
Bedrohungsanalyse
Bei der von uns beobachteten Bedrohungsaktivität erstellt der Angreifende zielspezifische Subdomains, die Microsoft Entra ID-Login-Seiten nachahmen. Die Seiten werden mit dem legitimen Branding der jeweiligen betroffenen Organisation individualisiert. Das generische Microsoft-Design wird über das Content Delivery Network von Microsoft geladen, während die brandingrelevanten Elemente der jeweiligen Zielorganisation (Logo und Hintergrund) als Teil der Konfiguration für jedes Ziel pro Subdomain im Voraus bereitgestellt und vom Backend des Phishing-Kits ausgeliefert werden.
Das Kit ist kein transparenter Adversary-in-the-Middle (AitM)-Proxy, eine der am häufigsten beobachteten Arten von Phishing-Kits, die darauf ausgelegt sind, Anmeldedaten, MFA-Token und Sitzungs-Token zu sammeln. Es handelt sich um ein betreibergesteuertes PHP-Panel, in dem ein Angreifender die Opfer mithilfe eines 1-Sekunden-Heartbeat-Polling-Mechanismus nahezu in Echtzeit durch verschiedene Phasen der Authentifizierung steuert. Die bedienende Person kann das Kit nutzen, um die User Experience während der Sitzung individuell an die MFA-Anforderungen der jeweiligen Zielperson anzupassen (TOTP, Push-Benachrichtigung mit Nummernvergleich, SMS-OTP). Dieses operative Design entspricht den Vishing-Methoden, die im öffentlichen Blogbeitrag von Okta vom November 2025 dokumentiert wurden: „Phishing-Kits passen sich dem Skript der Anrufer:innen an.“ Die anrufende Person kann in Echtzeit steuern und anpassen, welche Phishing-Seiten und Benachrichtigungen eine Zielperson sieht.
Es ist wahrscheinlich, dass die angreifende Seite das Kit nutzt, um die Kontrolle über das Konto zu übernehmen und die betroffene Person dazu zu verleiten, eine von Angreifenden initiierte Passkey-Registrierung zu bestätigen.
Okta Threat Intelligence verwendete aus dem Phishing-Kit abgeleiteten Code, um den folgenden Flow nachzubilden, der dem Passkey-Registrierungsprozess für Microsoft Entra stark ähnelt.
Die erste Seite des Phishing-Kits (/gate) zeigt ein Seitenladesymbol, während das Phishing-Kit Anti-Analyse-Prüfungen durchführt. Die zweite Seite (/identify) fordert einen Benutzernamen. Das Phishing-Kit leitete zum Zeitpunkt unserer Analyse nicht an einen föderierten Identity-Anbieter weiter.
Abbildung 1. Die Microsoft-Anmeldeseite O-UNC-066, neu generiert mit Code, der aus dem Phishing-Kit extrahiert wurde.
Die nächste Seite (/password) fordert den Benutzenden zur Eingabe eines Passworts auf. Die erfassten Anmeldedaten werden in einer POST-Anfrage mit einem Zeitstempel und einer ID an ein Operator-Panel unter /backend.php gesendet.
Abbildung 2: Die Microsoft-Passwortabfrageseite von O-UNC-066, neu generiert mit Code, der aus dem Phishing-Kit extrahiert wurde.
Unsere Annahme ist, dass eine das Phishing-Kit bedienende Person (bei der es sich um eine andere Einzelperson als die anrufende Person am Telefon handeln kann) die Zugangsdaten der Zielperson innerhalb weniger Sekunden erfasst und auf der legitimen Microsoft-Anmeldeseite des jeweiligen Tenants eingibt.
Die Zielperson sieht daraufhin eine Verarbeitungsseite (/processing), die einen weiteren Ladebildschirm anzeigt, während das Phishing-Kit auf die nächste Anweisung der bedienenden Person wartet. Wir gehen davon aus, dass diese kurze Verzögerung erforderlich ist, damit sich eine angreifende Seite mit den gestohlenen Zugangsdaten am legitimen Microsoft-Konto der betroffenen Person authentifizieren, die angezeigten MFA-Aufforderungen einsehen und die nächste Seite des Phishing-Kits auswählen kann, die der Person angezeigt werden soll.
nächste Seite des Phishing-Kits auswählen kann, die der Person angezeigt werden soll.
- Falls sich die bedienende Person entscheidet oder dazu gezwungen ist, eine SMS-OTP-Aufforderung zu absolvieren, wird die Zielperson auf eine Seite namens /submit-otp weitergeleitet. Das erfasste OTP wird in einer POST-Anfrage an das Operator-Panel unter /backend.php gesendet.
- Wenn der Operator sich dafür entscheidet oder dazu gezwungen wird, eine TOTP-Herausforderung abzuschließen, wird der Benutzer:in auf eine Seite namens /submit-authenticator weitergeleitet. Das erfasste OTP wird in einer POST-Anfrage an das Operator-Panel unter /backend.php gesendet.
- Entscheidet sich die bedienende Person dazu oder ist sie gezwungen, eine Push-MFA-Aufforderung durchzuführen, wird die Zielperson auf eine Seite namens /approve-authenticator weitergeleitet (siehe Abbildung unten) und aufgefordert, die von der bedienenden Person bereitgestellte Nummer in die eigene Authentifikator-App einzugeben.
Abbildung 3. Die MFA-Abfrageseite von O-UNC-066, neu generiert mit Code, der aus dem Phishing-Kit extrahiert wurde.
In dieser Phase eines Angriffs wurde die betroffene Person am Telefon dazu verleitet, den Zugriff der angreifenden Seite auf ihr Microsoft-365-Konto zu bestätigen.
Passend zum Vorwand mit dem Passkey können die Angreifenden die Betroffenen anschließend auf die Seite /passkey/register weiterleiten, auf der diese aufgefordert werden, einen Passkey zu erstellen.
Abbildung 4. Die Passkey-Registrierungsseite von O-UNC-066, neu generiert mithilfe von Code, der aus dem Phishing-Kit extrahiert wurde.
Das Phishing-Kit scheint die mangelnde Vertrautheit der Benutzer:innen mit der Passkey-Authentifizierung auszunutzen. Bei einer echten Registrierung eines Passkeys würde die betroffene Person vermutlich einen Systemdialog erwarten, um einen Passkey auf ihrem Gerät zu registrieren. Die Passkey-Seiten in diesem Phishing-Kit scheinen diesen Prozess nachzuahmen, ohne einen Passkey zu registrieren.
Auf der Seite /passkey wird der Zielperson eine Seite im Microsoft-Design angezeigt, die dazu auffordert, einen „Wiederherstellungsschlüssel“ aus einer von Angreifenden gesteuerten Liste von BIP-39-Phrasen zu speichern. Dies ähnelt stark den Methoden, die in einigen Kryptowährungsanwendungen verwendet werden, um einprägsame Seed-Phrasen zu generieren.
Abbildung 5. Die optionale Passkey-Seite von O-UNC-066, unter Verwendung von aus dem Phishing-Kit extrahiertem Code.
Eine nachfolgende /passkey/check-Seite fordert Benutzer:innen auf, das letzte Wort zu verifizieren, das in der Seed-Phrase verwendet wurde.
Uns ist keine direkte Anwendbarkeit von BIP-39-Seed-Phrases auf Microsoft Entra oder dessen Passkey-Registrierungsprozess bekannt. Eine angreifende Partei, die sich bereits unbefugten Zugriff auf ein Konto verschafft hat, kann eigene Wiederherstellungscodes über einen Prozess erstellen, der keinerlei Eingabe der tatsächlichen kontoinhabenden Person erfordert.
Es ist wahrscheinlich, dass der bedienenden Person des Phishing-Kits diese passkey-bezogenen Seiten als Ablenkungsmanöver zur Verfügung stehen. Es dient als Ablenkung, um die betroffene Person mit einer Aufgabe zu beschäftigen, während die angreifende Seite ihren eigenen Passkey im legitimen Microsoft-Konto der Person registriert.
Die Seite /done bestätigt, dass eine Passkey-Registrierung erfolgreich war. Eine ahnungslose Person, die nicht vollständig versteht, wie ein Passkey registriert wird, glaubt möglicherweise tatsächlich, einen solchen bei Microsoft eingerichtet zu haben – nur weil sie diese ansonsten bedeutungslosen Schritte ausgeführt hat.
Abbildung 7. Die Kampagnen-Bestätigungsseite von O-UNC-066, unter Verwendung von aus dem Phishing-Kit extrahiertem Code.
Die bedienende Person kann entscheiden, wann sie die Zielperson auf die Seite /done weiterleitet. Zumindest hilft es der Phishing-Operation dabei, den ursprünglichen Vorwand aufrechtzuerhalten. Jedes Mal, wenn eine betroffene Person einen Passkey bei Microsoft registriert, erhält die kontoinhabende Partei des kompromittierten Kontos eine legitime E-Mail von Microsoft, die darüber informiert, dass ein neuer Passkey für das Konto eingerichtet wurde. Während eines Angriffs wurde der Passkey tatsächlich von der angreifenden Seite direkt bei Microsoft registriert, und die angreifende Seite ist in der Lage, dem Passkey einen Namen zu geben, den die Zielperson als harmlos einstufen würde (vielleicht sogar in Anlehnung an die von der Zielperson ausgewählte Seed-Phrase). Der Prozess zur Einrichtung des Passkeys, den die Zielperson auf der Phishing-Seite durchlaufen hat, dient im Gegensatz dazu wahrscheinlich nur dazu, diese in dem Glauben zu wiegen, die von der angreifenden Seite durchgeführte Registrierung sei ihre eigene gewesen.
Infrastruktur
Es wurde beobachtet, dass die angreifende Seite Subdomains für die jeweilige Zielorganisation unter den folgenden Domains erstellte:
- assignpasskey[.]com (am Sonntag, den 14. Juni 2026, Internet Domain Service BS Corp., DDoS-Guard)
- deploypasskey[.]com (21. April 2026, Tucows, DDoS-Guard)
- passkeydeploy[.]com (23. April 2026, Internet Domain Service BS Corp, DDoS-Guard)
- passkeyadd[.]com (2026-05-08, Tucows, DDoS-Guard)
- setpasskey[.]com (23. Mai 2026, IQWeb FZ-LLC)
Eine Kampagne, die auf "exampleentity" abzielt, könnte also in etwa so aussehen:
exampleentity[.]setpasskey[.]com
Die von Okta Threat Intelligence beobachtete Phishing-Infrastruktur wurde auf DDoS-Guard (AS57724, Russland) und IQWeb FZ-LLC (AS59692, USA) gehostet.
Auswirkung
Seit April 2026 betreibt eine mit O-UNC-066 in Verbindung gebrachte angreifende Seite eine Datenleck-Website namens Pink (von Palo Alto Networks Unit 42 als „CL-CRI-1147“ bezeichnet).
Abbildung 7. Die Pink-DLS-Website (Datenerpressung)
Empfehlungen
Obwohl bisher nicht beobachtet wurde, dass sich dieses Cluster von Bedrohungsaktivitäten als Okta ausgibt, haben ähnliche Kampagnen sprachbasiertes Social Engineering und betreibergesteuerte Phishing-Kits kombiniert:
Öffentlicher Blog-Beitrag (öffentlich verfügbar)
Flash Advisory (nur für Okta-Kund:innen)
Bedrohungshinweis (nur für Okta-Kund:innen)
Die folgenden Empfehlungen gelten speziell für den Schutz von Okta-Kund:innen.
ATT&CK
|
Taktik
|
Kontrollempfehlung
|
T1566
|
Phishing
|
Registrieren Sie Benutzer:innen für starke Authentifikatoren wie Okta FastPass, Passkeys oder Smartcards und erzwingen Sie Phishing-Resistenz in der Richtlinie.
Etablieren, kommunizieren und vermitteln Sie Verfahren zur Identitätsprüfung von Helpdesk-Mitarbeiter:innen bei der Kontaktaufnahme mit Personen.
|
T1078
|
Phishing
|
Lehnen Sie Anfragen von Standorten ab, an denen Ihr Unternehmen keine Dienste anbietet. Okta Netzwerkzonen ermöglichen es Administrator:innen, Richtlinien festzulegen, die den Zugriff auf durch Okta geschützte Anwendungen anhand von Geolokalisierung (Land), ASN, IP oder anderen Kriterien verweigern.
|
T1078
|
Gültige Accounts
|
Okta-Authentifizierungsrichtlinien können verwendet werden, um den Zugriff auf Benutzerkonten basierend auf einer Reihe von vom Kunden konfigurierbaren Voraussetzungen einzuschränken. Wir empfehlen Administratoren, den Zugriff auf sensible Anwendungen auf Geräte zu beschränken, die von Endpoint-Management-Tools verwaltet werden und durch Endpoint-Sicherheitstools geschützt sind. |
T1078
|
Gültige Accounts
|
Informieren Sie die Betroffenen über Benachrichtigungen für Endnutzende über jedes Lebenszyklus-Ereignis eines Authentifikators (Faktors).
|
T1098
|
Accountmanipulation (Geräteregistrierung)
|
Wenden Sie Okta Account Management-Richtlinien an, die die Möglichkeit zum Hinzufügen oder Ändern von Authentifikatoren basierend auf dem Netzwerkkontext, dem Status der Geräteverwaltung und den registrierten Authentifikatoren einschränken. Spezifische Hinweise finden Sie im folgenden Blogbeitrag: |
