Mimikatz credential dumping: detect and stop it

1. LSASS isn't protected — Mimikatz reads memory directly

The most common reason Mimikatz works is that LSASS (Local Security Authority Subsystem Service) is left wide open. By default, any process running as SYSTEM or with SeDebugPrivilege can open LSASS and read its memory. Mimikatz uses sekurlsa::logonpasswords to dump plaintext passwords and hashes from there.

Real-world trigger: A user runs a downloaded tool that's actually Mimikatz, or an attacker drops it after phishing. You'll see event ID 4663 — "An attempt was made to access an object" — with LSASS as the object and a non-standard process doing it.

How to detect it

Enable auditing for LSASS process access. GPO: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy > Detailed Tracking > Audit Process Creation — set to Success + Failure. Then watch event ID 4688 (process creation) and 4663 (object access).

Run this PowerShell to check if LSASS protection is already on:

Get-WmiObject -Class Win32_Service -Filter "Name='LSASS'" | Select-Object Name, PathName, StartMode

If you don't see RunAsPPL in the path, it's not protected.

The fix: Enable LSASS RunAsPPL

This forces LSASS to run as a Protected Process Light (PPL). Only processes signed by Microsoft can access it. Mimikatz can't open the handle.

Open Registry Editor as admin.
Go to HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
Create DWORD RunAsPPL and set it to 1.
Reboot.

Alternatively, use Group Policy: Computer Configuration > Administrative Templates > MS Security Guide > Turn on Virtualization Based Security. Set to Enabled, then choose "Enabled with UEFI lock" if your hardware supports it. Reboot twice.

One catch: This breaks some legacy software that hooks LSASS. Test in a pilot group first. But for 95% of orgs, it's a drop-in fix.

2. WDigest is still enabled — storing plaintext passwords

Second biggest culprit. WDigest is a legacy authentication protocol that caches your plaintext password in LSASS memory. Windows 8.1/Server 2012 R2 and newer disable it by default. But older systems — or systems upgraded from older ones — often have it still on. Mimikatz dumps those passwords directly.

Real-world scenario: You have a 2012 R2 file server that was upgraded from 2008 R2. WDigest remained enabled. Attacker gets a foothold via SMB exploit, runs Mimikatz, and grabs the domain admin's cached password.

Check and disable WDigest

Check the registry:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name UseLogonCredential

If UseLogonCredential is 1 or doesn't exist, it's enabled. Fix it:

Open Registry Editor.
Go to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest.
Set DWORD UseLogonCredential to 0.
If it doesn't exist, create it.

Then push this via GPO to every domain-joined machine. Don't skip servers. I've seen domain controllers with WDigest still on after a decade of upgrades.

After disabling, any existing cached passwords stay until the user logs off or the system reboots. Force a reboot to clear them.

3. Credential Guard isn't deployed — virtualization-based protection missing

The third fix is the nuclear option: Credential Guard. It uses virtualization-based security to isolate LSASS in a separate VM partition. Even if you get admin rights on the host, you can't read LSASS memory from the guest partition. Mimikatz can't dump what it can't see.

This requires a few things: Windows 10 Enterprise or Education (not Pro), or Windows Server 2016+. Also needs hardware virtualization (VT-x/AMD-V), Secure Boot, and UEFI.

Real-world trigger: The attacker already bypassed RunAsPPL by installing a malicious driver that mimics a Microsoft-signed kernel module. That's rare but happens. Credential Guard stops it cold.

Enable Credential Guard

Group Policy route:

GPO: Computer Configuration > Administrative Templates > System > Device Guard.
Enable "Turn on Virtualization Based Security".
Set "Select Platform Security Level" to "Secure Boot and DMA Protection" if your hardware supports it.
Set "Credential Guard Configuration" to "Enabled with UEFI lock".
Reboot twice.

PowerShell route (easier for a few machines):

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Services, Microsoft-Hyper-V, Microsoft-Hyper-V-Management-PowerShell
bcdedit /set hypervisorlaunchtype auto
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSASS-CCA
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device path \EFI\Microsoft\Boot\SecConfig.efi
bcdedit /set vm {0cb3b571-2f2e-4343-a879-d86a476d7215} enforce

Yeah, that's ugly. The GPO method is cleaner for deployments.

What Credential Guard breaks: Anything that uses Kerberos delegation or requires reading LSASS memory. That includes some backup agents, password managers, and remote management tools. Test thoroughly. You might need to exempt certain servers.

Quick-reference summary table

Fix	What it stops	Effort	Compatibility risk
Enable LSASS RunAsPPL	Direct memory reads from LSASS	Low — registry change	Low — breaks legacy LSASS hooks
Disable WDigest	Plaintext password caching in LSASS	Low — registry or GPO	Very low — WDigest is obsolete
Enable Credential Guard	Full memory isolation via virtualization	High — HW requirements + testing	Moderate — breaks delegation tools

Start with RunAsPPL and WDigest disable. That stops 99% of Mimikatz attacks I've seen. Only break out Credential Guard if you're paranoid and have the infrastructure for it.

One last thing: combine with a proper endpoint detection tool (Microsoft Defender for Endpoint, CrowdStrike, SentinelOne). They'll catch Mimikatz dropping on disk or running suspicious LSASS access calls. But don't rely on detection alone — these three fixes prevent the dump from working in the first place.