Onderzoekers waarschuwen voor een nieuwe manier waarop Windows Hello for Business keys kunnen worden misbruikt. De kern: draait er malware in een Windows-sessie terwijl de gebruiker interactief is ingelogd, dan kan de schadelijke code Windows Hello for Business gebruiken om zich stil te authenticeren bij Microsoft Entra ID. Dat opent de deur naar langere toegang tot cloudservices, inclusief het registreren van een device en het verkrijgen van token-artefacten zoals een Primary Refresh Token (PRT).
In dit artikel leggen we uit wat er precies wordt aangetoond, waarom dit past binnen de manier waarop Windows Hello for Business en ticketing werken, en welke signalen je kunt monitoren om dit soort misbruik tijdig te herkennen.
Wat is er nieuw aan het misbruik van Windows Hello for Business keys?
Dirk-jan Mollema, een Entra ID-onderzoeker, liet zien dat malware die al draait in een ingelogde Windows-sessie de Windows Hello for Business-sleutel kan gebruiken om authenticatie richting Microsoft Entra ID te starten. Dat gebeurt zonder dat de aanvaller de private key hoeft te extraheren en zonder dat de gebruiker opnieuw biometrie hoeft te bevestigen.
De techniek richt zich op persistentie in de cloud. Nadat de malware zich kan authenticeren, kan de aanvaller vervolgens een device registreren dat hij zelf controleert, een PRT verkrijgen en—mits tenantbeleid dit toestaat—extra authenticatiemethoden toevoegen op dat nieuwe device.
Geen administratorrechten en geen biometrische prompt op TPM-systemen
Een belangrijk detail in de bevindingen is dat administratorrechten niet nodig zijn. Ook op systemen met TPM-ondersteuning werd niet vastgesteld dat de private key uit de beveiligde hardware hoeft te worden gehaald, de PIN hoeft te worden teruggewonnen, of dat er een biometrische prompt wordt getriggerd.
De achtergrond is volgens de onderzoeker hoe Windows ticketing de interne private-key operaties beschikbaar houdt zolang de gebruiker interactief is ingelogd. Daardoor kan code die als de ingelogde gebruiker draait Windows vragen om ondertekening te doen voor authenticatiegegevens.
Van DEF CON naar “passkey-achtig” gedrag via WebAuthn
Mollema beschrijft dat eerdere concepten op DEF CON 32 (2024) al lieten zien dat je Windows Hello for Business op een bepaalde manier kunt aanspreken om een signed assertion voor een PRT te produceren. Die eerdere aanpak vereiste wel toegang tot een Entra-registered of joined device.
Het nieuwe werk haalt die beperking weg. In plaats van die afhankelijkheid te benutten, behandelt de aanpak de Windows Hello for Business-sleutel als een soort FIDO2-passkey via WebAuthn. Daardoor kan de Entra-uitdaging binnen vijf minuten worden gebruikt zonder sterke binding aan een specifieke sessie, gebruiker of tenant.
Waarom maakt token-informatie het lastig om op te sporen?
De onderzoekers vonden dat het token dat volgt uit deze aanpak geen claim bevat die het device ondubbelzinnig identificeert. Dat is relevant omdat een aanvaller daarmee een nieuw device kan registreren en vervolgens opnieuw een PRT voor dat device kan aanvragen.
Volgens Microsoft blijft een PRT 90 dagen geldig. Daarnaast wordt die geldigheid continu vernieuwd zolang de gebruiker actief het betreffende device gebruikt. Combineer je dat met malware die al in de sessie draait, dan kan een aanvaller langdurig cloudtoegang opbouwen met de authenticatiewaarden die in de keten worden gegenereerd.
Conditional Access omzeilen: “phishing-resistant” is niet overal genoeg
Een van de meest opvallende punten is de impact op phishing-resistente authenticatie. Mollema stelt dat de WebAuthn-aanmelding Conditional Access policies kan voldoen die phishing-resistant authentication strength vereisen. Anders gezegd: zelfs als je beleid inzet om phishing te blokkeren, kan malware binnen een legitiem ingelogde omgeving alsnog een sterke authenticatieketen tot stand brengen.
Daarnaast kan de aanmelding tellen als een verse multi-factor authentication voor het nieuwe device. Met die status kunnen aanvallers—in tenantomgevingen waar beleid dat toestaat—nieuwe passkeys of Windows Hello for Business keys toevoegen op het device dat de aanvaller controleert.
Tegelijk geldt er een kanttekening: device-state of compliance policies kunnen de keten alsnog onderbreken. Daardoor werkt de volledige route niet in elke inrichting, maar de bevindingen maken wel duidelijk waar de grenzen liggen van phishing-resistant instellingen.
Waar zit het vereiste: code-uitvoering in de ingelogde sessie
De methode is niet “remote magic”. De aanval heeft één duidelijke voorwaarde: de aanvaller moet code kunnen uitvoeren in de Windows-sessie waarin de gebruiker interactief is ingelogd. Dat maakt het geen universele aanval die van buitenaf direct werkt, maar wel een realistisch scenario zodra een endpoint gecompromitteerd is.
De disclosure meldt bovendien niet dat er bewijs is van actieve exploitatie of specifieke slachtoffers. Het gaat dus om een onderzoeksbevinding en een detectie-aanbeveling, niet om een rapportage van een lopende campagne.
Welke signalen kun je monitoren?
Voor defensie is vooral detectie van anomalieën relevant. Mollema adviseert om te jagen op Windows Hello for Business sign-ins met een lege device ID. Daarbij is het belangrijk om te weten dat legitieme scenario’s—zoals incognito browser-sessies of sessies zonder SSO—een vergelijkbaar patroon kunnen opleveren.
Daarom is het verstandig om niet alleen op het veld te filteren, maar ook op context: denk aan apparaat- en gebruikerstransities, plotselinge device-registraties of onverklaarde authenticatiestromen tijdens periodes waarin je geen match met normaal gedrag ziet.
POC-scripts en ROADtools: wat zit er technisch achter?
De onderzoeker publiceerde PowerShell proof-of-concept scripts in de ROADtools repository. In de betreffende map zijn op 6 augustus 2026 de bestanden fido_assertion.ps1 en hellopoc.ps1 teruggevonden. Met dit soort tooling kan worden aangetoond hoe een signed assertion via WebAuthn kan worden opgebouwd en hoe je vervolgens tokens kunt aanvragen of een browsersessie als de gebruiker kunt initiëren.
De bijbehorende bevinding vermeldt ook dat het Entra ID-challenge-proces niet bound lijkt aan een sessie, gebruiker of tenant. Dat verklaart waarom een aanvaller het op een andere host kan uitvragen, waarna het gecompromitteerde endpoint de ondertekening levert.
Praktische mitigaties: voorkom dat malware in je sessie blijft rondhangen
Omdat de sleutelvoorwaarde code-uitvoering in de ingelogde sessie is, draait de primaire mitigatie om het verkleinen van endpoint-compromis en het beperken van wat malware kan doen zodra het eenmaal aanwezig is.
- Monitor device registraties: let op onverwachte registraties of wijzigingen in auth-methoden.
- Combineer signalen: koppel Windows Hello for Business sign-ins met lege device ID aan risicocriteria zoals onbekende hosts, tijdstippen en login-patronen.
- Versterk endpoint-hygiëne: draai up-to-date EDR/antimalware, beperk installatierechten en voorkom dat aanvallers blijven persist herbergen in actieve sessies.
- Herzie Conditional Access ontwerp: zet policies in met oog voor het feit dat phishing-resistente MFA niet automatisch betekent dat “tokens niet misbruikbaar zijn” bij een al gecompromitteerde sessie.
Als je beleid en responseprocessen wil aanscherpen op basis van dit soort research, kan het ook helpen om eerder gepubliceerde inzichten over misbruik van token- en sessieketens te vergelijken. Zie bijvoorbeeld hoe aanvallen zich soms via technische tussenpaden kunnen vastzetten in sessies en authenticatielagen, zoals bij NatJack-aanvallen waarbij TCP-sessies worden gekaapt.
Wat betekent dit voor beheerders?
Voor IT- en securityteams is het belangrijkste take-away: Windows Hello for Business keys blijven “hardware-bound” en exportonafhankelijk, maar dat betekent niet dat ze onmisbruikbaar zijn wanneer malware al binnen de context van een ingelogde gebruiker draait. De beveiliging beschermt tegen export, niet noodzakelijk tegen misbruik van legitieme ondertekeningsstromen.
Daarnaast laat de casus zien dat de cloud authenticatieketen (van aanmelding tot PRT en device registratie) gevoelig kan zijn voor endpoints die al gecompromitteerd zijn. Daarom is detectie van anomalieën rond sign-ins en deviceregistraties cruciaal, zeker wanneer je Conditional Access gebruikt voor phishing-resistant sterkte.
Conclusie
Het onderzoek van Mollema toont aan dat malware in een actieve Windows-sessie Windows Hello for Business keys kan aanspreken om stille authenticatie bij Microsoft Entra ID te realiseren. Daarmee kan een aanvaller langdurigere cloudtoegang opbouwen door device registraties te doen en PRT’s te verkrijgen, zonder private key extractie, PIN-terugwinning of biometrische prompts in de beschreven scenario’s.
Door gerichte monitoring—zoals Windows Hello for Business sign-ins met een lege device ID—te combineren met endpointbescherming en strengere respons bij verdachte device-registraties, verklein je de kans dat dit type misbruik ongemerkt tot echte persistentie leidt.
Bron: https://thehackernews.com/2026/08/malware-can-abuse-windows-hello-for.html
