OPSEC

Credentials

Credential extraction on Windows often targets LSASS (lsass.exe), which handles authentication and stores credential material like NTLM hashes, AES keys, and Kerberos tickets in memory. Since LSASS is highly monitored, in-memory extraction (e.g., with Mimikatz’s sekurlsa) is risky and often requires elevated privileges and stealth. Not all credential artifacts require touching LSASS:

Registry Hives

Local account password hashes are stored in the SAM hive, while service credentials and domain cached creds reside in the SECURITY hive as LSA secrets — these can be retrieved from the registry or volume shadow copies and are typically less monitored.

DPAPI

Additional credential material exists on disk via DPAPI-protected storage, including browser-stored passwords, cookies, tokens, and Windows Vault credentials. In modern environments, browser data can often be as valuable as LSASS.

PS History

PowerShell history is another often-overlooked source: the ConsoleHost_history.txt file, managed by the PSReadLine module (enabled by default), can expose sensitive commands unless the module filters keywords like password, token, or apikey.

While the NT hash enables NTLM-based attacks like Pass-the-Hash, it has limited utility in Kerberos scenarios. Modern environments increasingly disable RC4 (which depends on the NT hash) and enforce stronger Kerberos encryption.

For Kerberos-based impersonation or ticket forging, the AES-256 key is the most reliable and opsec-friendly option. It offers broad compatibility with hardened domain policies, avoids RC4 fallback, and enables stealthier operations such as Overpass-the-Hash or Golden Ticket attacks. In environments with NTLM restrictions or where visibility into legacy auth is high, leveraging AES keys significantly reduces detection and increases stability across Kerberos-based lateral movement.

Commands

Enum

# Alt to whoami
set username
$env:USERNAME

# Alt to hostname
set computername
$env:COMPUTERNAME