Listen to this Post
Introduction:
When an attacker compromises a single Windows machine, the real damage isn’t limited to that host—it’s the credentials stored in memory that become the golden ticket for lateral movement. LSASS (Local Security Authority Subsystem Service) caches NTLM hashes, Kerberos tickets, and sometimes plaintext passwords, and tools like Mimikatz can extract these artifacts if administrative privileges are obtained, turning one foothold into a network-wide disaster.
Learning Objectives:
- Understand how Mimikatz extracts credential material from LSASS memory and how attackers use it to pivot across the network.
- Implement defensive controls including LSA Protection, Credential Guard, and WDigest disablement to block credential dumping.
- Learn detection techniques using Sysmon and PowerShell to monitor LSASS access and respond to compromise attempts.
- How LSASS Credential Dumping Works (Mimikatz in Action)
Credential dumping targets the LSASS process because Windows stores authentication data there to support single sign-on, Kerberos, and NTLM authentication. When a user logs on—interactively or via network—their credentials remain in LSASS memory until the session ends. Mimikatz reads that memory using the `sekurlsa::logonpasswords` module after elevating to `DEBUG` mode.
Step-by-step explanation of what this does and how attackers use it:
– Attacker gains administrator privileges on a compromised host (e.g., via privilege escalation or phished admin creds).
– They run Mimikatz with `privilege::debug` to enable SeDebugPrivilege, required to access LSASS.
– The command `sekurlsa::logonpasswords` extracts all available authentication packages: NTLM hashes, Kerberos tickets (TGTs and service tickets), and if WDigest is enabled, plaintext passwords.
– Extracted hashes can be used in Pass-the-Hash attacks; Kerberos tickets enable Pass-the-Ticket; plaintext passwords allow direct logins.
Windows commands to simulate (for authorized testing only):
Download Mimikatz (authorized lab only) Invoke-WebRequest -Uri "https://github.com/gentilkiwi/mimikatz/releases/latest/download/mimikatz_trunk.zip" -OutFile "mimikatz.zip" Expand-Archive -Path "mimikatz.zip" -DestinationPath "C:\mimikatz" Run Mimikatz (admin PowerShell) cd C:\mimikatz .\mimikatz.exe privilege::debug sekurlsa::logonpasswords
Defensive equivalent: Use PowerShell to list LSASS access attempts (Event ID 4656 from Sysmon) or restrict who can open handles to LSASS.
2. Enabling LSA Protection (RunAsPPL) to Block Mimikatz
LSA Protection (RunAsPPL – Protected Process Light) prevents non-protected processes from opening LSASS for read access. Mimikatz cannot dump LSASS memory when this is enabled because the operating system blocks handle requests from untrusted processes.
Step-by-step guide to enable LSA Protection:
1. Open Registry Editor (regedit) as administrator.
2. Navigate to: `HKLM\SYSTEM\CurrentControlSet\Control\Lsa`
- Create or modify DWORD value: `RunAsPPL` = `0x00000001`
4. For additional protection, set `RunAsPPLBoot` = `0x00000002` (requires UEFI Secure Boot).
5. Reboot the system.
Verification commands:
Check if RunAsPPL is enabled Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" List protected processes (lsass.exe should show "PPL" status) Get-Process -Name lsass | Select-Object -Property ProcessName, Protection
Limitation: Mimikatz can still use the `mimikatz!` driver or reboot into safe mode if physical access exists, but for remote attacks, LSA Protection is highly effective.
3. Deploying Credential Guard for Virtualization-Based Security
Credential Guard uses hardware virtualization to isolate LSASS in a secure environment that the OS kernel cannot directly access. Even with administrative privileges, tools like Mimikatz see only dummy data because the real credentials live in a separate VTL (Virtual Trust Level).
Step-by-step guide to enable Credential Guard:
- Requirements: UEFI firmware, Virtualization Extensions (VT-x/AMD-V), TPM 2.0 recommended, Windows 10/11 Enterprise or Education.
- Method 1 – Using Group Policy:
- Open `gpedit.msc` → Computer Configuration → Administrative Templates → System → Device Guard.
- Enable “Turn On Virtualization Based Security” → Set “Credential Guard Configuration” to “Enabled with UEFI lock”.
- Method 2 – PowerShell:
Check if Credential Guard is supported Get-ComputerInfo -Property "DeviceGuard" Enable (requires reboot) $path = "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" New-Item -Path $path -Force New-ItemProperty -Path $path -Name "EnableVirtualizationBasedSecurity" -Value 1 -PropertyType DWord -Force New-ItemProperty -Path $path -Name "RequirePlatformSecurityFeatures" -Value 1 -PropertyType DWord -Force New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 1 -PropertyType DWord -Force
Verification: Run `msinfo32.exe` → System Summary → “Virtualization-based security services running” should show “Credential Guard”.
4. Disabling WDigest to Prevent Plaintext Password Caching
WDigest is a legacy authentication protocol that caches plaintext passwords in LSASS memory. By default, it is disabled on Windows 8.1/2012 R2 and later, but older systems or misconfigured images may have it enabled. Disabling WDigest eliminates the risk of plaintext credential extraction.
Step-by-step guide:
1. Registry path: `HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest`
2. Create DWORD value: `UseLogonCredential` = `0`
- Reboot (or restart the WDigest service via `net stop WDigest` followed by
net start WDigest, but reboot is safer).
Command to check current status:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name "UseLogonCredential" -ErrorAction SilentlyContinue
Impact: Applications that rely on WDigest (very rare) may break; in modern Active Directory environments, this change is harmless and strongly recommended.
5. Detecting LSASS Access Attempts (Credential Dumping Detection)
Monitoring for processes that open a handle to LSASS with read access is crucial. Attackers may use not only Mimikatz but also PowerShell with `Get-Process` + `MiniDumpWriteDump` or tools like ProcDump. Use Sysmon and Windows Event Logging to catch these behaviors.
Step-by-step guide to configure detection:
- Install Sysmon (if not already): Download from Microsoft, run
sysmon64 -accepteula -i sysmonconfig.xml. - Enable ProcessAccess events (Event ID 10): Add this rule to your Sysmon config:
<Sysmon> <EventFiltering> <ProcessAccess onmatch="exclude"> <TargetImage condition="end with">lsass.exe</TargetImage> <SourceImage condition="is">C:\Windows\System32\svchost.exe</SourceImage> </ProcessAccess> <ProcessAccess onmatch="include"> <TargetImage condition="end with">lsass.exe</TargetImage> <CallTrace condition="contains">dbghelp.dll</CallTrace> </ProcessAccess> </EventFiltering> </Sysmon>
- Enable PowerShell Script Block Logging (to catch in-memory Mimikatz):
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
- Monitor Event IDs: 4656 (Handle to LSASS requested), 4663 (LSASS accessed), and Sysmon 10.
Linux equivalent (for cross-platform awareness): On Linux, credential dumping targets `/etc/shadow` or memory of processes like sshd. Use `auditd` to monitor reads:
auditctl -w /etc/shadow -p r -k credential_access
6. Minimizing Privileged Logons and Securing Jump Boxes
The post emphasizes that impact depends on who has logged into the system. Shared servers, jump boxes, and domain controllers concentrate risk. Implementing Privileged Access Workstations (PAWs) and Just Enough Administration (JEA) reduces credential exposure.
Step-by-step hardening guide:
- Restrict local administrator logons: Use Group Policy → Computer Config → Windows Settings → Security Settings → Local Policies → User Rights Assignment → “Deny log on locally” for privileged accounts except designated PAWs.
- Disable cached logons for jump boxes: Registry `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon` → `CachedLogonsCount` =
0. - Use LAPS (Local Administrator Password Solution) to randomize local admin passwords after each use.
- Deploy Windows Defender Credential Guard (as in section 3) on all jump boxes and tier-0 assets.
Verification command for cached logons:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "CachedLogonsCount"
- Linux Credential Dumping: Extracting from /proc/kcore and SSH Memory
While the original post focuses on Windows, security professionals must understand similar risks in Linux environments. Attackers with root access can extract credentials from running processes (e.g., SSH agent memory, GNOME keyring) or dump the entire kernel memory.
Example command (authorized lab only):
Extract NTLM-like hashes from a Windows domain-joined Linux machine (using Samba) sudo tdbdump /var/lib/samba/private/secrets.tdb | grep -i "password" Dump SSH agent keys cat /proc/$(pgrep ssh-agent)/maps Then use a tool like ssh-grab to extract Mitigation on Linux: - Disable ptrace for non-root: sysctl -w kernel.yama.ptrace_scope=2 - Use auditd to monitor /proc/pid/mem access auditctl -a always,exit -F arch=b64 -S process_vm_readv -k memory_dump
Cross-platform takeaway: The principle remains the same—privileged access to memory equals credential compromise. Defenses include memory isolation (Intel SGX, AMD SEV) and strict process access controls.
What Undercode Say:
- Key Takeaway 1: A single compromised machine with administrative privileges exposes all credentials of every user who has logged into it—making shared servers and jump boxes the highest-value targets for lateral movement.
- Key Takeaway 2: Defensive layers must start with memory protection (LSA Protection, Credential Guard) before detection, because once an attacker runs Mimikatz, the damage is already done. Detection should focus on LSASS handle requests, not just Mimikatz binaries.
Analysis: The post correctly highlights that credential dumping is not a complex exploit but an abuse of legitimate OS functionality. Mimikatz simply reads what Windows already stores. Therefore, the most effective mitigations are architectural: isolate credentials via virtualization (Credential Guard), prevent read access to LSASS (LSA Protection), and eliminate unnecessary credential caching (disable WDigest). Many organizations still rely on antivirus to block Mimikatz.exe, but attackers load it in memory or rename the binary. Defenders must adopt the “assume breach” mindset and focus on reducing credential exposure across the environment, especially on tier-0 assets like domain controllers and jump boxes. The provided references (LSA Protection, Credential Guard, WDigest disablement, and detection) form a practical, actionable baseline.
Prediction:
As credential dumping techniques evolve, Microsoft will likely deprecate LSASS as an authentication broker in favor of hardware-backed isolation (Pluton, TPM 2.0 with key attestation). Within two years, default Windows installations will enable Credential Guard on all compatible hardware, rendering Mimikatz useless for remote attackers. However, Linux environments will become the next major target for memory-based credential theft, leading to increased adoption of eBPF-based detection and confidential computing. Organizations that fail to implement LSA Protection and Credential Guard today will face repeated breaches via lateral movement—the single most common path to ransomware deployment in 2025-2026.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rafa Pimentel – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
