> For the complete documentation index, see [llms.txt](https://capcap-1.gitbook.io/capcap/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://capcap-1.gitbook.io/capcap/readme/ctf-modules/exploitation/password-attacks/windows-authentication-process.md).

# Windows Authentication Process

## Windows Authentication Process

> **Module:** Password Attacks · Section 10/26 **Path:** Credential Attacks → Windows Auth Theory

***

### Overview

Authentication = proving you are who you say you are. When you type a password, Windows runs it through a chain of processes, DLLs, and databases before granting access. Passwords are **never stored in plaintext** — only as one-way hashes.

***

### The Actors

#### WinLogon.exe

* The **front-door process** — first to wake on `CTRL+ALT+DEL`
* Only process that intercepts keyboard input (via `Win32k.sys` RPC)
* Launches **LogonUI** to show the graphical prompt
* Passes collected credentials to LSASS via `LSALogonUser()`
* Does **not** verify credentials itself — only collects and forwards

#### LogonUI

* Pure UI — just the visual login screen
* No logic, no verification — renders the credential input form

#### Credential Providers

* COM DLLs inside `CredUI.dll`
* One provider per input method: password, PIN, smart card, fingerprint
* Collect your input and return it to WinLogon

#### LSASS — `lsass.exe`

* **Local Security Authority Subsystem Service**
* Located at `%SystemRoot%\System32\lsass.exe`
* The **real decision-maker** — verifies credentials, enforces policies, generates audit logs
* Loads authentication packages (DLLs) to handle different login types
* Holds active credentials in memory at runtime → **primary Mimikatz target**

#### LSA (inside LSASS)

* **Local Security Authority** — policy enforcer within LSASS
* Translates usernames ↔ SIDs (Security Identifiers)
* Manages user rights and local security policies

***

### DLLs Inside LSASS

| DLL            | Role                                                                             | Context            |
| -------------- | -------------------------------------------------------------------------------- | ------------------ |
| `Lsasrv.dll`   | Core LSA server. Contains the **Negotiate** function that picks NTLM or Kerberos | Always loaded      |
| `Msv1_0.dll`   | Handles local logons via NTLM. Talks to SAM database                             | Local / non-domain |
| `Samsrv.dll`   | Manages the SAM database — reads/writes local account data                       | Local              |
| `Kerberos.dll` | Implements Kerberos auth for domain-joined machines                              | Domain             |
| `Netlogon.dll` | Handles network-based logon, communicates with DC                                | Domain             |
| `Ntdsa.dll`    | Manages `ntds.dit` (AD database). Only loaded on Domain Controllers              | DC only            |

> **What is a DLL?** A plugin file (`.dll`) loaded by a process when it needs specific functionality. Instead of one monolithic program, Windows splits capabilities into reusable libraries.

***

### NTLM vs Kerberos

#### NTLM — Older, Challenge-Response

Used for **local logins** and legacy network authentication.

**Flow:**

1. Client sends username
2. Server sends a random **challenge** (nonce)
3. Client encrypts the challenge using the **password hash**
4. Server verifies the response

Password never travels over the network — only the hash response does.

**Weaknesses:** Pass-the-Hash, NTLM relay attacks.

***

#### Kerberos — Modern, Ticket-Based

Used for **domain logins**. Default protocol for Active Directory environments.

**Flow:**

1. Client authenticates to the DC's **KDC** (Key Distribution Center)
2. KDC issues a **TGT** (Ticket Granting Ticket) — master pass
3. Client exchanges TGT for a **service ticket** for a specific resource
4. Service ticket grants access — no password re-sent

**Weaknesses:** Pass-the-Ticket, Golden Ticket, Silver Ticket, Kerberoasting.

***

#### What is a Hash?

A one-way transformation of your password:

```
"Password123" → 8846F7EAEE8FB117AD06BDD830B7586C  (NTLM)
```

* Cannot be reversed
* Can be **cracked** by hashing wordlists and comparing (Hashcat, John)
* Can be used **directly** in Pass-the-Hash attacks without knowing the plaintext

***

### Full Login Flow

```
[1] User presses CTRL+ALT+DEL
         ↓
[2] WinLogon.exe wakes up
    └── Launches LogonUI (shows login screen)
         ↓
[3] Credential Provider (CredUI.dll) collects username + password
         ↓
[4] WinLogon calls LSALogonUser()
    └── Passes credentials to LSASS
         ↓
[5] LSASS loads authentication package (Lsasrv.dll → Negotiate)
    ├── Local account → Msv1_0.dll → NTLM → SAM database
    └── Domain account → Kerberos.dll / Netlogon.dll → ntds.dit on DC
         ↓
[6] Authentication succeeds
    └── CreateDesktop() → Load Profile → Load Registry (HKCU)
        └── userinit.exe → explorer.exe → Desktop
```

***

### Credential Stores

#### SAM Database

Stores **NTLM hashes** for all local user accounts. Never plaintext.

```
Path:     %SystemRoot%\system32\config\SAM
Registry: HKLM\SAM
```

* Locked while Windows is running
* Requires **SYSTEM** privileges to access
* **SYSKEY** (since NT 4.0) adds an extra encryption layer on disk
* Stores LM hashes (legacy, very weak) or NTLM hashes

***

#### NTDS.dit

Active Directory database on **Domain Controllers**. Contains hashed passwords for every domain user.

```
Path: %SystemRoot%\ntds.dit  (DC only)
```

* Synced across all DCs automatically (except RODCs)
* Also stores: group accounts, computer accounts, GPOs
* Dumping this = full domain compromise

***

#### Credential Manager

Built-in Windows feature for saving credentials for websites, apps, and network shares.

```
Path: C:\Users\<username>\AppData\Local\Microsoft\[Vault/Credentials]\
```

* Stored encrypted, tied to the user's **DPAPI** master key
* Decryptable — common target on servers where admins stored domain/RDP creds

***

#### LSASS Memory (Runtime)

While the system is running, LSASS holds credentials in memory:

* NTLM hashes of logged-in users
* Cleartext passwords (WDigest — older systems / misconfigured)
* Kerberos TGTs and service tickets

This is why live memory extraction is so powerful — all active sessions exposed at once.

***

### Pentesting Relevance

| Target             | What You Get                                         | Tool Examples                     |
| ------------------ | ---------------------------------------------------- | --------------------------------- |
| LSASS memory       | NTLM hashes, cleartext (sometimes), Kerberos tickets | Mimikatz, lsassy, pypykatz        |
| SAM database       | Local user NTLM hashes                               | secretsdump.py, reg save          |
| NTDS.dit           | Every domain user's hash                             | secretsdump.py (DCSync), ntdsutil |
| Credential Manager | Saved app/network/RDP creds                          | Mimikatz vault module, cmdkey     |

#### Pass-the-Hash

Once you have an NTLM hash you **don't need the plaintext password**. You authenticate directly using the hash — Windows only validates the NTLM response, not the original password.

```bash
# Example with secretsdump
impacket-secretsdump -sam sam.hive -system system.hive LOCAL

# Pass-the-hash with CME
crackmapexec smb <target> -u Administrator -H <ntlm_hash>
```

#### SAM Dump Commands

```cmd
reg save HKLM\SAM sam.hive
reg save HKLM\SYSTEM system.hive
```

Then transfer and extract offline with `secretsdump.py`.

***

### Glossary

| Term    | Meaning                                                                                        |
| ------- | ---------------------------------------------------------------------------------------------- |
| SID     | Security Identifier — unique numeric ID for every user/group (e.g. `S-1-5-21-...`)             |
| DLL     | Dynamic Link Library — plugin file loaded by processes for specific functionality              |
| Hash    | One-way scramble of a password. Can't reverse, but can crack or pass directly                  |
| TGT     | Ticket Granting Ticket — Kerberos master pass proving identity to the DC                       |
| KDC     | Key Distribution Center — component on DC that issues Kerberos tickets                         |
| DC      | Domain Controller — server managing all users/computers in an AD domain                        |
| AD      | Active Directory — Microsoft's central system for managing enterprise users/machines           |
| DPAPI   | Data Protection API — Windows mechanism for encrypting per-user secrets                        |
| RODC    | Read-Only Domain Controller — does not receive full ntds.dit sync                              |
| SAS     | Secure Attention Sequence — CTRL+ALT+DEL, kernel-level, cannot be faked by userspace           |
| GINA    | Old Windows component replaced by Credential Providers in Vista+                               |
| LM hash | Legacy hash format (pre-Vista). Extremely weak — split into 7-char chunks, trivially crackable |
| WDigest | Old auth protocol — if enabled, stores cleartext creds in LSASS memory                         |

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://capcap-1.gitbook.io/capcap/readme/ctf-modules/exploitation/password-attacks/windows-authentication-process.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.