Schwächen im Passkey-Umfeld : Malware könnte via Chrome und Google Password Manager Passkey-Anmeldungen angreifen

Drei von Palo Alto Networks Unit 42 beschriebene Techniken – Pass-ta-key, Silver Pass-ta-key und Golden Pass-ta-key – richten sich nicht gegen die kryptografischen Grundlagen von Passkeys, sondern missbrauchen lokale Schlüssel, Wiederanmeldeprozesse und unzureichende Prüfungen durch Onlinedienste. Voraussetzung ist stets, dass Malware bereits mit den Rechten eines normalen Nutzers auf einem Windows-System läuft. Untersucht wurde Chrome mit Google Password Manager auf Geräten mit “Trusted Platform Module” (TPM). Hinweise auf eine aktive Ausnutzung, zugehörige CVE-Kennungen, konkret betroffene Chrome-Versionen oder einen vollständigen Behebungsstatus gibt es bislang nicht.

Lokale Daten verraten Konten und Zugangsschlüssel

Chrome speichert synchronisierte Anmeldedaten im Benutzerprofil unter %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Ein unprivilegierter Prozess kann laut Unit 42 daraus Metadaten zu Diensten, Benutzernamen und Passkey-Kennungen auslesen – auch verschlüsseltes geheimes Schlüsselmaterial (private keys) sei dort auffindbar. Die Daten allein reichen zwar noch nicht zur Anmeldung, liefern der Malware jedoch eine genaue Übersicht über lohnende Konten. Diese Angriffe sind deshalb als sogenannte Post-Compromise-Techniken einzuordnen: Sie erklären nicht, wie ein Rechner infiziert wird, sondern welche Möglichkeiten Angreifer erhalten, nachdem das Endgerät bereits unter Kontrolle gebracht wurde.

Pass-ta-key: Anmeldung ohne Nutzerprüfung

Beim ersten geschilderten Angriff extrahiert die Malware den von Chrome gespeicherten Geräteidentitätsschlüssel, der als verpacktes, nur vom TPM nutzbares Datenobjekt vorliegt. Über die Windows-Schnittstelle “Cryptography API: Next Generation” (CNG) kann die Schadsoftware das gleiche TPM dazu bringen, eine manipulierte Anfrage zu signieren. Chrome lädt den Schlüssel laut aktuellem Chromium-Quellcode ohne sichtbare Rückfrage. Der Cloud-Authentifikator liefert anschließend eine gültige WebAuthn-Anmeldebestätigung. Allerdings bleibt das Bit “User Verified” (UV), das eine tatsächliche Nutzerprüfung kennzeichnet, ungesetzt.

Genau hier liegt die Verantwortung des jeweiligen Onlinedienstes: Fordert eine Website über userVerification: required eine Nutzerprüfung, muss sie nach der aktuellen Web-Authentication-Spezifikation die Anmeldung ablehnen, wenn das UV-Bit fehlt. GitHub setzte diese Kontrolle laut Bericht korrekt um; eBay akzeptierte die manipulierte Bestätigung zunächst, schloss die Lücke jedoch nach der Offenlegung.

Von den drei beschriebenen Angriffspfaden ist dies somit der einzige, dessen Abwehr unmittelbar in der Hand des jeweiligen Onlinedienstes liegt: Eine Website kann die Anmeldung unabhängig vom Verhalten des Cloud-Dienstes zurückweisen, sofern sie das UV-Bit konsequent prüft.

Silver Pass-ta-key: Fremden Prüfschlüssel einschleusen

Silver Pass-ta-key nutzt die erneute Registrierung eines Geräts: Die Malware löscht oder verändert den lokalen Zustand so, dass Chrome eine Neuanmeldung beim Cloud-Dienst auslöst. Da der Browser den Schlüssel zur Nutzerprüfung allerdings nicht sofort erzeugt, entsteht ein Zeitfenster, in dem ein Angreifer einen eigenen Schlüssel registrieren kann. Unit 42 zufolge prüfte der Dienst nicht, ob der neue Schlüssel tatsächlich aus geschützter Hardware stammt. Mit dem eingeschleusten Schlüssel erzeugte Anmeldebestätigungen tragen ein gesetztes UV-Bit und wirken damit wie ordnungsgemäß bestätigte Logins. Der Zugriff könnte anschließend auch von einem fremden System erfolgen.

Der öffentliche Chromium-Code bestätigt den verzögerten Zustand deferred_uv_key_creation. Ob der produktive Google-Dienst die beschriebene Schlüsselübernahme weiterhin zulässt, geht aus den verfügbaren Angaben jedoch nicht hervor. Unit 42 empfiehlt, neu registrierte Schlüssel durch Hardware-Attestierung zu überprüfen.

Golden Pass-ta-key: Angriff auf das Hauptgeheimnis

Die weitreichendste Variante der bekanntgewordenen Schwachstellen zielt auf das 32 Byte lange “Security Domain Secret” (SDS), das die synchronisierten geheimen Passkey-Schlüssel im Google Password Manager schützt. Bei einer erneuten Geräteanmeldung gelangt das SDS vorübergehend im Klartext in den Speicher des Chrome-Prozesses. Malware könnte es dort auslesen und anschließend die synchronisierten Passkeys entschlüsseln. Nach Darstellung von Unit 42 ermöglicht das einen wiederverwendbaren Zugriff aus einer eigenen Angriffsumgebung.

Der Chromium-Quellcode bestätigt, dass das SDS in Datenstrukturen des Client-Prozesses verarbeitet wird; ob eine zuverlässige Extraktion bei aktuellen stabilen Chrome-Versionen möglich ist und wie lange ein gestohlenes SDS gültig bleibt, ist öffentlich nicht abschließend geklärt. Google entfernte laut Bericht eine frühere Ausgabe des Geheimnisses aus den FIDO-Protokollen. Das Grundproblem, dass das SDS den Chrome-Speicher im Klartext durchläuft, werde dadurch jedoch nicht beseitigt.

Status der Absicherung bleibt unklar

Am 4. August 2026 ließ sich in der National Vulnerability Database (NVD) noch keine CVE finden, die den drei Angriffsnamen zugeordnet ist. Auch öffentliche Hinweise von Google oder eBay dokumentieren bislang nicht vollständig, welche Maßnahmen umgesetzt wurden. Unklar bleibt zudem, ob eine Änderung der Google-Password-Manager-PIN oder das Löschen sämtlicher gespeicherter Daten ein bereits entwendetes SDS ungültig macht. Googles Hilfeseiten beschreiben zwar beide Funktionen, nennen aber keine gezielte Rotation oder Sperrung des Hauptgeheimnisses.

Webdienste sollten zwingend eine Nutzerprüfung verlangen und das zurückgegebene UV-Bit kontrollieren, statt allein auf die ursprüngliche Anfrage zu vertrauen. Anbieter von Passkey-Infrastrukturen sollten darüber hinaus:

• neu registrierte Prüfschlüssel per Hardware-Attestierung validieren,
• Wiederanmeldung und Kontowiederherstellung stärker absichern,
• lokale Passkey-Daten vor unprivilegierten Prozessen schützen sowie
• Hauptschlüssel aus Protokollen und ungeschütztem Prozessspeicher fernhalten.

Passkeys bleiben kryptografisch robust und schützen wirksam vor klassischem Phishing. Die aktuelle Untersuchung zeigt jedoch klar, dass ihre Sicherheit nicht allein vom Verfahren abhängt: Wird das Endgerät kompromittiert oder prüfen Dienste die Authentifizierungsmerkmale nur oberflächlich, kann Malware die Schutzmechanismen rund um einen Passkey gezielt aushebeln.