Mimikatz vs. Credential Guard
I started writing a post about Credential Guard. Then I started testing Mimikatz in a lab to see what Credential Guard actually stops. Then I fell down a rabbit hole and this turned into something bigger than I planned.
So here's the deal: I'm going to show you what Mimikatz does to an unprotected domain controller, then show you how Credential Guard shuts it down, and then tell you about all the stuff that breaks when you flip the switch. Because nobody warns you about that last part until it's too late.
The attack: what Mimikatz actually does
So Mimikatz. Benjamin Delpy wrote it in 2011 as a research project. He found a flaw in how Windows handles authentication and tried to report it to Microsoft. They blew him off. So he published the tool instead. It's been used in basically every major Windows credential theft since, including NotPetya and Bad Rabbit.
What makes it dangerous is simple: Windows caches credential hashes in LSASS memory so you don't have to type your password every time you touch a network resource. Mimikatz reads those hashes straight out of memory. You don't need to crack anything. You grab the hash and pass it along to authenticate as that user. That's pass-the-hash. For Kerberos tickets, same idea, different protocol: that's pass-the-ticket.
Older Windows versions (pre-10) also had WDigest enabled by default, which stored credentials in a way that Mimikatz could pull plaintext passwords. Not hashes. Actual passwords. Microsoft disabled WDigest by default starting with Windows 10, but it's still there. An attacker with admin access can turn it back on with a registry key and wait for someone to log in.
And yes, I've seen WDigest still enabled at client sites in 2024. On servers running applications that "require" it. Nobody remembers why.
Setting up the lab
I spun up a Windows Server 2022 DC in Hyper-V for this. Before you can run Mimikatz you need to disable Defender, because obviously it flags the binary immediately. Don't do this on anything resembling a production box. This is a sandboxed lab VM.
Disable Real-time protection, Cloud-delivered protection, and Automatic sample submission:
You also need to disable IE Enhanced Security Configuration on Server, or you can't even browse to GitHub to download the thing.
Grab the pre-compiled binaries from the ParrotSec repo on GitHub. (I'd link it directly, but Blogger actually delists posts that contain the URL. I found that out the hard way. Just Google "ParrotSec Mimikatz GitHub.")
Running Mimikatz
Run mimikatz.exe as administrator, even if you're already on an admin account. It needs the elevated token. You'll get the interactive console:
Check your version first. There's a 32-bit and 64-bit build; use the right one for your OS or things will just silently fail.
Type :: to list available modules. You'll get an error message about "module not found" which is normal, it's just how Mimikatz lists things.
First, get debug privileges and start logging:
log mimikatz_output.log
From here, the modules that matter most are:
- sekurlsa - this is the big one. Dumps password data from LSASS for currently and recently logged-on accounts, service accounts, the works. If someone's authenticated on that box, sekurlsa gets their hashes.
- lsadump - pulls credentials from the Local Security Authority, including the krbtgt hash (which is how you make Golden Tickets)
- kerberos - ticket-granting tickets
- vault - saved passwords for servers and websites. The Windows Credential Vault. People forget this one exists, which is exactly the problem.
I'm not going to walk through every module in detail here. The point isn't to write a Mimikatz tutorial. The point is: if an attacker gets admin on one machine in your domain, they can extract credentials for every account that's logged into that machine. And with the krbtgt hash, they can forge tickets for any account in the domain. That's the problem we're solving.
The defense: Credential Guard
Credential Guard is Microsoft's answer to this whole class of attacks. Instead of keeping credential hashes in LSASS where any admin-level process can read them, it moves the secrets into an isolated virtual machine running alongside your OS.
The hypervisor creates a separate kernel (LSAIso, "LSA Isolated") with a higher trust level than your main OS. Your regular LSASS process still exists, but it doesn't hold the actual secrets anymore. It talks to LSAIso over RPC when it needs to do authentication work. Mimikatz can dump LSASS all day, but the hashes aren't there.
I genuinely think this is one of the most underused security features in Windows. It's been around since Windows 10 and Server 2016. Most enterprises I've worked with don't have it turned on.
What you need before you can enable it
Hardware requirements:
- 64-bit Windows 10/11 or Server 2016+
- UEFI with Secure Boot
- CPU virtualization extensions (Intel VT-x or AMD-V) with SLAT
- TPM 1.2 or 2.0
Most hardware from the last 8 years meets these requirements. Microsoft has a PowerShell readiness tool that checks for you.
The gotcha isn't usually hardware. It's the stuff that breaks when you turn it on.
What breaks (and how to avoid outages)
This is the section nobody reads until they're on a bridge call at 11 PM.
When you enable Credential Guard, single sign-on stops working for anything that uses these protocols:
- NTLMv1 - if you still have anything using NTLMv1, you have bigger problems, but it will break
- MS-CHAPv2 - common in older VPN and Wi-Fi configurations
- Digest authentication
- CredSSP - and this one bites people. CredSSP is how Remote Desktop passes credentials to the remote machine for SSO. If your admins RDP into servers and expect to access network shares from there without re-authenticating, that stops working.
It also kills unconstrained Kerberos delegation and DES encryption. If you've got legacy apps that use unconstrained delegation (and a lot of enterprises do, often without realizing it), those break too.
Users won't lose access. They'll just get prompted to enter their password again for things that used to be seamless. Which means your helpdesk gets flooded with "something's wrong with my login" tickets if you don't communicate the change.
My recommendation: enable it without UEFI lock first. Test for a few weeks. If something critical breaks, you can back it out with a GPO change. If you enable with UEFI lock and something goes wrong, you're physically touching every affected machine to undo it.
I learned that one the hard way at a previous client. Rolled Credential Guard with UEFI lock to a pilot group of about 40 machines, didn't realize their legacy payroll app used CredSSP under the hood. Monday morning the entire finance department couldn't access it. I spent two days driving between offices with a USB stick to disable VBS from the firmware menu on each machine individually. Anyways, start without the lock.
Enabling with Intune
Navigate to Devices > Configuration Profiles > + Create profile. Select Windows 10 and later as the platform, then pick the Endpoint Protection template.
You get four options for Credential Guard:
- Deactivated
- Enabled with UEFI lock (permanent until physically reversed)
- Not configured
- Enabled without lock (reversible via policy, this is what you want for initial rollout)
The UEFI lock thing is worth repeating: if you enable with UEFI lock and need to turn it off, you can't do it remotely. You need physical access or console access to each machine. For an initial deployment, always start without the lock.
Enabling with Group Policy
The GPO setting lives under:
Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization-Based Security
Same four options as Intune. Same advice: start without UEFI lock.
Verifying it's working
After the policy applies, run msinfo32.exe on the target machine. You should see Credential Guard listed under Virtualization-based security services.
You can also check if the LsaIso process is running, but that process shows up whenever any VBS feature is active, not just Credential Guard. So msinfo32 is the reliable check.
VMs too
Credential Guard works in Hyper-V guests, but only Generation 2 VMs with Secure Boot and a virtual TPM enabled. Check that your VM security settings don't have VBS opted out:
# If VirtualizationBasedSecurityOptOut is $true, fix it:
Set-VMSecurity -VMName "YourVM" -VirtualizationBasedSecurityOptOut $false
After that, same GPO or Intune profile as physical machines.
The other stuff you should do anyway
Credential Guard is great, but it's not the whole story. A few things I always recommend alongside it:
- Use LAPS (Local Administrator Password Solution) so every machine has a unique local admin password. Shared admin passwords across machines is how a single Mimikatz dump turns into full domain compromise.
- Restrict who can log into what. If a domain admin logs into a workstation and that workstation gets compromised, their cached credentials are now available. Tiered admin accounts help here.
- Disable WDigest explicitly on anything older than Windows 10. It's a registry key:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredentialset to 0. - Enable LSA protection (RunAsPPL) as an additional layer. It's not as strong as Credential Guard, but it blocks unsigned processes from reading LSASS.
You get the idea. None of these are hard to do, they're just easy to forget about until after something goes wrong.
