Unit 42 toont drie aanvallen op gesynchroniseerde Google-passkeys

Unit 42 beschrijft drie aanvallen waarmee malware op een besmette Windows-pc gesynchroniseerde passkeys uit Google Password Manager overneemt, tot en met de hoofdsleutel waarmee alle passkeys van een account te ontsleutelen zijn.

Dat landt boven op een beslissing die Nederlandse beheerders deze maand nemen. Microsoft maakt passkeys op 1 september 2026 de standaard inlogmethode in Entra ID en schrapt per 1 februari 2027 de eigen sms- en voice-MFA. Entra ID accepteert daarbij ook passkeys uit precies die kluis, want Google Password Manager en Apple iCloud Keychain gelden als ondersteunde passkey-providers. Staat dat profiel bij jou aan, dan gaat dit onderzoek over de inlog van je eigen medewerkers.

Drie routes naar dezelfde passkey

Pass-ta-Key is de naam die Unit 42-onderzoeker Arie Olshtein geeft aan drie technieken waarmee malware op een Windows-apparaat met TPM de passkey-opslag van Chrome misbruikt. Ze verschillen in wat de aanvaller meeneemt: een enkele inlog, blijvende toegang, of de sleutel onder alle passkeys tegelijk.

• Pass-ta-Key. De malware leest de ingepakte identiteitssleutel uit de opslag van Chrome en ondertekent daarmee via Windows-API's zelf de aanvraag aan Google's Cloud Authenticator. Geen vingerafdruk, geen pincode, geen beheerdersrechten. Dat lukt alleen bij diensten die niet controleren of er echt een mens is geverifieerd. eBay accepteerde zo'n inlog en herstelde die controle na de melding.
• Silver Pass-ta-Key. De aanvaller dwingt het apparaat zich opnieuw te registreren en schuift in dat venster zijn eigen verificatiesleutel naar binnen. Daarna kan hij inloggen vanaf zijn eigen machine, ook als de laptop van het slachtoffer offline staat.
• Golden Pass-ta-Key. De zwaarste variant. De malware leest de Security Domain Secret uit het geheugen van Chrome, 32 bytes die alle gesynchroniseerde passkeys van het account beschermen, en ontsleutelt daarmee de complete sync-database.

Voor die laatste is er geen noodrem. Unit 42 stelt vast dat er geen mechanisme bestaat om de Security Domain Secret te roteren of in te trekken, waardoor ook passkeys die na de inbraak worden aangemaakt onder dezelfde gestolen sleutel vallen. Google haalde de sleutel na de melding uit de logbestanden van Chrome, maar volgens de onderzoekers staat hij nog steeds in het procesgeheugen.

Wat dit niet is

De proportie doet er hier toe, want de cryptografie blijft heel. De onderzoekers benadrukken dat de aanvallen de cryptografie achter passkeys niet breken. Het probleem zit in de code eromheen: hoe Chrome zijn apparaatsleutels bewaart, hoe een apparaat zich opnieuw aanmeldt nadat die staat verdwijnt, en of de site waar je inlogt überhaupt nakijkt dat er een mens is geverifieerd.

En er is een harde voorwaarde. Elk pad begint bij malware die al op het apparaat van het slachtoffer draait, een Windows-machine met TPM. Er zijn geen CVE-nummers toegekend en misbruik in het wild is niet vastgesteld. Dit is dus geen reden om de overstap naar passkeys uit te stellen, wel om te weten wat je je team belooft: een passkey haalt het phishbare geheim uit je inlog, maar hij beschermt een apparaat niet tegen zichzelf.

Wat dit betekent voor je Entra-uitrol

Microsoft trekt de scheidslijn zelf al. In dezelfde documentatie staat dat gesynchroniseerde passkeys geen attestation ondersteunen, en dat je voor beheerders en gebruikers met toegang tot gevoelige systemen beter apparaatgebonden passkeys kiest: een FIDO2-sleutel of een passkey in Microsoft Authenticator. Tegelijk duwt Microsoft de gesynchroniseerde variant naar de brede groep, met gebruikscijfers uit de eigen consumentenomgeving: inloggen duurt 3 seconden tegen 69 seconden bij een wachtwoord met traditionele MFA. Dat advies stond er al voor dit onderzoek. Het krijgt er nu een uitgewerkte aanvalsketen bij.

In de praktijk komt dat neer op drie dingen. Splits je passkey-profielen in Entra ID: gesynchroniseerd voor de brede groep, apparaatgebonden voor beheerders, financiën en iedereen met rechten op klantdata. Zet bij dat tweede profiel de optie Enforce attestation aan, zodat alleen sleutels van een bekend type worden geaccepteerd. En bouw je zelf een applicatie waar klanten met een passkey inloggen, controleer dan of je server de user-verification-vlag echt afdwingt in plaats van hem te negeren, want dat was precies het gat bij eBay.

Waar dit heen wijst

De verdediging schuift op van de inlog naar het apparaat. Dat is dezelfde beweging die de uitrol van passkeys sowieso al kenmerkt: zolang de zwakke sms-terugval naast de passkey blijft staan verandert er voor een aanvaller vrijwel niets. Alleen verplaatst het werk zich nu een laag dieper, naar de sleutelopslag van de browser en het moment waarop een apparaat zich opnieuw registreert.

Dat is niet nieuw, wel scherper. Bij wachtwoordmanagers zag je hetzelfde gebeuren: bijna één op de vier aanvallen richt zich inmiddels op opgeslagen inloggegevens in plaats van op inbreken. Een gesynchroniseerde passkey is die kluis in een nieuwe vorm, met dezelfde eigenschap: één geslaagde besmetting levert niet één account op, maar alles wat erin ligt. Wie op 1 september de knop omzet, verkleint de kans dat iemand een code weggeeft en vergroot het belang van de vraag wie er naar die laptops kijkt.