LONDON (IT BOLTWISE) – Unit 42 beschreibt mehrere post-compromise Angriffe, die in Chrome auf Windows passkey-geschützte Konten über den Cloud-Authenticator von Google Password Manager kompromittieren können. Die Techniken zielen nicht auf die Kryptografie selbst, sondern auf die Architektur rund um Geräte- und Benutzerverifikation. Je nach Pfad reicht es, eine gültige Authentifizierungs-Aussage ohne echtes „User Verified“ zu erzeugen, einen Ersatz-Schlüssel mit UV-Flag zu platzieren oder sogar einen 32-Byte Security Domain Secret aus Chrome-Prozessspeicher auszulesen. Eine Ausnutzung im Wilden und klare Mitigationsangaben nennt der Bericht nicht.
Passkeys sollen das mühsame Passwort-Ökosystem ersetzen: Der Nutzer authentifiziert sich, weil ein Gerät einen kryptografischen Nachweis erzeugt. Der Knackpunkt in der aktuellen Diskussion ist jedoch die Annahme, dass der Nachweis immer an einem „sauberen“ Ende beginnt. Unit 42 beschreibt für Chrome unter Windows mehrere Techniken, die erst dann funktionieren, wenn bereits Malware auf dem Zielsystem als unprivilegierter Prozess läuft. Genau hier liegt die Sicherheitsphilosophie der Studie: Es geht um Post-Compromise-Wege, also darum, was ein Angreifer noch ausrichten kann, nachdem ein Rechner ohnehin kompromittiert ist. Laut Bericht werden dabei drei Angriffspfade auf den Google-Cloud-Authenticator im Google Password Manager beschrieben, die sich gegenseitig in ihrer Zielrichtung über Geräte-Keys, Re-Enrollment-Logik und einen 32-Byte Security Domain Secret (SDS) unterscheiden.
Technisch gesehen brechen die beschriebenen Angriffe nicht die Kryptografie der Passkeys. Stattdessen greifen sie an Stellen an, die sich viele Nutzer eher selten bewusst machen: Wie ein Browser Geräte-Identitäten speichert, wie er bei einem Re-Enrollment mit einem „verlorenen Zustand“ umgeht, und vor allem wie stark eine Website die vom Authentifizierungssystem gelieferten Verifikationsinformationen prüft. Der Bericht betont, dass die Angriffe gültige Authentifizierungs-Assertions erhalten können, ein vom Angreifer kontrolliertes User-Verification-Keying installieren oder den 32-Byte SDS auslesen, der die privaten Schlüssel für synchronisierte Passkeys entschlüsselt. Damit verschiebt sich die Angriffslogik weg von „Kann ich die Signatur knacken?“ hin zu „Kann ich die Signatur als korrekt erscheinen lassen, ohne dass ein echter Nutzer verifiziert wurde?“
Der erste Pfad trägt den Namen Pass-ta-key und richtet sich auf einen „wrapped“ Device Identity Key, der von Chrome gebündelt und an das Trusted Platform Module (TPM) gekoppelt wird. Laut den Forschern kann die Malware eine signierbare Anfrage durch Windows Cryptography API: Next Generation (CNG) triggern, ohne dass ein Fingerprint, eine PIN oder irgendein verifizierender UI-Trigger auf dem Opferbildschirm sichtbar wird. Das ist die Stelle, an der die Studie wiederholt klarstellt: Der Schlüssel wird im TPM sinnvoll zum Signieren genutzt, aber die Schutzlogik entscheidet am Ende über einen UV-Flag (User Verified). Im Bericht wird als entscheidender Unterschied beschrieben, dass ein einzelnes Bit im Ergebnis gesetzt oder nicht gesetzt wird: Wenn das Flag fehlt, müsse eine relying party bei Einstellung „userVerification = required“ die Authentifizierung ablehnen. Die Forscher vergleichen hier konkrete Praxis: GitHub soll die UV-Prüfung korrekt umgesetzt haben, während eBay den Test-Assertion zunächst akzeptierte und erst nach einer Offenlegung eine Validationslücke geschlossen habe.
Der zweite Pfad, Silver Pass-ta-key, setzt direkt an der Re-Enrollment-Mechanik an. Chrome erstellt dem Bericht zufolge sein User-Verification-Keying nicht sofort; in genau diesem Zeitfenster kann ein Angreifer einen eigenen Schlüssel registrieren lassen, sodass Assertions später als „user verified“ erscheinen, obwohl kein gesichertes Hardware-Ticket beteiligt war. Unit 42 schreibt, dass der Dienst nicht prüfe, ob ein neu registrierter Key aus „secure hardware“ stammt. Auf Ebene des Chromium-Quellcodes wird parallel bestätigt, dass neu eingetragene Geräte einen Zustand wie „deferred_uv_key_creation“ behalten können. Gleichzeitig bleibt ein Teil der Kette laut Bericht offen: Das Material belegt nicht, ob die produktive Service-Seite die beschriebene Server-Substitution gegen die neueste stabile Chrome-Version bereits zuverlässig abwehrt. Als Gegenmaßnahme empfehlen die Forscher insbesondere eine Hardware-Attestation als Voraussetzung für die Akzeptanz ersetzter Schlüssel.
Am weitesten geht Golden Pass-ta-key, weil er den SDS selbst in den Mittelpunkt stellt. Hier beschreibt Unit 42, dass Malware Re-Enrollment triggern, den Secret kurzfristig aus Chrome-Prozessspeicher in Klartext auslesen und anschließend nutzen kann, um synchronisierte Passkey-Private-Keys wiederherzustellen. Der Chromium-Code soll diese Grundlage stützen: Chrome erzeugt oder erhält 32-Byte Security-Domain-Secrets in Client-Datenstrukturen, wodurch der Secret grundsätzlich in den Speicher des Browsers „gelangt“. Unklar bleibt aber, wie zuverlässig ein Angreifer den Secret extrahieren kann, wie gut sich ein daraus resultierender Account-Takeover in der Praxis durchführen lässt und ob sich Zugänge über spätere „secret epochs“ hinweg stabil halten. Zusätzlich nennt der Bericht, dass Google eine frühere SDS-Exposition aus Chrome-FIDO-Logs entfernt habe und eBay inzwischen den UV-Flag validiere. Diese Änderungen schließen den von den Forschern beschriebenen Pfad laut ihrer Darstellung nicht vollständig, weil der Secret weiterhin im Clientprozess ankommt und dort im Speicher vorhanden bleibt; außerdem liefert der Text keine eindeutige Antwort darauf, ob Nutzer durch Ändern des Google Password Manager PINs oder durch Löschen der Password-Manager-Daten einen bereits erbeuteten SDS invalidieren können.
Für die praktische Bewertung ist vor allem wichtig, dass der Bericht ausdrücklich keine Ausnutzung „in the wild“ beschreibt, keine CVE-IDs liefert und weder betroffene Chrome-Versionen noch einen vollständigen Status der Remediation nennt. Eine Suche in der National Vulnerability Database am 3. August 2026 habe dem Bericht zufolge keinen Treffer geliefert, der zu den drei benannten Techniken passt. Die Forschung sei außerdem auf Google Password Manager in Chrome auf Windows mit TPM beschränkt und beginne überall mit lokalem Reconnaissance- und Endpoint-Zugriff durch bereits laufende Malware. Als weiteres Detail führt der Text aus, dass Chrome synchronisierte Credential-Records in einem LevelDB-Verzeichnis unter %LocalAppData%\Google\Chrome\User Data\Sync Data\LevelDB ablegt. Daraus könne ein unprivilegiertes Prozessprofil genug Metadaten ziehen, um relying parties, zugehörige Benutzernamen sowie Credential-Identifier und verschlüsseltes privates Schlüsselmaterial zuzuordnen.
Für relying parties und Credential Provider lassen sich aus der Studie dennoch konkrete Engineering-Ziele ableiten. Der Bericht empfiehlt, userVerification = required nicht nur zu setzen, sondern das Ergebnis auch anhand des zurückgegebenen UV-Bits zu verifizieren, statt sich auf die Serverseitige Parameterannahme zu verlassen. Provider sollten neu registrierte Keys stärker an Hardware- oder Attestationssignale koppeln, Checks bei der Re-Registration und Recovery härten und Zugriffe auf lokale Passkey-Zustände minimieren. Auch aus defensive Sicht gehört dazu, dass Master-Keys nicht in Logs landen und die Lebensdauer sensibler Secrets im Prozessspeicher so weit wie möglich reduziert wird. Ob eine PIN-Änderung oder das Löschen von Password-Manager-Daten die beschriebenen Secrets wirksam rotiert oder bereits kompromittierte Werte invalidiert, bleibt im Bericht offen; eine Nutzerprüfung ist zwar wünschenswert, aber die Quellenlage beschreibt keine SDS-spezifische Rotation oder ein gezieltes Revocation-Steuerungskonzept. Bis hier Klarheit entsteht, gilt die Hauptaussage der Studie: Nicht jede Passkey-Schwäche muss Kryptografie brechen – manchmal reicht es, dass eine Plattform-Integration ein „verifiziert“-Signal fälschlich akzeptiert oder Secrets zu lange im Clientkontext hält.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Angriffe auf Passkey-Schutz: Chrome-Cloud-Authenticator in Gefahr" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Angriffe auf Passkey-Schutz: Chrome-Cloud-Authenticator in Gefahr" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Angriffe auf Passkey-Schutz: Chrome-Cloud-Authenticator in Gefahr« bei Google Deutschland suchen, bei Bing oder Google News!