Nicht alle Passkeys sind gleich

Michael Grafnetters Black-Hat-USA-2026-Forschung und das Pass-the-Passkey-Paper zeigen: Die Kryptografie von WebAuthn ist nicht gebrochen. Die Implementierungen schon. Entra-Passkeys widerstehen Phishing im Moment des Logins. Das ist nicht dasselbe wie phishing-sicher.

Zwei MFA 2.0-Kontrollen beantworten diese Familie. Die erste ist, wie die Login-Challenge gebunden und verworfen wird. Deshalb erreicht keine Technik aus Gruppe 1 MFA 2.0. Die zweite ist die Durchsetzung der Zertifikatsbindung, die einen Angreifer stoppt, der von der eigenen Maschine aus arbeitet. Das ist der RDP-Fall in Gruppe 3.

Die sechzehn hier bewerteten Techniken sind nicht gleichwertig, und sie als eine Liste zu behandeln macht die Forschung schwer umsetzbar. Manche sind Fehler des Identity Providers. Manche sind Fragen der Credential-Policy. Sechs brauchen den Code des Angreifers auf dem PC des Opfers, und kein Identity Provider kann das verhindern. Microsoft hat zwei der sechzehn gepatcht und den Rest als by-design eingestuft. Dieser Beitrag trennt sie in drei Gruppen, weil die Antwort auf „Sind wir exponiert?“ in jeder anders ausfällt.

Gruppe 1: Angriffe auf den Identity Provider

Diese sechs sind Aufgabe des Identity Providers. Das Ergebnis hängt davon ab, wie er eine WebAuthn-Challenge ausstellt, bindet und prüft. Entra war für alle sechs verwundbar. Microsoft hat zwei gepatcht: das Event-Log-Leck und das User-Verification-Flag. Die anderen vier sind Produktentscheidungen und keine Bugs. Entra-Challenges sind kurzlebige JWTs, daher weder an eine Sitzung gebunden noch nach Verwendung verworfen.

MFA 2.0 war nie exponiert, weil es beides tut. Jede Challenge ist an das Gerät und die Benutzersitzung gebunden, die sie gestartet hat, und wird im Moment der Verwendung verworfen.

Assertion Mining

Windows schrieb nutzbare WebAuthn-Assertions in das Event-Log. Unprivilegierte Konten konnten sie lesen, in manchen Gruppenmitgliedschaftsfällen auch über das Netzwerk. Microsoft hat das am 14. Juli 2026 als CVE-2026-34348 geschlossen. Signaturen im Log werden jetzt gekürzt. Selbst ohne den Patch kann eine geminte Assertion keinen MFA 2.0-Login abschließen, weil die Challenge an die Sitzung gebunden ist, die sie angefordert hat, und der Angreifer nicht in dieser Sitzung ist. Auf ungepatchten Maschinen kann das Log weiterhin eine Assertion für jede Relying Party enthalten, einschließlich MFA 2.0. Der Unterschied ist, dass sie gegen MFA 2.0 nicht verwendbar ist.

Replay

Entra-Challenges bleiben kurzlebige JWTs. Sie sind nicht an Gerät und Benutzersitzung gebunden und werden bei der ersten Verwendung nicht verworfen. Seit Mai 2026 verfolgt Entra Signaturzähler für einige Hardware-Authenticatoren, aber Windows Hello meldet weiterhin einen Signaturzähler von 0, sodass eine erbeutete Hello-Assertion erneut vorgelegt werden kann. Microsoft behandelt das als Design, nicht als CVE. SpecterOps betrachtet die vollständige Windows-zu-Entra-Kette, die ursprünglich demonstriert wurde, nach dem Juli-Log-Patch inzwischen als gebrochen und hat Entras JWT-Verhalten seit Juni nicht erneut getestet. Die Lücke auf Entra-Seite ist unverändert. MFA 2.0 bindet die Challenge an Gerät und Benutzersitzung, prüft sie und verwirft sie im Moment der Verwendung. Eine zweite Einreichung hat nichts, womit sie übereinstimmen könnte.

Circuit Breaker

Malware pausiert den Browser und stiehlt die Assertion mitten in der Ceremony. Microsoft wird diesen Abgriff nicht als Produktbug behandeln. Die eigentliche Lücke war, dass Entra die gestohlene Assertion in einer anderen Sitzung akzeptierte. Eine Assertion kann nur die Sitzung abschließen, die ihre Challenge hält. Ein anderer Host scheitert, selbst wenn die Signatur gültig ist.

Detour Capture

Das Paper behandelt Detour als eine Technik mit drei Modi. Capture und Replay gehören hierher. Inject gehört in Gruppe 3. Capture hookt webauthn.dll und holt die Assertion vom System. Microsoft wird User-Mode-API-Hooking nicht patchen. Off-Box-Replay funktionierte nur, weil Entra die gestohlene Assertion akzeptierte. Ein Hook kann weiterhin eine Signatur sehen. Der Operator hat keine Sitzung, in die er sie replayen könnte.

Detour Replay

Das nutzt denselben Hook. Der Dual-Login-Trick brauchte, dass Entra die Challenge nach der ersten Verwendung am Leben ließ. Microsoft ließ das als Design stehen. MFA 2.0 verwirft die Challenge im Moment der Verwendung, sodass ein Replay nichts hat, woran es binden könnte.

User Verification Bypass

Entra ignorierte historisch User-Verification-Flags des Authenticators. Das war ein Relying-Party-Bug und ist inzwischen gepatcht. Es war kein Windows-Hello-CVE. Der MFA 2.0-Login hat User Verification stets verlangt und validiert das Flag bei jeder Assertion. Das Entfernen des Flags schwächt den Login nicht. Es lässt ihn scheitern.

Gruppe 2: Passkey-Fehlverwendung

Diese drei geschehen diesseits oder jenseits des Logins, nicht währenddessen. Zwei betreffen, wie ein Angreifer einen Passkey erhält, der weiter funktioniert. Eine betrifft, wie eine erbeutete Entra-Passkey-Assertion in Microsoft-Tokens umgewandelt wird. Microsoft stuft alle drei als Produktfeatures ein. Keine hängt davon ab, dass der Identity Provider eine Assertion korrekt prüft; deshalb sehen die Antworten hier anders aus als in Gruppe 1. Keine erreicht MFA 2.0, und zwar aus drei getrennten Gründen.

Software Authenticators

Synchronisierte und exportierbare Passkeys sind eine bewusste FIDO- und Microsoft-Richtung. Device-bound versus syncable ist eine Tenant-Policy-Entscheidung. Microsoft wird den Vault-Export in einem Security-Update nicht verbieten. Das MFA 2.0-Enrolment verlangt einen Platform-Authenticator, sodass der Schlüssel unter Windows in Windows Hello erzeugt und vom TPM gehalten wird. Es gibt keine exportierbare Kopie, die ein Passwortmanager entnehmen könnte.

Shadow Passkey

Administrative FIDO-Registrierung über Microsoft Graph ist ein Entra-Feature, damit IT Schlüssel vorab enrolen kann. Microsoft wird es nicht entfernen. Graph kann kein MFA 2.0-Credential schreiben. Es gibt auch keine äquivalente API: kein administrativer Endpunkt registriert einen Passkey im Namen einer anderen Person, und das Enrolment findet auf dem Gerät statt, das den Schlüssel hält. Das ist die Zero-Knowledge-Enrolment-Regel, keine Admin-Bequemlichkeit.

Passkey to Token

Die Technik besteht darin, eine erbeutete Entra-Passkey-Assertion bei Entra gegen ESTS-Cookies einzulösen und diese dann über einen bekannten Public Client gegen Access- und Refresh-Tokens zu tauschen. Das ist kein Bug der Passkey-Ceremony, und Microsoft wird die Token-Ausstellung für einen akzeptierten Login nicht stoppen. Der TokenTactics-artige Tausch ist eine Entra-native Abkürzung. Sobald die Domäne an MFA 2.0 föderiert ist oder MFA 2.0 der External-MFA-Provider ist, hat diese Abkürzung nichts, wogegen sie laufen könnte: Eine MFA 2.0-Assertion ist für den Relying-Party-Identifier, den Origin und die Challenge von MFA 2.0 signiert, sodass Microsoft sie nicht honoriert. Gewöhnliche SAML- und OIDC-Tokens nach einem erfolgreichen Login sind Föderation wie vorgesehen, und Entra stellt weiterhin seine eigene Sitzung aus, sobald es dieses föderierte Ergebnis akzeptiert, wie nach jedem Sign-in, den es akzeptiert.

Gruppe 3: Malware auf dem System und eine RDP-Ausnahme

Sechs davon erfordern den bösartigen Code des Angreifers auf dem Opfer-PC. Ab diesem Punkt gehört die Maschine ihnen. Das Session-Cookie kann entnommen werden. Kein Passkey, kein Zertifikat, keine MFA ist involviert. Entra, Okta, Ping und MFA 2.0 sind hier gleich. Einem Identity Provider, der etwas anderes behauptet, sollte man auch in allem anderen nicht glauben. Die Infektion ist der Befund. Patch-Management, Application Control und EDR sitzen vorgelagert. Login-Design ersetzt das nicht.

Die siebte ist anders. RDP Passkey Phishing läuft vom eigenen Host des Angreifers. Die Durchsetzung der Zertifikatsbindung ist die Kontrolle, die diesen Fall beantwortet.

UI Overlay

Windows erlaubt bereits nur eine Ceremony gleichzeitig. Zu warten, bis sie endet, und dann einen gefälschten Prompt zu zeigen, bleibt erlaubt. Fake-Dialoge sitzen im Trust-Modell der OS-Oberfläche. Microsoft ließ das als Design stehen. Es loggt niemanden von allein ein. UI Overlay, HWND Spoofing und Metadata Spoofing verkleiden Assertion Phishing, Prompt Flooding und Detour Inject.

HWND Spoofing

Windows validiert nicht, dass der Aufrufer das Parent-Window-Handle besitzt, das er liefert. MSRC bewertete den Fall VULN-185216 im Juni 2026 als Low / Defence in Depth und schloss ihn. Microsoft wird ihn nicht beheben. Es ist ein Kostüm, kein Login.

Metadata Spoofing

Der Text „Requested by…“ stammt aus der EXE-Versionsressource. Microsoft behandelte das Spoofen dieser Zeichenkette nicht als Schwachstelle. Ältere Windows-11-Builds nutzten stattdessen die digitale Signatur; diese Prüfung wurde absichtlich entfernt. Es ist ein Kostüm, kein Login.

Assertion Phishing

Jede Windows-Anwendung darf WebAuthNAuthenticatorGetAssertion aufrufen. Microsoft wird Drittanbieter-Code nicht daran hindern, einen Passkey anzufordern. Das ist dieselbe Klasse wie ein Push-Prompt: Das OS fragt, wenn es dazu aufgefordert wird. Es braucht Malware auf dem System.

Prompt Flooding

Windows wird wiederholte WebAuthn-Prompts einer Anwendung nicht rate-limitieren. Microsoft lehnte es ab, Prompt-Spam als Produktbug zu behandeln. Es ist dieselbe Klasse wie MFA-Fatigue, nur dass der Aufrufer bereits lokal ist.

Detour Inject

Das ist der dritte Detour-Modus. Ein In-Process-Hook von webauthn.dll tauscht die Challenge innerhalb einer laufenden Sitzung auf der Maschine des Benutzers aus. Capture und Replay sind Gruppe 1. Inject ist on-box. Microsoft wird User-Mode-Hooking nicht patchen.

RDP Passkey Phishing

WebAuthn-Pass-through ist in [MS-RDPEWA] dokumentiert und standardmäßig aktiv. Der Benutzer wird in Remote Desktop auf einem Host gelockt, den der Angreifer kontrolliert. Windows leitet den Passkey-Prompt an die lokale Maschine weiter. Microsoft wird Pass-through in einem Security-Update nicht deaktivieren. Administratoren können es im RDP-Client abschalten. Das ist operativ, kein CVE.

Das ist der einzige Angriff in Gruppe 3, der von der eigenen Maschine des Angreifers und nicht von der des Opfers gestartet wird. Mit Durchsetzung der Zertifikatsbindung präsentiert dieser Host kein passendes Client-Zertifikat und erhält daher nie eine Challenge. Das Deaktivieren von RDP-WebAuthn-Pass-through schließt ihn zusätzlich am Endpunkt.

Die Grenze ist einfach. Malware auf dem PC des Opfers schlägt jeden Identity Provider. Von der eigenen Maschine aus erreicht ein Angreifer den Login nie so weit, dass er eine Challenge erhält.

Wenn Sie den kontrolleenseitigen Walkthrough zu phishing-sicherer, gerätegebundener Authentifizierung möchten, beginnen Sie bei Prävention, nicht Detection. Für ein Gespräch mit IDEE nutzen Sie Demo buchen.

Häufige Fragen

Sind alle sechzehn Pass-the-Passkey-Techniken derselbe Bug?

Nein. Sechs greifen an, wie der Identity Provider eine Challenge bindet und verwirft. Drei sind Enrolment-Policy und das Einlösen einer erbeuteten Entra-Assertion gegen Tokens. Sechs brauchen Malware auf dem Opfer-PC. RDP Passkey Phishing ist der eine Pfad in Gruppe 3, der von der Maschine des Angreifers aus läuft, und die Durchsetzung der Zertifikatsbindung verhindert, dass dieser Host eine Challenge erhält.

Hat Microsoft Pass-the-Passkey gepatcht?

Microsoft hat zwei Issues aus Gruppe 1 gepatcht: das Event-Log-Assertion-Leck als CVE-2026-34348 am 14. Juli 2026 und das User-Verification-Flag auf der Relying Party. Replay, Circuit Breaker, Detour Capture und Detour Replay bleiben bei Entra by-design. Nichts in Gruppe 2 oder Gruppe 3 wurde als Produktbug geschlossen.

Hätte phishing-sicheres MFA 2.0 die Entra-Replay-Kette gestoppt?

Für Gruppe 1 ja. MFA 2.0 bindet die Challenge an Gerät und Benutzersitzung, akzeptiert sie einmal und verwirft sie danach. Eine Signatur aus einem Event-Log oder einem webauthn.dll-Hook hat keinen Ort, an dem sie replayt werden könnte. Das ist phishing-sichere Session-Bindung, nicht bloß phishing-resistenter Login. Es stoppt keinen Cookie-Diebstahl, nachdem Malware bereits auf dem enrolten PC läuft.

Warum sitzt RDP bei Malware, wenn die Durchsetzung der Zertifikatsbindung es stoppt?

RDP Passkey Phishing steht in Gruppe 3, weil SpecterOps es mit der Windows-WebAuthn-Missbrauchs-Familie gelistet hat. Es ist keine Infektion. Der Angreifer steht auf dem eigenen Host und lässt Windows den Prompt weiterleiten. Mit Durchsetzung der Zertifikatsbindung hat dieser Host kein Client-Zertifikat, sodass der Login nicht initiiert werden kann. Die sechs Infektionstechniken bleiben Endpoint-Probleme.

Wo ist die Primärforschung?

Die Übersicht liegt unter specterops.io/passkeys. Tools sind auf GitHub unter SpecterOps/pass-the-passkey. Grafnetter hat die Familie am 5. August 2026 auf der Black Hat USA vorgestellt.