What Mimikatz reaches, and the hardening that makes it not matter

You find it in the Sysmon logs after the fact: a process that is not your EDR opened lsass.exe with a read handle. Or the WDigest registry value is back to 1 on a server nobody admits touching. The dump has already happened. The only questions left are what the account it ran as could reach, and whether any of it mattered.

Mimikatz is more than a decade old and still works, because the thing it abuses — the Local Security Authority Subsystem Service (LSASS) keeping credentials in memory so users do not re-authenticate for every resource — is single sign-on, a feature you cannot uninstall. So defending against it is never one setting. It is making a successful credential dump worthless.

What it actually reaches

Mimikatz reads LSASS memory to extract NTLM hashes, Kerberos tickets, and — on unhardened hosts — cleartext passwords cached by WDigest. But several of its most damaging modes never touch LSASS at all. DCSync asks a domain controller to replicate password hashes over the directory-replication protocol, as if the attacker were another DC. Pass-the-hash and pass-the-ticket reuse stolen material without ever recovering the password. Each needs a different defence, which is why "just patch it" was never a coherent plan.

Why the one-click fixes get rolled back

Two settings get recommended everywhere and then quietly reverted in production, because nobody tested what they break.

WDigest — necessary, not sufficient

On Windows 8.1 / Server 2012 R2 and later, WDigest cleartext caching is off by default: the value is absent or 0. An attacker re-enables it by setting it to 1, then waits for the next interactive logon — it does not expose already-cached sessions retroactively. (On older systems the same fix arrived via update KB2871997.) Set it explicitly to 0 and monitor the key for changes.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
UseLogonCredential = 0   (DWORD)

But this closes one door in a building full of them: on a host without further protection, NTLM hashes and Kerberos tickets still sit in LSASS regardless of WDigest.

LSA Protection and Credential Guard — the part that breaks things

LSA Protection (RunAsPPL) makes lsass.exe a Protected Process Light, so a process at a lower protection level — even one running as SYSTEM — can no longer open its memory for reading through the normal APIs. It does not stop kernel-level access or an abused signed driver; Mimikatz ships a driver for exactly that, which is why PPL raises the bar rather than closing the door.

Credential Guard goes further, using virtualization-based security to move domain-derived secrets — NTLM password hashes and Kerberos TGTs — into an isolated process (lsaiso.exe) that the normal Windows kernel cannot read; the ordinary LSA talks to the isolated one instead of holding the secrets itself. It needs virtualization-based security (64-bit CPU virtualization with SLAT), and is strengthened by UEFI and Secure Boot. It does not protect local accounts in the SAM, or a plaintext password captured at the point of entry by a keylogger or a malicious credential provider. Both controls stop the standard user-mode memory dump; neither is a guarantee against kernel- or driver-level theft.

Both also break real things. Smartcard middleware, some VPN and SSO agents, and third-party authentication or security-support providers that load into LSASS stop working under RunAsPPL; Credential Guard can conflict with some third-party drivers and nested-virtualization setups. Enable either blindly and you will get a ticket from whoever runs the one undocumented app that authenticates through LSASS.

Defaults have shifted, but unevenly. Credential Guard is enabled by default on eligible Windows 11 22H2 and later Enterprise devices; LSA Protection is default-on for qualifying new, enterprise-joined 22H2 installations; and Windows Server 2025 adds server-side defaults. An estate that was upgraded rather than reinstalled, or that is not enterprise-joined, usually has neither — assume both are off until you verify, and turning them on without auditing first is how you cause the outage you were trying to prevent.

The order we deploy in

The sequence that hardens without the rollback:

• •Audit first. Enable LSASS plug-in compatibility auditing (the AuditLevel value under Image File Execution Options for lsass.exe; incompatibilities surface in the CodeIntegrity/Operational log) and run Credential Guard's hardware-readiness check. Fix what would break before enforcing anything.
• •Disable WDigest cleartext (UseLogonCredential = 0) and monitor the key for re-enablement.
• •Enforce RunAsPPL once the audit log is clean, then Credential Guard where the hardware supports VBS.
• •Put privileged accounts in the Protected Users group: no NTLM, no Digest, no CredSSP plaintext caching, no new cached (offline) logon, Kerberos restricted to AES with no RC4 or DES, a non-renewable 4-hour TGT, and delegation blocked. The domain-side protections require a Windows Server 2012 R2 domain functional level. Never put service accounts, or any account that must log on when a DC is unreachable, into it.
• •Deploy Windows LAPS to manage the machine's designated local Administrator password — unique per machine and rotated — so that account's hash is useless anywhere else.
• •Tier the estate — the control that actually decides the outcome, below.

# enforce LSA Protection
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
RunAsPPL = 1        (DWORD; 2 = enable without the UEFI variable, newer builds)

# compatibility AUDIT mode first (this is NOT RunAsPPL=2)
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe
AuditLevel = 8      (DWORD)

Tiering: why a successful dump stops mattering

Every control above raises the cost of dumping credentials. Tiering caps the damage when it happens anyway. Split the estate into tiers — Tier 0 (domain controllers, AD, anything that controls identity), Tier 1 (member servers and their applications), Tier 2 (user workstations) — and enforce a single rule: a credential from a higher tier is never entered or cached on a lower-tier machine. A Domain Admin never signs into a helpdesk workstation; a workstation admin never logs on to a domain controller.

The payoff is what happens on the day Mimikatz runs on a Tier-2 workstation, because eventually it will. What it can harvest there — that workstation's own users, its machine account, the tokens and tickets present on the box — cannot administer a server, let alone a domain controller. The blast radius is one tier, not the domain: the dump is contained rather than catastrophic. That is the assume-breach posture, and it is the hardest thing here to retrofit, because it is organisational rather than a registry value — which is exactly why it is where the real work lives.

Detecting the dump you did not prevent

Prevention is never complete, so instrument for the attempt. A high-signal source is Sysmon Event ID 10 (ProcessAccess): alert on a process opening lsass.exe with a read-capable access mask. Masks that include PROCESS_VM_READ often appear as 0x1010, 0x1410 or 0x143a, but those values are not unique to any one tool — the durable signal is a non-allowlisted process taking a readable handle to LSASS, not a specific number. Note that kernel-mode acquisition, handle duplication and snapshot/minidump techniques may not produce this pattern at all.

<!-- Sysmon config: log access to LSASS -->
<ProcessAccess onmatch="include">
  <TargetImage condition="is">C:\Windows\System32\lsass.exe</TargetImage>
</ProcessAccess>
<!-- then alert on any source that is not on your allowlist -->

This rule is noisy before it is useful. Legitimate security tools read LSASS constantly. Allowlist them by validated signer and file hash — not by path alone, which can be spoofed — and baseline for a week before you alert, or you will teach the SOC to ignore the one event that matters.

Layer the rest on top: Microsoft Defender's Attack Surface Reduction rule "Block credential stealing from the Windows local security authority subsystem (lsass.exe)", in audit mode first; process-creation logging (Event 4688) with command lines; and, for DCSync, Directory Service Access auditing with a SACL on the domain object, alerting on Event 4662 that references the replication control-access rights. Fire on any principal or source host outside an explicit allowlist — a few sync, backup or migration products legitimately hold these rights, so "not a domain controller" is too blunt — and correlate 4662 with authentication and network telemetry, since it names the principal but not the originating host.

# DCSync abuses these control-access rights (watch for them in Event 4662):
DS-Replication-Get-Changes            1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
DS-Replication-Get-Changes-All        1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
DS-Replication-Get-Changes-In-Filtered-Set  89e95b76-444d-4c62-991a-0facbeda640c

What "we fought it" actually means

The honest version: there is no fighting Mimikatz in the moment it runs with sufficient privilege on an unhardened host — it reads memory that, without LSA Protection or Credential Guard in the way, the system lets a high-privilege process read. The fight is everything around that moment: closing WDigest, protecting and isolating LSASS, and above all tiering, so the credentials the tool can reach are worthless. When we are called in after a dump, the first question is never "how do we remove the tool." It is what every session and secret on that host could reach, and the remediation is rebuilding the tiering that let it reach too far.

If a Windows estate has grown for a decade with no tiering model — Domain Admins used on workstations, one local-admin password everywhere, WDigest never touched — that is the finding, and it is the same class of operational debt as what an Active Directory audit turns up. We remediate both in the same engagement.