Passkeys gelten seit Jahren als moderne Alternative zu wiederverwendbaren Passwörtern – vor allem, weil sie Phishing erschweren. Doch neue Untersuchungen zeigen: Passkey-Angriffe können dennoch Sicherheitsversprechen in der Praxis angreifen, ohne die zugrunde liegende Kryptografie zu knacken. Stattdessen greifen die Forscher an verschiedenen Stellen der Sicherheitskette ein: bei gespeicherten Signaturen in Windows, bei der Verarbeitung synchronisierter Passkeys in Chrome/Google Password Manager und bei der Nutzung von Windows Hello for Business innerhalb bereits kompromittierter Sitzungen.
Wichtig: Die Ergebnisse sind nicht identisch. Je nachdem, ob es um Windows-Logging geht, um synchronisierte Schlüssel oder um Session-Rechte geht, unterscheiden sich auch die Auswirkungen und die passenden Gegenmaßnahmen.
Warum die Angriffe die Kryptografie nicht „brechen“
Die drei vorgestellten Forschungsstränge haben gemeinsam, dass sie nicht „die Mathematik“ der Passkey-Technologie knacken. Passkeys basieren auf standardisierten Verfahren wie WebAuthn und FIDO2, bei denen private Schlüssel nicht einfach extrahiert werden sollen. Die Angriffe zielen daher auf die Umgebung ab: auf Bedingungen, Validierungslogik, zwischengespeicherte oder wiederverwendete Signaturartefakte sowie auf die Art, wie Authentifizierungsmaterial akzeptiert wird.
So entsteht eine typische Lage aus der Praxis: Wenn Kontrollmechanismen in der Implementierung zu locker sind oder wenn zuvor erzeugtes Material wiederverwendbar bleibt, können Angreifer trotz „starker Kryptografie“ dennoch zu brauchbaren Authentifizierungswegen gelangen.
Windows-Kette: Privilegien durch wiederverwendete Signaturdaten
Ein Team um SpecterOps beschrieb eine Kette, die in Windows sowie in Microsoft Entra ID zur Impersonation privilegierter Nutzer führen kann. Das Besondere dabei: Der Angriff benötigt nicht zwingend das Auslesen des privaten Schlüssels eines Authentifikators wie eines YubiKey.
Die Forscher berichten, dass Windows frühere YubiKey-Signaturen in Klartext speichert, zumindest in einem Szenario, in dem unprivilegierte Nutzer – darunter auch Remote-Nutzer – diese Daten auslesen könnten. Durch das „Chaining“ dieser Signaturen mit Schwächen in der Passkey-Validierung von Entra ID soll die zuständige Cloud-Logik die Signatur in einem Replay-ähnlichen Ablauf akzeptieren. Dadurch kann eine Authentifizierungskette funktionieren, obwohl Richtlinien eigentlich phishingresistente MFA verlangen.
CVE-2026-34348 und was Microsoft dazu sagt
Das Windows-Problem wird als CVE-2026-34348 geführt. Dabei handelt es sich laut Quelle um eine Informationsoffenlegung im Windows Event Logging Service. Microsoft nennt für den betroffenen Fehler eine Vendor-CVSS-Bewertung von 6,5 und hat einen Security Update bereitgestellt.
Microsoft äußerte außerdem, man habe Mitigations für ein gemeldetes Problem im Zusammenhang mit Passkey Relay Assertions umgesetzt. Detaillierte technische Angaben zur Reichweite zusätzlicher Entra-seitiger Maßnahmen wurden in der öffentlichen Antwort jedoch nicht geliefert.
Der Hersteller empfiehlt insgesamt: Least-Privilege, phishingresistente Authentifizierung und konsequente Endpoint-Protections im Sinne eines Zero Trust-Ansatzes.
Google Password Manager: Master-Key aus Browser-Kontext
Unit 42 zeigt in einer zweiten Forschungsreihe Passkey-Angriffe, die den synchronisierten Passkey-Mechanismus im Umfeld von Chrome und Google Password Manager betreffen. Ausgangspunkt ist jeweils Malware auf dem Endgerät. Das ist entscheidend, denn es verschiebt die Frage von „Remote-Hack“ hin zu „was passiert nach einer Kompromittierung“.
Die Forscher beschreiben drei Angriffswege, die jeweils auf die Fähigkeit zielen, sich gegenüber Google als legitimer Client auszugeben – ohne dass der Nutzer erneut sein Gerät entsperren muss oder aktiv interagiert.
Abzweigung über Geräteidentität und User-Verification
Ein Ansatz missbraucht laut Bericht die Geräteidentitätslogik in Chrome. Damit können Angreifer Signaturen erzeugen bzw. beschaffen, um so aufzutreten, als sei ein gültiger WebAuthn-Client vorhanden. Unit 42 demonstrierte die Technik sogar in einem Fall gegen eBay, als die Seite User-Verifikation verlangte. Nach der Meldung habe eBay seine Validierung des WebAuthn-User-Verification-Flags angepasst.
„Golden Pass-ta-key“: Rückgewinnung synchronisierter Privatschlüssel
Besonders kritisch ist laut Unit 42 die Variante Golden Pass-ta-key. Sie zielt auf das Security Domain Secret ab: einen 32-Byte-Master-Key, der synchronisierte Passkeys schützt. Unit 42 fand diesen Schlüssel ursprünglich in Ausgaben des Geräte-Loggings in Chrome.
Google habe das Logging nach dem Bericht entfernt. Trotzdem sagen die Forscher: Der Secret sei in der Phase der erneuten Registrierung vorübergehend noch in der Prozess-Speicherlandschaft von Chrome vorhanden. Mit dem Secret können Angreifer die privaten Schlüssel synchronisierter Passkeys eines Opfers wiederherstellen.
Ein weiterer Punkt: Unit 42 gibt an, dass es derzeit keine Möglichkeit gibt, das Security Domain Secret gezielt zu rotieren oder zu widerrufen. Dadurch kann ein erfolgreicher Zugriff persistentere Folgen haben als das einmalige Abgreifen eines einzelnen Logins.
Windows Hello for Business: Nutzung ohne erneuten PIN/Scan
Der dritte Bericht, von Dirk-jan Mollema, konzentriert sich auf Windows Hello for Business. Auf modernen Windows-Geräten wird die zugehörige Schlüsselbasis typischerweise über das Trusted Platform Module geschützt und lässt sich nicht einfach exportieren. Das schließt eine missbräuchliche Nutzung jedoch nicht zwingend aus.
Mollema zeigt, dass Software mit niedrigeren Privilegien innerhalb einer bereits laufenden, angemeldeten Benutzerumgebung über kryptografische Schnittstellen auf das Windows Hello for Business Schlüsselmaterial zugreifen kann. Dabei wird kein neuer PIN- oder Biometrie-Prompt ausgelöst. Der Schlüssel lässt sich anschließend als FIDO2-Credential einsetzen, um bei Microsoft Entra ID eine Anmeldung zu erzeugen.
WebAuthn-Challenges und Zeitfenster
In dem Ablauf fand Mollema außerdem, dass die Entra WebAuthn Challenge laut Bericht fünf Minuten gültig ist und nicht an Session, Benutzer oder Tenant gebunden ist. Dadurch kann eine Challenge, die auf einem Angreifer-System angefordert wurde, auf die Opfermaschine „mitgenommen“ werden: Dort wird sie mit dem Windows Hello Key signiert und als WebAuthn Assertion zurückgegeben.
Das Ergebnis kann Anmeldungen unterstützen, die phishingresistente Conditional-Access-Regeln erfüllen. Mollema berichtet außerdem, dass Token unter Umständen keinen Device-ID-Claim enthalten. Das eröffnet laut Quelle einen Weg über Device Registration zu einem Primary Refresh Token und damit potenziell zu weiterer Persistenz.
Ein gemeinsames Muster – aber kein einzelner „Replay-Bug“
Auch wenn sich die Berichte im Ergebnis ähneln, sollte man sie laut Quelle nicht in einen einzigen Fehler zusammenlegen. Die Studien unterscheiden sich in ihrem Kern:
- SpecterOps beschreibt die Gefahr wiederverwendbarer Signaturartefakte, die Windows bereitstellt und die in eine Cloud-Authentifizierungskette einspeisen.
- Unit 42 untersucht Angriffe auf browser- und synchronisationsnahe Logik, inklusive des Umgangs mit einem Master Key, der synchronisierte Passkeys absichern soll.
- Mollema zeigt, wie Software innerhalb einer kompromittierten Windows-Session einen hardwaregebundenen Schlüssel verwenden kann, um frische Authentifizierungsmaterialien zu erzeugen.
Gerade diese Unterschiede erklären auch, warum kein einzelnes Prinzip („synchronisiert statt gerätegebunden“) das gesamte Angriffsbild automatisch schließt. Vielmehr hängt es davon ab, welche Implementierungsdetails in der jeweiligen Kette versagen.
Konkrete Schritte: So können Sie jetzt reagieren
Die Quelle leitet für Windows und Entra verschiedene unmittelbare Maßnahmen ab. Entscheidend ist, dass Sie die Sicherheitsumgebung als Ganzes betrachten – nicht nur die Passkey-Technologie selbst.
Windows: Security Updates einspielen
Für Windows sollte die sofortige Maßnahme sein, die von Microsoft bereitgestellten Updates für CVE-2026-34348 zu installieren. Da es in der Quelle um den Windows Event Logging Service geht, ist das gezielte Patchen in den betroffenen Versionen besonders relevant.
Zusätzlich wird empfohlen, dort, wo Services WebAuthn Assertions akzeptieren, die angefragten User-Verification-Anforderungen konsequent durchzusetzen. Wenn eine Implementierung diese Flags nicht zuverlässig prüft, können Angreifer Validierungslücken ausnutzen.
Endpoints: Passkey-Speicher und Browserkontext als Credential-sensitive Bereiche behandeln
Für den Endpoint bedeutet das: Passkey-Stores, Recovery-Flows und besonders Browser-Speicher sollten als hochwertige Zielbereiche betrachtet werden. Wenn Malware bereits auf dem System läuft, reichen klassische Annahmen („der private Schlüssel lässt sich nicht exportieren“) nicht mehr als alleinige Schutzlinie.
Die Quelle betont damit indirekt: Ein Zero-Trust-Ansatz muss auch die Nutzerendpunkte und deren Schutzstatus aktiv berücksichtigen.
Entra: Ungewöhnliche Windows Hello Aktivitäten überwachen
Für Entra ID wird empfohlen, auffällige Muster zu beobachten – etwa Windows Hello for Business Authentifizierungen ohne erwarteten Device Identifier oder unerwartete Device Registrations. Da die beschriebenen Token- und Claim-Details variieren können, sollten die Monitoring- und Alert-Regeln an Ihre Entra-Conditional-Access-Strategie angelehnt werden.
Ausblick: Passkeys werden in Entra stärker automatisiert
Microsoft erhöht laut Quelle die Priorität von Passkeys im Migrationsprozess. Ab dem 1. September 2026 sollen Entra ID Nutzer, bei denen derzeit SMS- oder Voice-Authentifizierung aktiv ist, automatisch auf Passkeys umgestellt bzw. dazu angestoßen werden, diese zu registrieren.
Parallel ist die Abschaltung der SMS- und Voice-Zustellung für den 1. Februar 2027 geplant. Das bedeutet: Auch für Organisationen, die Passkeys bisher nur vorsichtig eingeführt haben, steigt die Notwendigkeit, Implementierungen, Policies und Endpoint-Schutz sauber zu gestalten.
Fazit: Passkeys bleiben stark – aber Ihre Kette muss es auch sein
Die vorgestellten Passkey-Angriffe zeigen vor allem eins: Passkeys können Phishing deutlich erschweren, aber sie ersetzen nicht automatisch eine robuste Sicherheitsarchitektur rund um Authentifizierung. In den Berichten reichen Angreifer offenbar aus, um entweder wiederverwendbare Signaturdaten zu nutzen, synchronisierte private Schlüssel aus browsernahen Kontexten zurückzugewinnen oder hardwaregebundene Keys innerhalb kompromittierter Sessions missbräuchlich einzusetzen.
Wenn Sie jetzt handeln, ist der beste Hebel klar: Patches für relevante Windows-Schwachstellen einspielen, WebAuthn User-Verification-Strenge prüfen, Endpoint-Schutz gegenüber Credential-ähnlichen Daten konsequent stärken und Entra-Aktivitäten mit Blick auf ungewöhnliche Claims und Registrations überwachen. So schließen Sie die Lücken, die Angreifer in „den Umgebungen“ finden, nicht in der Kryptografie selbst.
Quelle: https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html
