Passkey-Phishing: Wie ShinyHunters und Helix mit falschen IT-Anrufen Microsoft 365 leerräumen

Passkey-Phishing klingt nach einem Widerspruch – Passkeys gelten schließlich als phishing-resistent. Genau darauf setzen Erpressergruppen wie ShinyHunters und Helix: Sie rufen Mitarbeiter als angeblicher IT-Helpdesk an, behaupten, ein Passkey oder die SSO-Konfiguration müsse dringend erneuert werden, und lotsen sie auf gefälschte Microsoft-Anmeldeseiten. Microsoft hat die Kampagne am 9. September 2026 detailliert analysiert. Der Passkey ist dabei nur der Köder – gestohlen werden Sitzungen, Tokens und am Ende ganze SharePoint-Bibliotheken.

Was passiert ist

Microsoft Threat Intelligence beobachtet die Aktivität seit Mai 2026 und ordnet den Erstzugang mehreren Gruppen zu, darunter Storm-3121 (verbunden mit ShinyHunters- und Falcon-Erpressung) und Storm-3032 (ehemalige BlackFile-Mitglieder, heute unter dem Namen Helix aktiv). Die Angreifer recherchieren ihre Ziele vorab über soziale und berufliche Netzwerke und melden sich dann per Anruf oder SMS – häufig auf der privaten Handynummer des Mitarbeiters.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

E-Mail-Adresse *

Vorname

Nachname

Der entscheidende Punkt: Ein echter Passkey wird nie eingerichtet. Das Szenario dient dazu, das Opfer entweder auf eine Adversary-in-the-Middle-Seite zu führen, die Zugangsdaten und Session-Token abgreift, oder es durch einen Device-Code-Flow zu lotsen. Dabei tippt das Opfer einen vom Angreifer gelieferten Code auf der echten Microsoft-Seite ein und autorisiert damit eine fremde Anwendung – ohne dass eine weitere MFA-Abfrage nötig wäre. Die Phishing-Domains folgen einem Muster: passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, oft mit dem Firmennamen als Subdomain.

Nach dem Einstieg läuft ein weitgehend automatisierter Ablauf: Die Angreifer registrieren eigene MFA-Methoden (neue Telefonnummer, Authenticator-App, Software-Token), um den Zugang zu behalten. Dann fragen sie über Microsoft Graph systematisch ab, was das Konto darf – Benutzer, Gruppen, Rollen, Anwendungen, SharePoint-Sites, Postfächer. Anschließend werden Dateien aus SharePoint Online und OneDrive sowie E-Mails über REST-APIs eingesammelt. Microsoft beobachtete dabei den User-Agent python-httpx und ein bewusst gedrosseltes Tempo: weniger als 1.000 Dateien oder Mails pro Stunde, verteilt über Stunden bis Tage, um nicht aufzufallen.

Warum Passkey-Phishing funktioniert

Die Kampagne nutzt eine Lücke, die nicht technisch ist. Viele Unternehmen rollen gerade Passkeys aus – die Aufforderung, „den Passkey zu aktualisieren”, wirkt deshalb plausibel. Und weil der Anruf auf dem Privathandy landet, das nicht in Defender for Endpoint eingebunden ist, gibt es aus der ersten Phase oft keinerlei Telemetrie. Microsoft schreibt selbst, dass die Erinnerung des Mitarbeiters an den Anruf oft der früheste und manchmal der einzige Hinweis auf den Ursprung ist. In einigen Fällen nutzten die Angreifer bereits übernommene Konten, um dieselbe Passkey-Aufforderung intern per Microsoft Teams zu verbreiten. Das Muster kennen wir bereits von der Helix-Vishing-Welle im Juli – neu ist die Passkey-Verkleidung und der Einblick in die Nacharbeit im Tenant.

Was das für dich bedeutet

Ich beschäftige mich seit über zwei Jahrzehnten mit Identity und Active Directory, und diese Kampagne bestätigt eine unbequeme Wahrheit: Die stärkste Authentifizierung nützt nichts, wenn daneben ein schwächerer Weg offenbleibt. Wer Passkeys ausrollt, aber Device-Code-Flow und Passwort-plus-SMS parallel erlaubt, hat die Tür nur zur Hälfte zugemacht. Angreifer gehen immer durch die offene Hälfte.

Zweitens zeigt der Bericht, wie wertvoll ein einzelnes Cloud-Konto geworden ist. Über Graph lässt sich innerhalb von Minuten der komplette Tenant kartieren, und über SSO hängen an derselben Identität oft Salesforce, Slack, Atlassian und mehr. Der klassische Perimeter existiert für diese Angreifer nicht – das Konto ist der Perimeter.

Drittens ist die Persistenz per zusätzlicher MFA-Methode ein Punkt, den viele Incident-Response-Checklisten übersehen: Passwort zurücksetzen reicht nicht. Solange die Authenticator-App des Angreifers registriert bleibt, ist er nach dem Reset sofort wieder drin.

Konkrete Handlungsempfehlung

• Device-Code-Flow und Authentication Transfer per Conditional Access blockieren, außer es gibt einen dokumentierten Bedarf (etwa für Geräte ohne Browser). Das ist eine einzige Richtlinie und schließt einen der beiden Hauptwege dieser Kampagne. Wo der Flow bleiben muss, zusätzlich ein konformes, verwaltetes Gerät verlangen.
• Phishing-resistente MFA erzwingen, nicht nur anbieten: FIDO2-Sicherheitsschlüssel, Passkeys oder Windows Hello for Business als Pflicht per Conditional Access – mindestens für Admins und Personen mit Zugriff auf sensible Daten. Schwächere Methoden für diese Gruppen abschalten. Welche Schlüssel sich bewährt haben, steht im Ratgeber zu FIDO2-Hardware-Keys. Wichtig: Ein echter FIDO2-Login lässt sich auf einer AiTM-Seite nicht abgreifen – gegen den Device-Code-Trick hilft er nicht – dort wirken nur Conditional-Access-Regeln, die den Flow sperren oder ein verwaltetes Gerät verlangen.
• Alarm auf neue Authentifizierungsmethoden: Jede Registrierung einer MFA-Methode kurz nach einer ungewöhnlichen Anmeldung (neues Land, unverwaltetes Gerät) ist ein Hochrisiko-Signal. Diese Abfolge sollte in Sentinel oder Defender XDR als eigene Regel laufen.
• Helpdesk-Regel kommunizieren: Die IT ruft nie unaufgefordert auf dem Privathandy an und verlangt nie, einen Code auf einer Microsoft-Seite einzugeben. Ein Satz, den jeder Mitarbeiter kennen sollte – und der bei Rückfrage über die bekannte interne Nummer bestätigt wird.
• Bei Verdacht vollständig zurücksetzen: Sessions und Tokens widerrufen, Passwort ändern, alle registrierten Authentifizierungsmethoden und Postfachregeln prüfen und fremde entfernen, dann Neu-Registrierung erzwingen. Erst die Kombination beendet den Zugriff.

Quellen

• Microsoft Security Blog: Passkey-themed social engineering leads to identity and cloud compromise (9. September 2026)
• BleepingComputer, 11. September 2026
• BleepingComputer: Google-Bericht zu UNC6671