Credential Extraction from Memory — LSASS, Mimikatz Artifacts, and Browser Credentials

Credential extraction from memory is the most sensitive operation in IR — the outputs are live credentials that must be treated with the same care as the incident itself. Understanding what Mimikatz does in memory lets you detect it, even when the binary has been deleted.

LSASS Memory — What Volatility Extracts

# Method 1: windows.hashdump — extracts NT hashes from SAM + LSASS
# Works on images with accessible LSASS and SYSTEM hive
vol.py -f memory.raw windows.hashdump

# Output format:
# User      | RID  | LM Hash                              | NT Hash
# Administrator | 500 | aad3b435b51404eeaad3b435b51404ee | 32ed87bdb5fdc5e9cba88547376818d4
# Guest         | 501 | aad3b435b51404eeaad3b435b51404ee | 31d6cfe0d16ae931b73c59d7e0c089c0

# NT hash uses: crack offline (hashcat -m 1000) or pass-the-hash with PsExec/impacket
# aad3b435b51404eeaad3b435b51404ee = empty LM hash (LM disabled — normal on modern systems)
# 31d6cfe0d16ae931b73c59d7e0c089c0 = empty NT hash (blank password account)

# Method 2: windows.lsadump — extracts LSA secrets (service account passwords, DPAPI)
vol.py -f memory.raw windows.lsadump

# Method 3: windows.cachedump — extracts cached domain credentials (MSCACHE2)
# These are the cached domain creds used when DC is unreachable
# Crackable with hashcat -m 2100 (slow)
vol.py -f memory.raw windows.cachedump

Detecting Mimikatz via Memory Analysis

# 1. Search for Mimikatz strings in memory (even if binary was deleted)
vol.py -f memory.raw windows.strings | grep -i "mimikatz\|sekurlsa\|privilege::debug\|lsadump"

# 2. Check which processes accessed LSASS (process access events)
# Find LSASS PID first:
vol.py -f memory.raw windows.pslist | grep lsass
# LSASS PID: 820

# Check handles opened to LSASS by other processes:
vol.py -f memory.raw windows.handles | grep 820

# 3. Check for SeDebugPrivilege on non-SYSTEM processes
vol.py -f memory.raw windows.privileges | grep -i "SeDebugPrivilege"
# SeDebugPrivilege PRESENT+ENABLED on a non-admin process = red flag

# 4. Look for LSASS memory dump artifacts
# If attacker used Task Manager or ProcDump to create lsass.dmp:
vol.py -f memory.raw windows.filescan | grep -i "lsass"
# Found: \Temp\lsass.dmp or \Users\Public\lsass.dmp = credential dump staging

LSASS Protection Detection

# Check if PPL (Protected Process Light) is configured
# From memory: check the EPROCESS.Protection field for LSASS
vol.py -f memory.raw windows.pslist | grep lsass
# Look for 'Prot' column — value 4 = PPL

# Check registry hive in memory for RunAsPPL setting
vol.py -f memory.raw windows.registry.hivescan
vol.py -f memory.raw windows.registry.printkey \
  --key "HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa" \
  --recurse | grep -i "RunAsPPL"
# RunAsPPL = 1: LSASS is a protected process — Mimikatz needs mimidrv.sys

# Check for Credential Guard (Virtualization Based Security)
vol.py -f memory.raw windows.pslist | grep lsaiso
# lsaiso.exe running = Credential Guard active
# If lsaiso.exe is present, NT hashes are not accessible in LSASS memory

Browser Credential Extraction from Memory

# Identify browser process PIDs
vol.py -f memory.raw windows.pslist | grep -E "chrome|msedge|firefox"

# Search browser memory for credential-shaped strings
vol.py -f memory.raw windows.strings --pid [CHROME_PID] | \
  grep -E "https?://.*password|password.*https|\"password\""

# Dump browser process for offline analysis
vol.py -f memory.raw windows.dumpfiles --pid [CHROME_PID] --name chrome.exe

# Analyze the dump with strings
strings chrome.exe.*.dmp | grep -E "password|credential|token|Bearer"

# Find Chrome Login Data database in memory (file handle)
vol.py -f memory.raw windows.handles --pid [CHROME_PID] | grep "Login Data"

# Look for DPAPI blobs being decrypted (Chrome calls CryptUnprotectData)
vol.py -f memory.raw windows.malfind --pid [CHROME_PID]
# Chrome's JIT may produce FPs — filter by MZ header presence

Handling Extracted Credentials

⚠️  CREDENTIAL SECURITY PROTOCOL ⚠️

Any credential extracted from memory must be treated as LIVE and COMPROMISED.

Required actions upon extraction:
1. Document in chain of custody: "NT hash extracted from memory image. 
   Treat as live credential. Restricted to IR team and legal counsel."

2. Restrict dissemination: Do NOT put raw hashes in reports, emails, 
   tickets, or Slack channels. Reference by account name and incident ID only.

3. Notify identity team: Account requires immediate password reset.
   Do NOT perform the reset yourself until containment plan is approved.

4. SIEM alerting: Alert on the extracted NTLM hash being used for 
   authentication anywhere in the environment — this detects if the 
   attacker already used it laterally.

5. Crack only if required: Cracking NT hashes requires explicit 
   authorization. The cracked plaintext is MORE sensitive than the hash.

Retrieval Practice

A Volatility windows.hashdump result shows the Administrator account with NT hash 32ed87bdb5fdc5e9cba88547376818d4. The attacker used this hash before it was rotated. What does the analyst do with this hash during the IR, and what should NOT be done?

Reveal answer

What to do: (1) Document the hash in the chain of custody evidence log — mark as sensitive, restricted to IR lead and legal counsel. (2) Immediately notify the identity team to disable the Administrator account or reset the password — do NOT perform the reset without coordination because it may alert the attacker to IR activity before containment is complete. (3) Create a detection in the SIEM/EDR: alert on any NTLM authentication event using this exact NT hash value from any source IP — this detects lateral movement the attacker may have already performed or may attempt before the reset. (4) Check if the hash was already used: query authentication logs (Windows Security Event 4776 — NTLM authentication) for this account across all DCs and servers to identify pass-the-hash lateral movement. What NOT to do: (1) Do NOT paste the hash into a Slack message, Jira ticket, email, or any shared system — the hash is a live credential and must be treated with need-to-know access controls. (2) Do NOT crack the plaintext immediately — the hash is sufficient for most IR actions and cracking creates additional sensitive data (the plaintext password) that has even broader exposure risk. Crack only if the business requires the plaintext for account recovery coordination. (3) Do NOT share the hashdump output file with parties outside the core IR team without redacting all hash values.