Credential Dumping
Credential dumping is the extraction of account credentials — password hashes, plaintext passwords, or Kerberos tickets — from a compromised system. Attackers use these credentials to move laterally, escalate privileges, and maintain persistent access without triggering additional authentication failures.
Severity
Critical
ATT&CK Tactic
Credential Access
Common attacker usage
Dump LSASS memory (Mimikatz, ProcDump, Task Manager) to obtain plaintext passwords and NTLM hashes for pass-the-hash attacks · Read the SAM database offline to crack local account hashes · Extract NTDS.dit from domain controllers to obtain all domain account hashes · Use DCSync (Mimikatz) to replicate credential data from a DC without touching disk
Investigate immediately if
- !Event 4663 shows access to lsass.exe, NTDS.dit, or SAM by a non-system process
- !procdump.exe, mimikatz.exe, or wce.exe appear in Event 4688 process creation logs
- !A non-privileged account or unexpected process opens LSASS with READ_VM access
- !This finding coincides with brute-force activity, privilege escalation, or lateral movement
MITRE ATT&CK
Technique
T1003 · OS Credential Dumping
Tactic
Credential Access
Security Relevance
Credential dumping is the pivot point of most advanced intrusions. Once an attacker has valid hashes or plaintext passwords, they can authenticate as any user without triggering failed-logon events — making subsequent lateral movement nearly invisible to threshold-based detection. Domain controller credential dumps (NTDS.dit extraction or DCSync) are especially devastating because they yield every account's hash in the domain.
Indicators of Malicious Use
- ⚑Event 4663: ObjectName contains 'lsass', 'ntds.dit', '\SAM', or 'system32\config\sam'
- ⚑Event 4688: NewProcessName includes procdump, mimikatz, wce, fgdump, or pwdump
- ⚑Event 4688: Command line includes '--pid' targeting lsass.exe PID, or '-accepteula'
- ⚑Unusual process (not SYSTEM or antivirus) opening lsass.exe with GrantedAccess 0x1010, 0x1038, or 0x143a
- ⚑LSASS access from a process in a writable or user-controlled directory (AppData, Temp)
- ⚑Volume shadow copy creation followed shortly by SAM/NTDS file access
Example Log Entry
Log Name: Security Event ID: 4663 Level: Information An attempt was made to access an object. Subject: Account Name: attacker-user Account Domain: CORP Logon ID: 0x7B3A91 Object: Object Server: Security Account Manager Object Type: File Object Name: \Device\HarddiskVolume3\Windows\System32\config\SAM Handle ID: 0x3f4 Process Information: Process ID: 0x1a4 Process Name: C:\Users\attacker\Downloads\tools\procdump64.exe Access Request Information: Accesses: ReadData (or ListDirectory) Access Mask: 0x1
Investigation Steps
- 1.Identify the accessing process from Event 4663's ProcessName field — any process other than System, antivirus, or EDR accessing LSASS or SAM is highly suspicious.
- 2.Check the process's parent (Event 4688) — Mimikatz and dump tools are commonly launched from cmd.exe, PowerShell, or a web shell. The parent reveals the attacker's initial access vector.
- 3.Check the process path — legitimate system processes live in System32. Any LSASS-accessing process in AppData, Temp, Downloads, or a user's home directory is an immediate IOC.
- 4.Look for Event 4688 for known dump tool names: procdump, mimikatz, wce, fgdump, pwdump, secretsdump, lsassy, nanodump.
- 5.Check for DCSync indicators: Event 4662 (directory service access) with properties '1131f6aa' (DS-Replication-Get-Changes) or '1131f6ad' (DS-Replication-Get-Changes-All) — these are the AD replication rights Mimikatz's DCSync requires.
- 6.Look for volume shadow copy creation (Event 7036 — VSS service starting, or vssadmin.exe in Event 4688) — attackers create VSS copies to access locked SAM/NTDS files.
- 7.Correlate the timestamp with other findings — credential dumps are almost always preceded by privilege escalation and followed by lateral movement or new account creation.
Check your own logs for this technique — upload an EVTX file for instant detection, no account required.
Common False Positives
- ◎Antivirus and EDR agents — legitimately access LSASS for memory scanning. Known security product processes should be baselined and excluded from alerting.
- ◎Windows Credential Guard diagnostic tools — some Windows built-in processes access LSASS for legitimate credential management tasks.
- ◎ProcDump used by IT staff for application crash dumps — ProcDump targeting lsass.exe specifically has no legitimate use case outside of intentional credential extraction.
- ◎Backup software — may access VSS copies of SAM/NTDS for backup purposes. Verify the backup agent's process name and schedule.
Remediation
- ✓Rotate all credentials immediately — assume every account hash reachable from the compromised system is now compromised.
- ✓Enable Credential Guard on Windows 10/Server 2016+ — stores credentials in a Hyper-V protected container that LSASS credential dump tools cannot reach.
- ✓Enable Protected Users security group for privileged accounts — prevents NTLM, DES, and RC4 use, forcing Kerberos AES and making extracted hashes less useful.
- ✓Enable LSA Protection (RunAsPPL) — makes LSASS a Protected Process Light, blocking non-signed code from accessing LSASS memory. Configurable via registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa → RunAsPPL = 1.
- ✓Audit and restrict high-privilege accounts — if a service account or admin account was dumped, rotate it and review what it has access to.
- ✓Enable object access auditing for LSASS — requires audit policy: 'Audit Object Access → Success and Failure' and a SACL on lsass.exe.
Related Event IDs
Related Detection Guides
Frequently Asked Questions
- Is Event ID 4663 always an indicator of credential dumping?
- No. Event ID 4663 fires on any file or object access where SACL auditing is enabled. Credential dumping is specifically indicated when 4663 shows access to lsass.exe (process memory), ntds.dit (AD database), or the SAM hive, especially from unexpected process names. Backup software, antivirus, and EDR agents also access some of these paths — cross-reference the accessing process name against known-good baselines.
- How do I know if LSASS was dumped?
- Check Event ID 4663 for access to lsass.exe with GrantedAccess codes 0x1010 or 0x1410 (read/query memory). Pair with Event ID 4688 to identify the dumping process — procdump.exe, taskmgr.exe (Task Manager dump), or an anomalous unknown process. If Sysmon is deployed, Event ID 10 (ProcessAccess) provides the GrantedAccess bitmask directly and is far easier to query. The absence of these events does not guarantee LSASS was not dumped — some techniques avoid triggering 4663.
- Can credential dumping be done without Mimikatz?
- Yes. Common alternatives include: ProcDump (procdump.exe -ma lsass.exe), Task Manager (right-click lsass.exe → Create dump file), comsvcs.dll MiniDump via rundll32, and the custom tool nanodump. NTDS.dit can be copied via VSS shadow copies using vssadmin, ntdsutil, or Invoke-NinjaCopy. Detection should focus on the access pattern and process behavior, not Mimikatz-specific filenames.
- What is the difference between LSASS dumping and SAM database dumping?
- LSASS memory contains credentials of currently logged-on users — domain accounts, cached credentials, and Kerberos tickets. The SAM database contains hashed credentials for local accounts only. NTDS.dit contains all domain account hashes. An attacker dumping LSASS gets active session credentials; dumping SAM gets local account hashes; dumping NTDS.dit gets the entire domain. All three are serious but NTDS.dit is the most catastrophic.
Analyze your Windows Event Logs
Upload an .evtx file from servers, domain controllers, or endpoints — get instant detections, MITRE mappings, and an AI-generated triage report.
Detect this technique in your logs →