Windows Authentication & Credential Storage

Why Authentication Is the Attacker's Favorite Target

Every attacker who gains a foothold on a Windows machine has the same next question: how do I get credentials? Credentials are the keys that unlock lateral movement, privilege escalation, and domain dominance. A single compromised Domain Admin hash can turn a foothold on one workstation into full control of an entire enterprise.

Windows authentication is complex by design — it has to support single sign-on across thousands of machines, backward compatibility with systems from the 1990s, and seamless delegation between services. That complexity creates a large attack surface. Understanding how Windows authenticates users and where it stores their credentials is not optional for a SOC analyst — it is the foundation for detecting every credential theft technique you will encounter in the field.

NTLM Authentication

NTLM (NT LAN Manager) is the older of Windows' two authentication protocols. Despite Microsoft's long-running efforts to deprecate it, NTLM remains active in virtually every Windows environment because legacy applications, network devices, and cross-forest trusts still rely on it.

The Challenge-Response Flow

NTLM uses a three-step challenge-response mechanism. The user's password never crosses the network — only a cryptographic proof that the client knows the password.

The critical detail: the client never sends the password or even the hash directly. It sends an encrypted challenge response. But this design has a fatal weakness — the NTLM hash itself is sufficient to generate valid responses. If an attacker steals the hash, they do not need the plaintext password. This is the foundation of Pass-the-Hash attacks.

NTLM Hash Format

The NTLM hash is an unsalted MD4 hash of the user's password encoded in UTF-16LE:

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

Example for the password "P@ssw0rd":

a4f49c406510bdcab6824ee7c30fd852

NTLMv1 vs NTLMv2

Kerberos Authentication

Kerberos is the default authentication protocol for Active Directory environments. Named after the three-headed dog from Greek mythology, Kerberos is fundamentally a ticket-based system: instead of proving your identity to every service, you prove it once to a trusted third party that issues tickets on your behalf.

Key Components

The Ticket-Granting Process

Click to enlarge

Step 1 — AS-REQ (Authentication Service Request): The client sends a timestamp encrypted with the user's password hash to the KDC. This proves the user knows the password without sending it.

Step 2 — AS-REP (Authentication Service Response): The KDC verifies the encrypted timestamp, then returns a TGT encrypted with the krbtgt account's hash. The client cannot read inside the TGT — only the KDC can.

Step 3 — TGS-REQ (Ticket Granting Service Request): When the user needs to access a service (e.g., a file share), the client presents the TGT to the TGS and requests a service ticket.

Step 4 — TGS-REP (Ticket Granting Service Response): The KDC decrypts the TGT (using krbtgt hash), validates it, and issues a Service Ticket encrypted with the target service account's password hash.

Step 5 — AP-REQ (Application Request): The client presents the service ticket to the target service. The service decrypts it using its own password hash and grants access.

Step 6 — AP-REP (Application Response): Optional mutual authentication — the service proves its identity back to the client.

Where Windows Stores Credentials

Understanding credential storage locations is essential for detection — every credential theft technique targets one of these specific locations.

The SAM Database

Every Windows machine has a SAM (Security Account Manager) database containing NTLM hashes for local accounts. The file is locked while Windows is running, but attackers extract it using:

• reg save HKLM\SAM sam.save — dumps the SAM registry hive
• Volume Shadow Copy — accesses a snapshot of the locked file
• Offline boot from USB — reads the file directly from the disk

LSASS: The Crown Jewels

lsass.exe (Local Security Authority Subsystem Service) is the most targeted process on any Windows machine. It handles all authentication and stores credentials for every active logon session in memory. When you log into a Windows machine, LSASS caches your NTLM hash and Kerberos tickets so you do not have to re-enter your password for every network resource.

NTDS.dit: The Domain's Password Vault

On Domain Controllers, the NTDS.dit file is the Active Directory database. It contains NTLM hashes and Kerberos keys for every account in the domain — often tens of thousands of accounts. Extracting NTDS.dit gives an attacker the ability to authenticate as any user in the domain.

Credential Caching

Windows caches the last 10 domain logon credentials by default (configurable via CachedLogonsCount registry value). This allows users to log in when the Domain Controller is unreachable (e.g., laptop off the corporate network). Cached credentials are stored as MS-Cache v2 hashes — harder to crack than NTLM but not immune.

How Attackers Steal Credentials

Every technique below targets one of the credential storage locations described above. Understanding the technique helps you understand what to detect.

Click to enlarge

LSASS Memory Dumping

The most direct approach: read credentials straight from LSASS memory.

SAM Database Extraction

reg save HKLM\SAM C:\temp\sam.save
reg save HKLM\SYSTEM C:\temp\system.save

Then offline: secretsdump.py -sam sam.save -system system.save LOCAL

DCSync

DCSync is a domain-level attack where the attacker impersonates a Domain Controller and requests password hashes via the Directory Replication Service (MS-DRSR) protocol. No malware on the DC required — just a compromised account with replication rights.

mimikatz # lsadump::dcsync /domain:corp.local /user:Administrator

DCSync generates Event ID 4662 with specific replication GUIDs on the Domain Controller. In Lab 3.4, you will build a detection rule for this exact event pattern.

Pass-the-Hash (PtH)

The attacker uses a stolen NTLM hash to authenticate without knowing the plaintext password. This works because NTLM challenge-response only requires the hash:

mimikatz # sekurlsa::pth /user:admin /domain:corp.local /ntlm:a4f49c406510bdcab6824ee7c30fd852

PtH generates Event ID 4624 Logon Type 9 (NewCredentials) with NTLM as the authentication package.

Pass-the-Ticket (PtT)

The Kerberos equivalent of Pass-the-Hash. The attacker steals a Kerberos TGT or service ticket from memory and injects it into their own session:

mimikatz # kerberos::ptt stolen_ticket.kirbi

Kerberoasting

Kerberoasting exploits a design feature of Kerberos: any authenticated domain user can request a service ticket for any service account. The service ticket is encrypted with the service account's password hash — so the attacker requests tickets and cracks them offline.

GetUserSPNs.py corp.local/jsmith:Password1 -request -outputfile hashes.txt
hashcat -m 13100 hashes.txt wordlist.txt

Kerberoasting generates Event ID 4769 with encryption type 0x17 (RC4-HMAC) — weaker encryption that is easier to crack. Requests for AES-encrypted tickets (type 0x12) are normal; RC4 requests from a user workstation are suspicious.

Golden Ticket

The ultimate Kerberos attack. If an attacker obtains the krbtgt account's password hash (via DCSync or NTDS.dit extraction), they can forge TGTs for any user — including non-existent users — with any group membership, including Domain Admins.

mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local /sid:S-1-5-21-... /krbtgt:<HASH> /ticket:golden.kirbi

Golden Tickets are valid for 10 years by default and bypass normal authentication logging because the forged TGT was never issued by the real KDC. Detection relies on spotting anomalies: TGTs with impossibly long lifetimes, tickets for non-existent users, or TGS requests (4769) without a corresponding AS request (4768).

Detecting Credential Theft

Every technique above leaves traces. The table below maps attacks to the telemetry that exposes them.

Building a Kerberoasting Detection Rule

Here is what a Wazuh rule for Kerberoasting detection looks like in practice:

<rule id="100410" level="12">
  <if_sid>60106</if_sid>
  <field name="win.eventdata.ticketEncryptionType">0x17</field>
  <field name="win.eventdata.serviceName" negate="yes">krbtgt|\$</field>
  <description>Possible Kerberoasting: RC4 TGS request for service account</description>
  <mitre>
    <id>T1558.003</id>
  </mitre>
</rule>

This rule triggers on Event ID 4769 (via parent rule 60106), filters for RC4 encryption (0x17), and excludes the krbtgt account and computer accounts (which end with $). A hit means someone requested a service ticket using deliberately weak encryption — a hallmark of Kerberoasting.

Sysmon Event ID 10: Your LSASS Sentinel

Sysmon Event 10 (ProcessAccess) logs every time a process opens a handle to another process. For LSASS protection, you monitor for:

TargetImage: C:\Windows\System32\lsass.exe
GrantedAccess: 0x1010  (PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ)
GrantedAccess: 0x1FFFFF (PROCESS_ALL_ACCESS)

Legitimate processes that access LSASS include csrss.exe, services.exe, svchost.exe, and security products. Any other source process accessing LSASS with read permissions is suspicious and should trigger an alert.

Key Takeaways

• NTLM uses challenge-response and is vulnerable to Pass-the-Hash because the hash alone is sufficient to authenticate — the plaintext password is not needed
• Kerberos is ticket-based and more secure, but introduces its own attack surface: Kerberoasting targets service accounts with weak passwords, and Golden Tickets exploit the krbtgt hash
• Credentials are stored in five locations: SAM (local hashes), LSASS (in-memory credentials), NTDS.dit (all domain hashes), LSA Secrets (service account passwords), and the credential cache (last 10 domain logons)
• LSASS is the #1 target — every credential dumping tool (Mimikatz, comsvcs.dll, ProcDump) targets this process. Sysmon Event 10 is your primary detection for LSASS access
• Kerberoasting is detectable via Event ID 4769 with RC4 encryption (type 0x17) for non-computer service accounts
• DCSync generates Event ID 4662 with specific replication GUIDs — watch for replication requests from non-Domain Controller sources
• Credential Guard is the single most effective mitigation: it isolates LSASS credentials in hardware-backed Virtual Secure Mode, making memory dumping impossible even for SYSTEM-level attackers

What's Next

Now that you understand how Windows authenticates users and where credentials live — and how attackers steal them — Lesson 3.5 shifts focus to Windows Services, Tasks & Persistence. You will learn how attackers maintain access after stealing credentials: creating malicious services, scheduled tasks, and registry-based persistence mechanisms that survive reboots. The credential theft techniques from this lesson become the "how they got in" that persistence mechanisms turn into "how they stayed."