Credential Guard

Wat is Credential Guard?

Credential Guard is een Windows-functie die de credentials in LSASS afschermt. Het gebruikt Virtualization-Based Security (VBS) om die geheimen op te slaan in een apart proces dat door de hardware is geïsoleerd. Zelfs malware met adminrechten of SYSTEM-rechten op de gewone Windows-omgeving komt daar niet bij.

Vroeger stonden die credentials in het geheugen van lsass.exe, het Local Security Authority-proces. Dat is precies wat tools als Mimikatz uitlezen. Credential Guard haalt ze daar weg en zet ze in een apart proces dat de hypervisor afschermt. De functie heette vroeger Windows Defender Credential Guard en zit sinds Windows 10 Enterprise en Windows Server 2016 in Windows.

Hoe werkt het?

VBS gebruikt de hypervisor om een geïsoleerd deel van het geheugen te maken, los van de gewone Windows-omgeving. Daarin draait een apart LSA-proces, LSAIso.exe. Dat proces bewaart en beschermt de geheimen. De normale LSA in Windows praat er via remote procedure calls mee, maar kan niet in het geheugen ervan kijken. Het geïsoleerde proces draait geen drivers en bevat alleen een kleine set ondertekende beveiligingsbinaries, waarvan VBS de handtekening controleert voordat ze starten.

Credential Guard beschermt drie soorten geheimen:

• NTLM-wachtwoordhashes.
• Kerberos Ticket-Granting Tickets (TGT’s).
• Credentials die applicaties als domein-credentials opslaan in Credential Manager.

Op hardware met een TPM 2.0 hangt persistente VBS-data aan een VSM-master key die door de TPM wordt beschermd. De hashes en TGT’s zelf blijven meestal niet bewaard over een herstart. Die raken bij een reboot kwijt en komen terug zodra de gebruiker opnieuw inlogt.

Wat beschermt het wel en niet?

Credential Guard zorgt dat de beschermde geheimen niet meer in lsass.exe staan, maar in het geïsoleerde proces. Een aanvaller die het LSASS-geheugen uitleest, krijgt die NTLM-hashes en TGT’s daardoor niet meer te pakken. Dat remt Pass-the-Hash en pass-the-ticket voor de accounts die het dekt.

Credential Guard beschermt niet de lokale SAM en dus niet de lokale accounts. Het beschermt niet de NTDS.dit, de wachtwoorddatabase op een domain controller. Cached domein-credentials in het register blijven onbeschermd. Ook een wachtwoord dat iemand los aanlevert voor een NTLM-login valt erbuiten. Credential Guard schermt de opgeslagen hash van de ingelogde gebruiker af, maar zo’n vers aangeleverd wachtwoord gaat nog gewoon leesbaar door LSASS. Van Kerberos is alleen de TGT beschermd, niet de service-tickets, dus Kerberoasting blijft mogelijk. Keyloggers en fysieke aanvallen vallen er ook buiten, en het stopt een aanvaller niet die de rechten van een al ingelogde sessie misbruikt.

Voor de lokale accounts die Credential Guard niet dekt zet je LAPS in. Dat geeft elke machine een eigen lokaal admin-wachtwoord, zodat een lokale hash nergens anders werkt.

Wanneer staat het aan?

Vanaf Windows 11 22H2 en Windows Server 2025 staat Credential Guard standaard aan op domain-joined systemen die geen domain controller zijn en aan de hardware-eisen voldoen. Die standaard-inschakeling gebeurt zonder UEFI-lock, zodat je het op afstand kunt uitzetten. Was het voor de upgrade expliciet uitgezet, dan blijft het uit.

Voorwaarde is VBS plus Secure Boot, en een Enterprise- of Education-editie. Op Windows Pro werkt het niet. Een TPM en een UEFI-lock zijn aanbevolen, niet verplicht. Microsoft raadt af om het op domain controllers of Exchange-servers te zetten, omdat het daar geen extra veiligheid biedt en problemen kan geven.

Of het echt draait, controleer je met msinfo32.exe. Onder System Summary hoort bij “Virtualization-based Security Services Running” de waarde “Credential Guard” te staan. Met PowerShell kan het ook:

# Draait Credential Guard? Waarde 1 in de array betekent ja (2 = HVCI)
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Credential Guard en aanvallers

Met Credential Guard aan levert het dumpen van LSASS met Mimikatz de beschermde hashes en tickets niet meer op. Voor die accounts is dat pad dicht. Maar een pentester houdt genoeg over. De lokale SAM is nog uit te lezen, cached domein-credentials staan nog in het register, en op een domain controller is de hele NTDS.dit met een DCSync uit te lezen. NTLM-relay heeft de hash helemaal niet nodig, want daar gebruik je de authenticatie zonder hem ooit te lezen. En credentials die net zijn ingetypt zitten nog gewoon in LSASS.

Credential Guard is dus geen complete oplossing op zichzelf. Het sluit één belangrijk pad af, het uitlezen van domein-credentials uit het geheugen. Combineer het met LAPS voor de lokale accounts en met een tiering-model dat beheeraccounts weghoudt van gewone werkstations.