5.2 Credential & Password Hash Extraction

5.2 Credential & Password Hash Extraction

Credential harvesting represents one of the most critical phases of post-exploitation. Once an attacker or penetration tester achieves administrative or root access on a target host, extracting stored credentials allows for vertical privilege escalation, persistence establishment, and extensive lateral movement across segmented internal subnets.

Modern operating systems do not store user passwords in cleartext. Instead, they employ one-way cryptographic hashing functions combined with salt values to verify user authentication without retaining the original secret. Understanding how Linux and Windows operating systems store, protect, and process credentials—both on disk in static databases and in active volatile system memory—is mandatory for succeeding on the eJPT examination and in practical security assessments.

Cryptographic Storage Principles: Hashes vs. Salting

A cryptographic hash function takes an arbitrary-length input (such as a password) and produces a fixed-length string of bytes known as a digest. A secure hashing algorithm satisfies three properties:

1. Pre-image Resistance (One-Way): It is computationally infeasible to reverse the hash digest back into the original plaintext password.
2. Second Pre-image Resistance: Given an input and its hash, it is computationally infeasible to find another distinct input that produces the identical hash.
3. Collision Resistance: It is computationally infeasible to find any two arbitrary inputs that generate the same hash output.

The Role of Cryptographic Salting

A salt is a random string of bits generated uniquely for each user and concatenated with the plaintext password prior to hashing. Salting provides two critical defenses:

• Prevents Lookup & Rainbow Table Attacks: Pre-computed rainbow tables cannot be utilized against salted hashes because the attacker must calculate a unique table for every distinct salt value.
• Prevents Identical Hash Collisions: If two users choose the identical password Password123!, their stored hashes will differ completely because their accounts have different salt strings.

---

Linux Credential Architecture & Shadow Hash Extraction

In UNIX and Linux systems, user account metadata and authentication material are segregated into two distinct administrative files: /etc/passwd and /etc/shadow.

Historical Separation: /etc/passwd vs. /etc/shadow

In early UNIX operating systems, encrypted password hashes were stored directly in /etc/passwd. However, system utilities such as ls, ps, and mail daemons require access to /etc/passwd to map numerical User IDs (UIDs) and Group IDs (GIDs) to human-readable account names. As a result, /etc/passwd must be world-readable (chmod 644).

Because world-readable hashes allowed unprivileged users to copy password digests and attempt offline cracking, modern Linux systems moved authentication hashes into /etc/shadow.

• /etc/passwd permissions: -rw-r--r-- (644), readable by all system users.
• /etc/shadow permissions: -rw-r----- (640 owned by root:shadow) or -rw------- (600 owned by root:root), readable strictly by elevated accounts.

Structure of /etc/shadow

The /etc/shadow file stores one record per line, structured into nine colon-delimited (:) fields:

root:\$6\$rounds=5000\$qZ8jKl9m\$Wk8...:19245:0:99999:7:::

Account Lock Tokens

If the second field does not contain a valid hash digest, it indicates account authentication state:

• * or ! or !!: The account is locked or disabled; the user cannot authenticate via password.
• Empty string (::): The account possesses no password; depending on PAM configuration, login may be permitted without authentication.

Modular Crypt Format & Hash Identifiers

Linux password hashes adhere to the Modular Crypt Format. The hash field is segmented by dollar signs (\$) into distinct structural components:

\$id\$[rounds=N\$]salt\$hash

The integer or characters residing between the first and second dollar signs (\$id\$) specify the cryptographic algorithm:

The unshadow Workflow for Password Cracking

When preparing to crack Linux credentials using tools like John the Ripper, supplying /etc/shadow alone is often insufficient. John the Ripper relies on account information (such as usernames, home directories, and full names) to construct smart, candidate-specific cracking rules.

The unshadow utility merges /etc/passwd and /etc/shadow into a single combined file:

# Execute unshadow on the attack host after extracting both files
unshadow /path/to/extracted_passwd /path/to/extracted_shadow > unshadowed_hashes.txt

# Inspect the unshadowed format
head -n 2 unshadowed_hashes.txt
# Output:
# root:$6$qZ8jKl9m$Wk8...:0:0:root:/root:/bin/bash
# user:$6$T8b3jPx9$Lm2...:1000:1000:user:/home/user:/bin/bash

# Crack the unshadowed file with John the Ripper using RockYou wordlist
john --wordlist=/usr/share/wordlists/rockyou.txt unshadowed_hashes.txt

# Display cracked passwords from John's cache
john --show unshadowed_hashes.txt

If utilizing Hashcat instead of John the Ripper, Hashcat requires only the raw hash string (e.g., \$6\$salt\$hash) and uses mode -m 1800 for SHA-512 crypt:

hashcat -m 1800 -a 0 sha512_hashes.txt /usr/share/wordlists/rockyou.txt

---

Windows Local Credential Architecture: SAM, SYSTEM, and NTLM

On standalone Windows workstations and member servers, local user account credentials are stored in the Security Account Manager (SAM) database.

The Registry Hive Structure

The Windows registry organizes configuration data into hierarchical trees called hives. Three hives are critically relevant to credential extraction:

1. HKLM\SAM (C:\Windows\System32\config\SAM): Contains user account names, Relative Identifiers (RIDs), group memberships, and encrypted LM and NTLM password hashes.
2. HKLM\SYSTEM (C:\Windows\System32\config\SYSTEM): Contains global operating system settings, including the SysKey (also called the BootKey). The SysKey is a 128-bit cryptographic key used by the Windows kernel to encrypt the password hashes stored inside the SAM database.

   Critical Rule: Extracting the SAM hive alone is useless. An attacker cannot decrypt or extract password hashes without the corresponding SYSTEM hive.

3. HKLM\SECURITY (C:\Windows\System32\config\SECURITY): Stores Local Security Authority (LSA) secrets, cached domain credentials (DCC2 / MSCash2), DPAPI backup keys, and service account passwords.

The NTLM Hashing Algorithm

The modern authentication standard for local Windows accounts is the NTLM (New Technology LAN Manager) hash. The algorithm operates as follows:

NTLM Hash = MD4(UTF-16LE(Password))

1. The plaintext password is converted into little-endian Unicode (UTF-16LE).
2. The resulting byte stream is passed through the standard MD4 message digest algorithm.
3. The resulting 128-bit digest is represented as a 32-character hexadecimal string.

Critical Cryptographic Weaknesses of NTLM

• Zero Salting: NTLM hashes do not use salts. If ten users on a corporate network choose the password Password123!, every single one of their NTLM hashes will be identical (B53127393433EF8ACD744669647240E4).
• Pass-the-Hash (PtH) Capability: Because the NTLM hash functions as the direct equivalent of the password in Windows challenge-response network protocols (SMB, RPC), an attacker who extracts an NTLM hash does not need to crack it. The attacker can authenticate directly to remote machines across the network using tools like psexec.py, wmiexec.py, or Metasploit using the raw hash string.
• Obsolete MD4 Algorithm: MD4 is cryptographically broken and exceptionally fast to compute, enabling modern GPUs to calculate tens of billions of NTLM hashes per second in offline dictionary attacks.

Historical LM (LAN Manager) Hash

Prior to Windows Vista and Windows Server 2008, Windows utilized the legacy LM hash. LM is notoriously weak:

• Forces all lowercase characters to uppercase (destroying case sensitivity).
• Limits maximum password length to 14 characters.
• Splits the 14-character string into two separate 7-byte halves.
• Encrypts each 7-byte half independently using the DES algorithm with a fixed, static key (KGS!@#\$%).
• Any password shorter than 8 characters leaves the second 7-byte half empty, producing a constant, recognizable null hash: AAD3B435B51404EEAAD3B435B51404EE.

LM hashing has been disabled by default since Windows Vista and Windows Server 2008, appearing in modern environments only as a string of 32 zeros or the fixed null-hash value.

---

Offline Registry Extraction: reg save & Volume Shadow Copies

Because the Windows kernel maintains exclusive open file handles on C:\Windows\System32\config\SAM while the operating system is booted, attempting to copy or open the file directly via standard command-line tools results in a sharing violation (The process cannot access the file because it is being used by another process).

Method 1: The Built-In reg save Command

Local administrators and accounts with elevated privileges can use the Windows reg.exe tool to create static snapshots of active registry hives:

# Create binary backups of SAM, SYSTEM, and SECURITY hives
reg save HKLM\SAM C:\Windows\Temp\sam.save
reg save HKLM\SYSTEM C:\Windows\Temp\system.save
reg save HKLM\SECURITY C:\Windows\Temp\security.save

Once the .save files are transferred to the penetration tester's attack machine, Impacket's secretsdump.py decrypts the SAM database and outputs the local hashes:

# Offline hash extraction on Kali Linux
impacket-secretsdump -sam sam.save -system system.save -security security.save LOCAL

The output displays the standard Windows hashdump structure:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
LocalAdmin:1001:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

The output format follows: Username:RID:LM_Hash:NTLM_Hash:::

Method 2: Volume Shadow Copy Service (VSS)

If security monitoring blocks direct reg.exe calls or if targeting locked Active Directory databases (NTDS.dit) on a live Domain Controller, administrators can create a Volume Shadow Copy to snapshot the drive:

# Create a Volume Shadow Copy of the C: drive
vssadmin create shadow /for=C:

# Query existing shadow copies to retrieve the global root path
vssadmin list shadows

# Copy the locked configuration files directly from the shadow volume
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM C:\Temp\sam.copy
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\Temp\system.copy

# On a Domain Controller, extract the Active Directory database:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\Temp\ntds.dit

---

In-Memory Credential Extraction: LSASS, Meterpreter, and Mimikatz

While offline extraction from the SAM hive yields password hashes for local machine accounts, extracting credentials directly from active system memory can uncover domain credentials, Kerberos tickets, and plaintext passwords for currently logged-on users.

The Role of LSASS (lsass.exe)

The Local Security Authority Subsystem Service (LSASS) is the core Windows operating system process responsible for enforcing local security policy, managing user logins, creating security access tokens, and handling authentication packages (such as Kerberos, NTLM, and WDigest).

When a user logs into a Windows system, LSASS caches authentication credentials in its process memory so that the operating system can seamlessly access network shares, printers, and enterprise resources without prompting the user to re-enter their password for every connection.

Privileges Required for Memory Access

Accessing and dumping LSASS process memory requires the operating system privilege SeDebugPrivilege. By default, SeDebugPrivilege is assigned to members of the local Administrators group and the NT AUTHORITY\SYSTEM account.

Check your current assigned privileges from the command line:

whoami /priv
# Look for: SeDebugPrivilege -> State: Enabled

Meterpreter hashdump Commands

When a penetration tester obtains an elevated Meterpreter session (running as NT AUTHORITY\SYSTEM or with administrative privileges), Metasploit provides built-in modules to automate credential gathering:

# Within an active Meterpreter session:
meterpreter > getsystem
...got system via technique 1 (Named Pipe Impersonation).

# Dump local SAM hashes
meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

# Run the smart hashdump post-exploitation module
meterpreter > run post/windows/gather/smart_hashdump

The smart_hashdump post module automatically detects whether the compromised machine is a standalone workstation, member server, or domain controller, and systematically dumps the SAM or NTDS database while evading common lockups.

Mimikatz & Kiwi Post-Exploitation Deep Dive

Developed by security researcher Benjamin Delpy, Mimikatz is the foremost credential extraction utility in offensive cybersecurity. Metasploit integrates Mimikatz through its Kiwi extension.

To load and initialize Kiwi inside Meterpreter:

meterpreter > load kiwi
Loading extension kiwi...
  .#####.   mimikatz 2.2.0 20191125 (x64/windows)
 .## ^ ##.  "A La Clé des Champs" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##  > http://blog.gentilkiwi.com/mimikatz
 '## v ##'  Vincent LE TOUX ( vincent.letoux@gmail.com )
  '#####'   > http://pingcastle.com / http://mysmartlogon.com ***/
Success.

Essential Mimikatz / Kiwi Commands

1. privilege::debug: Requests and enables SeDebugPrivilege for the Mimikatz process, allowing it to inspect and open handles to other protected processes like lsass.exe.
2. sekurlsa::logonpasswords: The flagship Mimikatz command. It walks the memory space of LSASS, extracting plaintext passwords, NTLM hashes, and Kerberos tickets from all registered Security Support Providers (SSPs) including WDigest, Kerberos, TsPkg, and CredSSP.

   meterpreter > kiwi_cmd sekurlsa::logonpasswords
   # Output displays active logon sessions:
   # Authentication Id : 0 ; 239129 (00000000:0003a619)
   # Session           : Interactive from 1
   # User Name         : Administrator
   # Domain            : CORP
   # Password          : P@ssw0rd2026!
   # NTLM              : 8846f7eaee8fb117ad06bdd830b7586c
   

3. lsadump::sam: Extracts password hashes from the local SAM database directly through memory using the live SysKey, without writing .save files to disk.
4. lsadump::secrets: Extracts Local Security Authority (LSA) secrets stored in the registry. LSA secrets contain highly sensitive system secrets, including:
   • Plaintext credentials for Windows services running under dedicated user accounts
   • Stored credentials for scheduled tasks
   • Domain account passwords used for AutoLogon
   • The default machine account password (\$MACHINE.ACC) used to maintain the host's trust relationship with the Active Directory domain controller
5. lsadump::cache: Extracts cached domain credentials (also known as MS-CACHE or DCC2 hashes). When a domain laptop disconnects from the corporate network, Windows caches the last 10 logon hashes locally so the user can continue logging in.

The Plaintext Password Evolution: WDigest & Registry Toggles

On older operating systems (Windows 7, Windows 8, and Windows Server 2008 R2), sekurlsa::logonpasswords routinely extracted cleartext passwords because the WDigest authentication provider maintained a copy of the user's plaintext password in LSASS memory.

Beginning in Windows 8.1 and Windows Server 2012 R2, Microsoft disabled plaintext credential caching in WDigest by default. However, attackers with administrative privileges can force Windows to begin caching plaintext passwords for future logins by modifying the registry:

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f

Once modified, any user who subsequently logs into the host (via console, RDP, or runas) will have their plaintext password cached in LSASS, enabling cleartext recovery during subsequent Mimikatz executions.

---

Comparative Reference Tables

Password Hash Identifiers, Prefixes & Cryptographic Functions

Windows Credential Extraction Methods & Privilege Requirements