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

PS History

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