Unit 42 zufolge kann Malware nach einer lokalen Erkundung aus Chomes synchronisierten Daten unter %LocalAppData%\Google\Chrome\User Data<Profile>\Sync Data\LevelDB Metadaten auslesen. Dazu gehören nach Angaben der Forscher die zu Passkeys gehörenden relying parties und Benutzernamen sowie Kennungswerte und verschlüsseltes Material privater Schlüssel. Die Angriffe seien damit klar als Techniken nach einer bereits erfolgten Kompromittierung einzuordnen, nicht als Einbruchsweg auf das System selbst.
Die erste Methode, Pass-ta-key, nutzt laut Unit 42 Chomes gekapselten Geräte-Identitätsschlüssel und veranlasst dasselbe TPM über Aufrufe der Windows Cryptography API: Next Generation zur Signatur einer vom Angreifer kontrollierten Anfrage. Im aktuellen Chromium-Quelltext ist nach Angaben des Berichts nachvollziehbar, warum sich dieses Blob wiederverwenden lässt: Chrome erstellt den TPM-Schlüssel ohne Schlüsselnamen, exportiert ihn als undurchsichtiges Blob und lädt ihn später mit einem Kennzeichen erneut, das jede Abfrage unterdrückt. Ein Kommentar im Code und ein Verweis auf Chromium-Issue 398125799 deuten darauf hin, dass diese Schlüssel stattdessen beschriftet werden sollten.
Der Google Cloud Authenticator liefere in diesem Fall eine gültige Authentisierungsbestätigung. Der Unterschied zu einer Bestätigung nach echter Benutzerprüfung sei ein einziges Bit: Das Kennzeichen „Benutzer verifiziert“ bleibe ungesetzt. Die aktuelle Web-Authentication-Spezifikation verlangt, dass eine relying party den Vorgang ablehnt, wenn sie userVerification auf required setzt und dieses Bit fehlt. Laut den Forschern setzte GitHub diese Prüfung korrekt um, während eBay die Test-Bestätigung zunächst akzeptierte und die Validierungslücke erst nach der Offenlegung schloss.
Silver Pass-ta-key zielt auf die nächste Ebene. Dabei erzwingt Malware laut Unit 42 eine erneute Registrierung des Geräts. Weil Chrome den Schlüssel für die Benutzerverifizierung nicht sofort erzeugt, entstehe ein Zeitfenster, in dem ein Angreifer einen eigenen Schlüssel registrieren könne. Der Dienst prüfe nach Angaben von Unit 42 nicht, ob ein neu registrierter Schlüssel aus sicherer Hardware stammt. Mit diesem Schlüssel signierte Bestätigungen trügen dann das Kennzeichen „Benutzer verifiziert“, was spätere Anmeldungen ohne das Gerät des Opfers ermögliche. Der aktuelle Chromium-Quelltext bestätige unabhängig, dass neu registrierte Geräte einen Zustand mit aufgeschobener Erstellung des Schlüssels für die Benutzerverifizierung behalten können. Ob der beschriebene serverseitige Austausch von Schlüsseln auch in der neuesten stabilen Chrome-Version funktioniert, belegt der öffentliche Code allein aber nicht.
Golden Pass-ta-key richtet sich gegen das 32 Byte große Security Domain Secret, kurz SDS. Unit 42 zufolge kann Malware eine erneute Registrierung auslösen, das Geheimnis aus dem Speicher des Chrome-Prozesses auslesen, solange es dort kurzzeitig im Klartext vorliegt, und damit synchronisierte private Passkey-Schlüssel wiederherstellen. Der aktuelle Chromium-Quelltext stützt den zugrunde liegenden Punkt, dass diese Security-Domain-Geheimnisse in Datenstrukturen des Client-Prozesses erzeugt oder empfangen werden und damit in Chomes Speicher gelangen. Ob eine zuverlässige Extraktion, die Übernahme von Konten und eine dauerhafte Nutzbarkeit über spätere Geheimnis-Epochen hinweg möglich sind, bleibt laut Text jedoch auf die Aussagen von Unit 42 gestützt oder offen.
Der Bericht hält fest, dass Google eine frühere SDS-Offenlegung aus Chomes FIDO-Protokollen entfernt habe und dass eBay inzwischen das Kennzeichen „Benutzer verifiziert“ prüft. Ob damit alle drei Angriffswege geschlossen sind, bleibt offen. Laut dem Text fanden Suchen in öffentlich zugänglichen Chrome-Materialien von Google sowie auf Support- und Presseseiten von eBay bis dahin keinen Hinweis, der diese Änderungen dokumentiert. Ebenso fehle eine Möglichkeit für Nutzer, selbst zu prüfen, ob ein SDS offengelegt wurde. Googles öffentliche Support-Dokumentation beschreibt zwar das Ändern der PIN für Google Password Manager oder das Löschen aller Password-Manager-Daten, nennt aber keine SDS-spezifische Rotation oder Widerrufsmöglichkeit.