Passkeys beloven sterke beveiliging: in plaats van wachtwoorden moeten gebruikers aantonen dat ze echt zijn. Toch laat nieuw onderzoek zien dat malware die al op een Windows-systeem draait een heel andere route kan nemen—namelijk via Google Password Manager in Chrome. De kern: de aanval richt zich niet op het “breken” van de cryptografie, maar op de softwarelaag eromheen, en op hoe authenticatie-informatie wordt opgeslagen, opnieuw ingeschreven en gevalideerd.
Belangrijk om te weten: de onderzoekers beschrijven technieken voor situaties waarin het apparaat al gecompromitteerd is. Er worden geen CVE’s genoemd en de publicatie vermeldt niet welke Chrome-versies exact getroffen zouden zijn. Dat neemt niet weg dat de lessen relevant zijn voor iedereen die passkeys gebruikt of als website een rol speelt in de verificatie.
Wat onderzoekers precies ontdekten
De studie van Unit 42 beschrijft drie aanvalspaden tegen de cloud-authenticator van Chrome, die onder de naam Pass-ta-key, Silver Pass-ta-key en Golden Pass-ta-key wordt genoemd. De aanvallen zijn ontworpen rond de master key die gebruikerspasskeys beschermt die worden gesynchroniseerd.
Volgens het rapport blijft de wiskundige beveiliging overeind; de aanvallen draaien om de context rondom passkeys: hoe Chrome device-gegevens verwerkt, hoe opnieuw inschrijven (re-enrollment) werkt wanneer een bepaalde status verdwijnt, en of de site (de relying party) echt controleert of een gebruiker is geverifieerd.
Drie aanvalspaden in mensentaal
Alle drie de routes beginnen met lokale verkenning op het toestel. Op Windows kijkt Chrome onder meer naar gesynchroniseerde credentialrecords die zijn opgeslagen in een directory zoals %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Daaruit kan malware metadata afleiden over welke relying parties en usernames gekoppeld zijn aan de passkeys, plus credential-IDs en versleutelde private-key-materiaal.
1) Pass-ta-key: signeren zonder dat de gebruiker echt is geverifieerd
Het eerste pad draait om het gebruik van een device-identity key die door Chrome wordt “ingepakt” en vervolgens via de Trusted Platform Module (TPM) wordt gebruikt om een verzoek te ondertekenen. De malware probeert daarbij een signatuur te krijgen die in de praktijk lijkt op wat een echte gebruikerscontrole zou opleveren—maar dan ontbreekt precies één belangrijk bit: de User Verified (UV)-vlag.
In de aanval is het onderscheid volgens de onderzoekers uiteindelijk klein: een ceremonie-uitkomst die het systeem markeert als “gebruiker geverifieerd” valt weg. De onderzoekers wijzen erop dat sommige relying parties (sites) in test- of implementatievarianten minder streng bleken. Daardoor kan een validatie-gat ontstaan dat pas opvalt nadat er is gediscloseerd.
De onderzoekers zeggen ook dat deze route het meest afhankelijk is van een check die de relying party zelf hoort te doen. Met andere woorden: zelfs als de cloud-authenticator een geldig assertion retourneert, zou de site moeten falen wanneer UV ontbreekt.
2) Silver Pass-ta-key: Chrome laat opnieuw inschrijven toe met een “eigen” sleutel
Het tweede pad richt zich op de volgende laag. Malware forceert Chrome om een apparaat opnieuw in te schrijven. In zo’n venster—wanneer Chrome nog niet meteen de gebruikersverificatie-sleutel heeft opgebouwd—kan een aanvaller proberen om een sleutel te registreren die hij zelf beheert.
Het rapport geeft aan dat bij later gebruik claims/asserions met de UV-flag kunnen worden meegestuurd. De onderzoekers noemen daarbij dat het servicegedrag niet controleerde of de nieuw geregistreerde sleutel afkomstig was uit beveiligde hardware. Omdat het certificaat- of attestation-aspect ontbreekt of onvoldoende wordt gecheckt, kan een aanvaller later logins proberen zonder dat de victim-pc (op dat moment) noodzakelijk een echte gebruikersverificatie uitvoert.
Ook hier geldt: het rapport beschrijft niet met zekerheid of en hoe dit al voor alle huidige Chrome-situaties is afgedicht. Het benoemt wel dat hardening via hardware-attestation als mitigatie wordt gezien voor dit scenario.
3) Golden Pass-ta-key: via memory blootleggen van de Security Domain Secret (SDS)
Het derde aanvalspad gaat het verst in op de interne geheimen. De onderzoekers stellen dat malware Chrome kan triggeren om opnieuw in te schrijven, vervolgens de Security Domain Secret (SDS) kan uitlezen terwijl Chrome die kort in plaintext in het geheugen heeft, en dat geheim kan gebruiken om gesynchroniseerde passkey-private keys terug te winnen.
Chrome maakt of ontvangt volgens de onderzoekers een SDS van 32 bytes en die komt in de datastructuren van het clientproces terecht. Het rapport zegt dat eerdere logging-gerelateerde issues zijn aangepast, en dat sommige relying parties (zoals eBay) UV-validatie inmiddels beter zouden afhandelen. Toch blijft volgens Unit 42 het belangrijkste punt: de secret bereikt de client en kan in geheugen zitten. Een loggingwijziging lost dat type risico niet per se op.
Het onderzoek maakt verder niet volledig duidelijk of alle paden inmiddels gesloten zijn, en het beschrijft ook geen “gebruikerscheck” om zelf te controleren of SDS is blootgesteld.
Waarom dit niet betekent dat passkeys “kapot” zijn
Het is verleidelijk om dit nieuws te lezen als: “dan werkt het hele passkey-concept niet.” Dat is niet wat hier wordt beschreven. De onderzoekers benadrukken dat de cryptografie niet wordt gebroken. De aanvallen zijn post-compromise: malware moet al op de computer draaien.
Dat onderscheid is cruciaal. Het laat zien dat passkeys vooral goed zijn tegen normale phishing en wachtwoorddiefstal, maar dat een volledig gecompromitteerd endpoint alsnog kan worden misbruikt om authenticatielogica te beïnvloeden. In zo’n scenario verschuift de vraag van “kan ik de sleutel stelen?” naar “kan ik een systeem laten geloven dat de verificatiestap is geslaagd?”
Wat kunnen relying parties en gebruikers doen?
Het rapport eindigt met aanbevelingen die vooral gericht zijn op wie de relying party is (websites en credential providers) en op hoe je je recovery- en re-registratieproces ontwerpt.
- Relying parties: zet userVerification op required en valideer de UV-bit bij de terugkeer van de assertion, in plaats van alleen te vertrouwen op wat het request zegt.
- Credential providers: controleer/attesteer nieuwe ingeschreven keys uit secure hardware en verbeter checks rondom herinschrijving en herstel.
- Beperk lokaal passkey-state: restricties op toegang tot lokale passkeygegevens kunnen helpen als een proces al toegang probeert te krijgen.
- Master keys weg uit logs en geheugen: vermijd dat gevoelige materiaal in clientlogs terechtkomt; verklein de kans dat secrets lang in process memory beschikbaar zijn.
Voor gebruikers is de praktische vervolgvraag: “Als ik mijn account beveilig, is een reeds gestolen secret dan ongeldig?” Het onderzoek geeft hier geen sluitend antwoord op. Wel staat in de publieke ondersteuning van Google Password Manager dat je bijvoorbeeld je PIN kunt wijzigen of alle Password Manager-data kunt verwijderen, maar er is geen SDS-specifieke rotatie of revocation-control beschreven.
Relatie met eerder onderzoek: endpoint-first is een trend
Deze vondst past in een breder patroon dat we vaker zien in beveiligingsnieuws: aanvallen richten zich niet alleen op de “buitenwereld”, maar op de logica en workflow rond authenticatie, zodra een aanvaller toegang heeft tot een device. Zie bijvoorbeeld ook hoe onderzoekers naar exploit-tijdlijnen en prioritering kijken—wat je als eerste afdekt bij een keten bepaalt vaak welke impact je nog kunt voorkomen: AI-exploit-tijdlijnen: focus op prioritering.
Ook zijn er in eerdere incidenten signalen geweest dat credentials of toegang soms via onverwachte componenten of omwegen worden benut. Denk aan onderzoeken die laten zien hoe kwaadwillenden bestaande beveiligingslagen kunnen “omzeilen” door implementatieverschillen. Dat maakt het extra belangrijk om niet alleen technische bescherming te hebben, maar ook te letten op implementatiekwaliteit aan de kant van sites en authenticatoren.
Wat betekent dit voor jou nu?
Als je passkeys gebruikt via Chrome en Google Password Manager, betekent dit onderzoek vooral dat je je threat model moet aanscherpen. De grootste winst zit in het voorkomen van malware op het endpoint: zodra een aanvaller al draait als “normale gebruiker” op je Windows-systeem, kan authenticatielogica worden misbruikt.
Verder is het slim om te letten op updates en aanbevolen hardening voor je browser en besturingssysteem. Het rapport noemt geen complete set van remediaties en geen exacte getroffen Chrome-versies. Dat maakt “wachten op bevestiging” gevaarlijk: zodra er beveiligingsupdates uitkomen, is bijwerken vaak de belangrijkste stap.
Samenvattend
Unit 42 beschrijft drie aanvalspaden waarbij malware op een Windows-systeem kan proberen passkey-beschermde accounts te gebruiken via Google Password Manager in Chrome. De aanvallen breken de cryptografie niet; ze proberen juist de gebruikersverificatie te omzeilen, opnieuw inschrijven te sturen met aanvallersleutels, of (in één route) een geheim uit Chrome-geheugen te onttrekken.
Voor relying parties is de boodschap helder: valideer de UV-bit en bouw robustere re-enrollment en recovery checks. Voor gebruikers betekent het vooral: voorkom endpoint-compromise, blijf up-to-date en behandel een mogelijk gecompromitteerd apparaat als een incident waarvoor je meer dan alleen “wachtwoorden wisselen” moet doen.
Bron: https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
