Mimikatz Detection and Defense: How to Prevent and Detect Credential Dumping on Windows
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Mimikatz defense is a layered problem because the tool has multiple attack modes, and defenders often focus on blocking one while leaving others open. Credential Guard stops sekurlsa (LSASS memory reading) but does not stop DCSync. RunAsPPL stops some Mimikatz modules but not all, and advanced Mimikatz variants include kernel driver loading to bypass PPL. This guide covers the full defensive stack -- prevention controls, detection events, and behavioral indicators -- so you can assess coverage gaps in your environment.
Credential Guard: The Most Effective Prevention
Windows Credential Guard uses Virtualization Based Security (VBS) to store NTLM hashes and Kerberos tickets in an isolated hypervisor process (LSAIso) that the main OS -- and therefore Mimikatz -- cannot access. When Credential Guard is enabled, sekurlsa::logonpasswords fails to extract useful hashes from LSASS because the credentials are not present in the main LSASS process memory. Requirements: UEFI Secure Boot enabled, TPM 2.0, 64-bit Windows 10/11 or Windows Server 2019+, Hyper-V hypervisor layer. Enable via GPO: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security = Enabled. Set Credential Guard Configuration to 'Enabled with UEFI lock' for the strongest protection (UEFI lock prevents disabling via software -- requires physical machine access to remove). After enabling, verify: Get-ComputerInfo | Select-Object -ExpandProperty DeviceGuardVirtualizationBasedSecurityStatus should return 'Running'. Note: Credential Guard does not protect against DCSync (which dumps credentials from AD replication, not LSASS), pass-the-hash with existing hashes, or skeleton key attacks.
LSASS RunAsPPL: A Complementary Layer
Running LSASS as a Protected Process Light (PPL) requires that any process opening a handle to LSASS must itself be a signed Microsoft binary -- Mimikatz.exe (unsigned) is blocked. Enable via GPO: Computer Configuration > Windows Settings > Security Settings > Security Options > LSASS RunAsPPL = Enabled. Or via registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1 (requires reboot). Limitations: PPL can be bypassed by Mimikatz via the mimidrv.sys kernel driver (which is signed but abusable), or by loading a vulnerable driver (Bring Your Own Vulnerable Driver, BYOVD) to disable PPL at the kernel level. RunAsPPL is not a complete defense on its own -- it raises the bar for commodity tools but sophisticated attackers have bypasses. Use it alongside Credential Guard, not instead of it.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect LSASS Memory Access via Sysmon and Audit
Sysmon Event ID 10 (ProcessAccess) fires when a process opens a handle to another process with a rights mask that allows reading memory. Configure Sysmon to capture LSASS access: in the Sysmon configuration XML, include a ProcessAccess rule for TargetImage ending in lsass.exe with GrantedAccess including 0x10 (VM_READ) or 0x1FFFFF (PROCESS_ALL_ACCESS). Sysmon Event 10 will alert on any non-Windows process attempting to read LSASS memory -- this includes Mimikatz, ProcDump (used to dump LSASS to a .dmp file for offline parsing), Task Manager LSASS dump, and other credential tools. Common false positives: EDR agents (they legitimately access LSASS), AV engines, some backup agents. Baseline the expected processes that access LSASS in your environment and alert on everything else. Windows Audit: Event ID 4656 (handle to an object requested) filtered for ProcessName=lsass.exe and AccessMask including 0x10 or 0x1F0FFF also captures LSASS access attempts.
Detect DCSync via Event ID 4662 and Unusual Replication
DCSync does not touch LSASS -- it uses the Directory Replication Service (DRS) protocol to request AD credential replication from a DC, as if the requesting machine were another DC. This bypasses Credential Guard and RunAsPPL entirely. Detection: Event ID 4662 on domain controllers fires when an object's properties are accessed, including directory replication. DCSync generates Event ID 4662 with Object Type 'controlAccessRight' and Access Mask including 'DS-Replication-Get-Changes' and 'DS-Replication-Get-Changes-All'. KQL in Sentinel: SecurityEvent | where EventID == 4662 and AccountType == 'User' and Properties contains '1131f70...' (the DS-Replication GUIDs). Alert when any non-DC account triggers these replication rights -- legitimate DC-to-DC replication comes from machine accounts (ending in $), not user accounts. Microsoft Defender for Identity (MDI) has a built-in alert for DCSync from non-DC machines and is the easiest way to detect this attack.
Detect Mimikatz Behavioral Indicators in Your EDR
Modern EDR products detect Mimikatz through behavioral patterns rather than static signatures (since Mimikatz variants are constantly obfuscated to evade signatures). Behavioral indicators that high-quality EDRs detect: in-memory loading of known credential harvesting modules (sekurlsa, kerberos, lsadump loaded into a process that is not LSASS), LSASS memory read from unexpected parent processes, privilege escalation to SeDebugPrivilege followed by LSASS access (SeDebugPrivilege is required for LSASS reading and should be restricted to only specific admin accounts -- Event ID 4674 fires when SeDebugPrivilege is used), and WDigest registry modification (Mimikatz uses lsadump::wdigest to re-enable plaintext password caching -- Monitor HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential for any value other than 0). Configure your EDR alert thresholds for all of these indicators at highest priority.
The bottom line
No single control fully blocks Mimikatz across all its attack modes. The effective defense is: Credential Guard (blocks LSASS credential access for most Mimikatz users), Sysmon Event ID 10 for LSASS access detection, Event ID 4662 for DCSync detection, EDR behavioral rules for in-memory credential tool patterns, and WDigest hardening to prevent re-enabling plaintext credential caching. Implement all of these; relying on only one creates bypasses. Credential Guard combined with MDI DCSync alerting covers the two highest-value Mimikatz paths.
Frequently asked questions
Does antivirus detect Mimikatz?
Standard Mimikatz binary is detected by most antivirus products via signature. However, attackers almost never use the unmodified Mimikatz binary in a real intrusion -- they use obfuscated versions, in-memory execution (loading Mimikatz modules directly into memory without writing a file to disk), or post-exploitation frameworks like Cobalt Strike that include Mimikatz functionality built in and obfuscated differently per build. AV signature detection of Mimikatz catches only the most unsophisticated use. Behavioral detection (EDR process access monitoring, Sysmon Event 10, Event ID 4662) is the reliable detection layer.
Can Mimikatz be run without being a local administrator?
Most Mimikatz functions (sekurlsa::logonpasswords, lsadump::dcsync) require local administrator rights or Domain Admin rights. SeDebugPrivilege (required for LSASS memory access) is only available to local administrators by default. Some specific Mimikatz modules operate on credential material the current user already owns (like the Kerberos ticket cache via kerberos::list) without admin rights. The general rule: effective Mimikatz use requires admin rights on the local system or domain-level replication rights for DCSync.
What is the WDigest protocol and why does Mimikatz enable it?
WDigest is an authentication protocol that stores credentials in plaintext in LSASS memory for use with HTTP Digest authentication. It was disabled by default starting with Windows 8.1 and Windows Server 2012 R2. When Mimikatz encounters a system with WDigest disabled, sekurlsa::logonpasswords returns NTLM hashes but not plaintext passwords. To get plaintext passwords, an attacker can re-enable WDigest by setting UseLogonCredential=1 in the registry, wait for a new login to populate the cache, and then dump credentials again. Monitor this registry key for any change to a non-zero value: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential.
Does Credential Guard affect legacy applications or Kerberos authentication?
Yes, with some compatibility caveats. Credential Guard prevents NTLM authentication for domain accounts (since hashes are isolated in LSAIso), which can break legacy applications that rely on NTLM authentication rather than Kerberos. Check compatibility before enabling: applications using NTLMv1, Digest authentication, and MS-CHAPv2 may fail. For Kerberos authentication, Credential Guard protects the TGT but does not prevent Kerberoasting (TGS requests from an authenticated user) or other Kerberos-based attacks. Run the Device Guard and Credential Guard hardware readiness tool from Microsoft to assess compatibility before deployment.
What is the DCSync attack and how do I detect it without using Defender for Identity?
DCSync abuses the DS-Replication-Get-Changes-All and DS-Replication-Get-Changes directory service permissions to request password hash data from a DC as if the requesting system were another DC. An attacker with these rights (Domain Admin, Enterprise Admin, or any account explicitly granted them) can run Mimikatz lsadump::dcsync and retrieve NTLM hashes and Kerberos keys for any account without touching LSASS memory. Detection without MDI: monitor Event ID 4662 on DCs for accesses involving the DS-Replication-Get-Changes-All GUID (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) where the subject account is not a domain controller. Any non-DC account triggering this GUID is performing DCSync. Configure object access auditing on the domain object in Active Directory Users and Computers to generate 4662 events.
What defenses specifically block Mimikatz's sekurlsa::logonpasswords command and why is LSASS protection the first priority?
sekurlsa::logonpasswords reads credential material cached in LSASS memory, including NTLM hashes, Kerberos tickets, and WDigest plaintext passwords (on pre-Windows 8.1 or when WDigest is manually re-enabled). Primary defenses: enable LSASS Protected Process Light (PPL) via RunAsPPL, which prevents unprivileged reads of LSASS memory and requires a signed, Microsoft-approved driver to attach a debugger. Enable Credential Guard (where hardware supports it), which moves credential material into a Hyper-V-isolated container that Mimikatz cannot reach even with kernel-level access. Disable WDigest authentication (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest, set UseLogonCredential=0) -- this stops plaintext password caching for Windows 8.1 and later, though NTLM hashes remain accessible. Windows Defender Credential Guard is the strongest control: even a compromised kernel cannot extract Credential Guard-protected credentials because they never enter the normal OS memory space. Mimikatz detects Credential Guard and reports that credential extraction is blocked rather than returning hash values.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.