Passkeys zijn bedoeld om herbruikbare wachtwoorden te vervangen en je te beschermen tegen phishing. Toch laten recente onderzoeken zien dat passkey-aanvallen kunnen slagen zonder de onderliggende cryptografie “te kraken”. In plaats daarvan richten aanvallers zich op waar het authenticatiemateriaal wordt vastgelegd, hoe validatie in cloudomgevingen werkt en welke toetsing (zoals PIN of biometrie) wel of niet opnieuw wordt afgedwongen.
De rode draad: het beveiligingsmodel blijft sterk, maar de omliggende componenten kunnen falen. Dat maakt de lessen praktisch, maar ook urgent: als een endpoint of sessie al gecompromitteerd is, kunnen aanvallers met het juiste “handige legitieme” materiaal alsnog binnenkomen.
Waarom passkeys niet automatisch “100% onkwetsbaar” zijn
In alle drie de onderzoeksinspanningen bleek dat de wiskunde achter passkeys niet wordt doorbroken. De aanvallen veranderen het spel rond authenticatie door te profiteren van hergebruik van getekende informatie en van onvoldoende gebondenheid aan context (zoals gebruikerssessie of een vers PIN/biometrie-moment).
Belangrijk detail: de onderzoekers beschrijven verschillende routes. In de ene case draait het om door Windows opgeslagen handtekeningen die daarna via Microsoft Entra ID worden geaccepteerd. In de andere case draait het om een synced-passkey mechanisme in Chrome en het terughalen van privésleutels. En in de derde case gaat het om Windows Hello for Business-keys die binnen een reeds lopende, gecompromitteerde gebruikerssessie kunnen worden ingezet.
SpecterOps: priviligeerders imiteren met Windows-materiaal en Entra-validatie
SpecterOps presenteerde een keten die kan leiden tot impersonatie van bevoorrechte gebruikers, terwijl aanvallers alsnog voldoen aan phishing-resistente MFA-eisen. De kern is dat de aanvaller niet per se een authenticator-privésleutel steelt (dus geen “breek FIDO2”-scenario), maar eerder ondertekende authenticatiegegevens opnieuw gebruikt die Windows eerder heeft blootgesteld of bewaard.
Volgens het onderzoek zijn in Windows eerder YubiKey-handtekeningen opgeslagen in leesbare vorm waar niet-geprivilegieerde gebruikers (ook remote) erbij konden. Door die handtekeningen te combineren met zwakheden in hoe passkey-validatie plaatsvindt in Microsoft Entra ID, kan een aanvaller een privileged gebruiker imiteren zonder dat de gewenste context-checks effectief werken.
Deze Windows-kwetsbaarheid is geregistreerd als CVE-2026-34348. Het gaat om een informatie-disclosure issue in de Windows Event Logging Service. Microsoft geeft aan dat er mitigaties zijn toegepast voor een gerelateerde kwestie rond passkey relay assertions. Daarbij benadrukt Microsoft dat het onderzoek via gecoördineerde disclosure is opgevolgd met beveiligingsverbeteringen over authenticatiemethoden heen.
Unit 42: Golden Pass-ta-key en het terughalen van synced privésleutels
Unit 42 richt zich op passkeys die gesynchroniseerd worden via Google Password Manager in Chrome op Windows. In de beschreven scenario’s start de aanval telkens met malware die al op de endpoint draait; er is geen administrator-level privilege-escalatie nodig om de techniek te benutten.
De onderzoekers tonen dat Chrome’s “device identity” componenten kunnen worden misbruikt om de benodigde signatures te verkrijgen om op te treden als een legitieme Password Manager-client, zonder dat er een nieuwe toestelontgrendeling of extra gebruikersinteractie nodig is.
Een van de varianten heet Golden Pass-ta-key. Die grijpt het zogenoemde Security Domain Secret aan, een master key van 32 bytes die volgens Unit 42 dient om synced passkeys te beschermen. De onderzoekers vonden aanvankelijk dat dit geheim werd blootgelegd in device logging; Google heeft dat aangepast nadat het rapport is gedaan.
Toch stellen de onderzoekers dat het geheim tijdelijk nog aanwezig kan zijn in het procesgeheugen van Chrome tijdens een herregistratie. Met dat geheim kunnen aanvallers volgens Unit 42 uiteindelijk de synced passkey privésleutels van het slachtoffer terughalen.
Daarnaast noemt Unit 42 dat de implementatie volgens hen geen mogelijkheid biedt om het Security Domain Secret te roteren of te revokeren. Daardoor kan een compromis langer doorwerken dan bij eenmalige gegevens die direct weer verlopen.
Dirk-jan Mollema: Windows Hello for Business gebruiken zonder nieuwe PIN/biometrie
Een derde onderzoeksroute gaat over Windows Hello for Business. Op moderne Windows-apparaten is de backing key volgens de beschrijving beschermd door de Trusted Platform Module en kan die niet simpelweg worden geëxporteerd. Maar dat betekent nog niet dat software in een compromisde sessie de sleutel nooit kan inzetten.
Mollema vond dat een proces met lage privileges binnen een reeds ingelogde (en dus mogelijk gecompromitteerde) gebruikerssessie gebruik kan maken van cryptografische interfaces om een Windows Hello for Business-key te gebruiken zonder een nieuw PIN- of biometrie-ontgrendelingsmoment.
Vervolgens gebruikte Mollema die key als FIDO2-credential richting Microsoft Entra ID. Daarbij wijst het onderzoek op een relevant validatie-aspect: de Entra WebAuthn challenge zou geldig zijn voor ongeveer vijf minuten en niet gebonden zijn aan een specifieke sessie, gebruiker of tenant. Daardoor kan een challenge die door een aanvaller wordt aangevraagd “meegenomen” en op de slachtoffersmachine worden ondertekend, waarna hij teruggaat als WebAuthn assertion.
Die assertion kan inlog mogelijk maken die Conditional Access-regels op basis van phishing-resistente authenticatie wél kan passeren. Het onderzoek noemt daarnaast een risico waarbij het resulterende token mogelijk zonder device identifier claim komt, wat weer routes opent naar device registration en extra persistentie (zoals Primary Refresh Tokens).
Geen one-bug-fix: sterke crypto, zwakkere ketenomgeving
De drie bevindingen moeten niet op één hoop worden gegooid. Dat is belangrijk voor zowel defenders als besluitvorming in teams. Waar SpecterOps focust op hergebruik van reeds aanwezige getekende assertions die door cloudvalidatie worden geaccepteerd, beschrijft Unit 42 een variant waarbij synced-keymateriaal kan worden teruggehaald en Mollema laat zien hoe software binnen een live sessie een hardware-gebonden sleutel kan gebruiken om frisse authenticatie te produceren.
De aanvalspaden starten ook op verschillende plekken. Unit 42 begint met malware op de endpoint. Mollema’s route begint binnen een reeds gecompromitteerde gebruikerssessie. Dat verschil maakt duidelijk: passkeys kunnen falen in scenario’s waarin het endpoint of de sessie al onder controle is, maar dat is niet hetzelfde als een aanval vanuit volledig unauthenticated remote positie.
Wat kun je nu doen? Concrete mitigaties per laag
De onmiddellijke actie voor Windows is helder: installeer de toepasselijke updates van Microsoft voor CVE-2026-34348. Omdat het om een informatie-disclosure issue gaat, is patchen een basisvoorwaarde om misbruik van opgeslagen of gelogd authenticatiemateriaal te beperken.
Daarnaast moeten services die WebAuthn-assertions accepteren, de user-verification vereisten afdwingen die ze zelf vragen. Als een keten impliciet aanneemt dat “het wel goed zit” in de context, ontstaan er juist gaten.
Voor endpointverdediging geldt een stevige boodschap: behandel passkey stores, recovery flows en relevante browser-geheugencomponenten als credential-sensitive gebieden. Als een aanvaller al code kan draaien op het endpoint, worden “legitieme” authenticatiefeatures al een hulpmiddel voor misbruik.
In Entra-land kan monitoring helpen. Het onderzoek noemt onder meer dat je ongebruikelijke Windows Hello for Business-authenticaties wilt herkennen die afwijken van normale patronen—bijvoorbeeld wanneer er geen device identifier claim is of wanneer er onverwachte device registraties plaatsvinden.
Synced versus device-bound: kies niet alleen, maar versterk de keten
Een deel van de discussie rond passkeys gaat vaak over de keuze tussen synced passkeys en device-bound passkeys. De bevindingen maken echter duidelijk dat er geen enkelvoudige keuze is die automatisch het volledige aanvalsvlak afdekt.
Wat je uiteindelijk nodig hebt, is een samenhangend geheel: minimaal privilege, sterke phishing-resistente authenticatie, een Zero Trust benadering en een strakke endpoint hygiëne. Microsoft verwijst ook naar least-privilege en het actief onderhouden van endpointbescherming als onderdeel van die strategie.
Microsoft rolt passkeys verder door: timing om rekening mee te houden
Tot slot is er een praktische planning vanuit Microsoft. Vanaf 1 september 2026 worden Entra ID-gebruikers die nu SMS of voice authenticatie gebruiken automatisch richting passkeys geduwd en worden ze aangemoedigd om die te registreren. Microsoft plant ook de retirement van SMS en voice delivery op 1 februari 2027.
Voor organisaties betekent dit: ga passkeys niet alleen “aanzetten”, maar ook parallel testen op detectie, logging, device registratieflows en de impact van endpointcompromittering. Juist omdat de aanvallen niet de cryptografie breken, maar de omgeving benutten, moet je beveiliging op meerdere plekken tegelijk aanscherpen.
Meer context: passkeys en MFA in het bredere threatlandschap
De passkey-aanvallen passen in een groter patroon waarin aanvallers zoeken naar de zwakste schakel in authenticatieketens en waar social engineering of tokenlogica wordt gecombineerd met technische misbruikscenario’s. Als je wilt zien hoe phishing-weerbaarheid en endpoint- en sessiebeveiliging samenkomen, bekijk dan ook dit artikel over Microsoft 365 AitM phishing.
Conclusie: patch, handhaaf en bewaak de context
De nieuwe onderzoeksresultaten maken één ding duidelijk: passkey-aanvallen kunnen slagen door slim te leunen op herbruikbaar authenticatiemateriaal, synced-keymechanismen en het gedrag van authenticatievalidatie. De cryptografie staat niet ter discussie, maar de omstandigheden waarin authenticatie wordt gegenereerd en geverifieerd wel.
Pak daarom meteen de relevante Windows-patches voor CVE-2026-34348 aan, dwing user-verification af waar je WebAuthn gebruikt, behandel passkey-gerelateerde data als credential-sensitive en versterk monitoring op Entra en device registration. Zo verklein je de kans dat een compromisde endpoint verandert in een startpunt voor authenticator-overname.
Bron: https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html
