How to Extract Credentials from Windows Memory with Mimikatz

/ Hack Log
cyberimage

Introduction

During a post-exploitation engagement, the moment you have local admin or SYSTEM on a Windows box, the next question is almost always: what credentials can I pull from this machine? Mimikatz – written by Benjamin Delpy – remains the most direct answer. It reads the LSASS (Local Security Authority Subsystem Service) process memory and extracts plaintext passwords, NTLM hashes, and Kerberos tickets cached there.

This guide covers the practical flow: getting the right privilege, dumping credentials, and understanding what you are looking at in the output. It also covers the common failure modes that waste time on real engagements.

Tools Required

  • Mimikatz – github.com/gentilkiwi/mimikatz (x64 binary for modern targets)
  • Privileges – Local Administrator or SYSTEM on the target
  • OS – Windows 7 through Server 2019 (technique coverage varies by version)

Note: Most AV/EDR products flag the Mimikatz binary. Obfuscation, in-memory execution, or a custom loader is required on hardened targets. That is outside this guide’s scope, but keep it in mind before dropping the binary to disk.

Step-by-Step Instructions

Step 1 – Transfer and Launch Mimikatz

Get the binary to the target. Common methods: SMB share, web delivery, PowerShell download. Launch from an elevated command prompt (run as Administrator).

mimikatz.exe

You will land at the mimikatz # prompt.

Step 2 – Request SeDebugPrivilege

privilege::debug

This requests the SeDebugPrivilege right, which allows a process to read and write the memory of other processes – including LSASS. A successful response looks like:

Privilege '20' OK

If this fails, you are not running as a true local admin or SYSTEM. A limited admin token (filtered UAC token) is not sufficient – you need an elevated process. Retry from an elevated shell or use a token impersonation technique to escalate first.

Step 3 – Dump Credentials from LSASS

sekurlsa::logonpasswords

This enumerates all active logon sessions from LSASS memory and dumps associated credentials. For each session Mimikatz reports the authentication package, username, domain, and any available credentials (NTLM hash, plaintext password, SHA1).

Step 4 – Check the WDigest Provider

WDigest is an older authentication protocol. On Windows XP through Server 2012 (pre-KB2871997), it caches plaintext credentials in memory by design. On Windows 8.1 / Server 2012 R2 and later, WDigest is disabled by default – but if an attacker or admin previously re-enabled it via the registry, passwords will still be present.

To check the current state on the target:

reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

A value of 0x1 means plaintext passwords are cached. If the value is 0x0 or absent, WDigest caching is disabled – expect empty plaintext fields in the dump.

If you have write access to that key and persistence time, you can enable it and wait for a new logon:

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

You will need a fresh logon event to populate the cache. This is operational tradecraft, not a quick win.

Example Output

A typical sekurlsa::logonpasswords result for a session with plaintext available:

Authentication Id : 0 ; PLACEHOLDER (00000000:PLACEHOLDER)
Session           : Interactive from 1
User Name         : PLACEHOLDER
Domain            : PLACEHOLDER
Logon Server      : PLACEHOLDER
Logon Time        : PLACEHOLDER
SID               : PLACEHOLDER

        msv :
         [00000003] Primary
         * Username : PLACEHOLDER
         * Domain   : PLACEHOLDER
         * NTLM     : PLACEHOLDER_NTLM_HASH
         * SHA1     : PLACEHOLDER_SHA1_HASH
        wdigest :
         * Username : PLACEHOLDER
         * Domain   : PLACEHOLDER
         * Password : PLACEHOLDER_PLAINTEXT_OR_NULL
        kerberos :
         * Username : PLACEHOLDER
         * Domain   : PLACEHOLDER.LOCAL
         * Password : (null)

On a system where WDigest is disabled and no cleartext provider is active, the Password field under wdigest will be (null). The NTLM hash is still usable for pass-the-hash attacks.

Common Mistakes

1. Not Running Elevated

privilege::debug fails silently or returns an error when the shell is not elevated. Always confirm you are running as a true admin – check with whoami /priv and look for SeDebugPrivilege before starting.

2. AV Catching the Binary

Dropping mimikatz.exe to disk on any production endpoint will trigger most AV and EDR products. Use in-memory execution (Invoke-Mimikatz via PowerShell, or a custom reflective loader) on engagements where stealth matters. The technique is the same; the delivery method changes.

3. Expecting Plaintext on Modern Windows

Windows 8.1+ with default configuration does not cache WDigest passwords. If the target is patched and WDigest is disabled, you will get NTLM hashes, not plaintext. Adjust your attack path accordingly – pass-the-hash or crack the NTLM offline.

4. Credential Guard Blocking Everything

Windows 10 Enterprise and Server 2016+ with Credential Guard enabled run LSASS in a virtualization-based security (VBS) isolated process. Mimikatz cannot read the isolated LSA process from a standard SYSTEM context. sekurlsa::logonpasswords will return empty or error. Credential Guard is a hard blocker for this technique – pivot to Kerberoasting, DCSync, or credential capture on the wire instead.

5. Missing SeDebugPrivilege in Output

Some environments strip SeDebugPrivilege from admin tokens via GPO. Verify with whoami /priv. If it is missing, you need SYSTEM – try a SYSTEM shell via task scheduler, service exploitation, or token impersonation (e.g., token::elevate within Mimikatz if you have a SYSTEM token in scope).

Summary

The Mimikatz credential dump flow is three commands on a cooperative target: privilege::debug, sekurlsa::logonpasswords, and reading the output. The real work is getting there – reliable admin access, AV evasion, and knowing when Credential Guard has closed the door. On modern, hardened Windows environments, expect NTLM hashes rather than plaintext, and plan your lateral movement around pass-the-hash or offline cracking rather than reusing passwords directly.

For authoritative technical detail on each Mimikatz module, see the official Mimikatz wiki. For Credential Guard architecture, refer to the [Microsoft Credential Guard documentation](https://learn.microsoft.com/en-us/windows/security/identity-protection