Authentication: NTLM, Kerberos & Tickets
Nearly every advanced Windows attack technique you will meet in this field is really just an abuse of the authentication mechanics covered in this chapter. Kerberoasting abuses how service tickets are requested and encrypted. Pass-the-hash abuses what NTLM actually treats as proof of identity. Golden and silver tickets abuse the trust the Key Distribution Center places in a ticket's contents. None of that will make sense from memorized attack steps alone. Get the mechanics right here and every technique built on top of them gets easier to reason about, detect, and explain.
Kerberos Core Concepts
Kerberos runs on a trusted-third-party model. A client never proves its identity directly to every server it wants to use. Instead, both sides trust a shared intermediary that vouches for both of them.
- KDC (Key Distribution Center): the trusted intermediary. Runs on every domain controller.
- AS (Authentication Service): half of the KDC. Proves who you are, once.
- TGS (Ticket Granting Service): the other half. Issues credentials for specific resources.
- krbtgt: a disabled built-in account. Its password hash is the domain's root of trust.
The KDC Splits Into Two Jobs
The AS handles the first step: proving who a user is and issuing a starting credential. The TGS handles everything after that: taking an already-proven identity and issuing credentials for specific resources. Splitting the work this way means a user proves their password once per session, not once per server they touch.
Why a Server Can Trust Data It Never Asked For
The KDC shares a long-term secret key with every account, derived from that account's password hash. It also holds a separate key used only to protect domain-controller-only data.
Anything encrypted with an account's key can only be decrypted by that account. Anything encrypted with the KDC's own key can only be decrypted by another domain controller. That's the whole trick: a server can trust a piece of data it never directly requested, because only the KDC could have produced it.
krbtgt: The Root of Trust
The krbtgt account exists purely to hold the key that protects Ticket Granting Tickets. It's disabled, and its password hash does not rotate on any normal schedule. That combination is exactly why it becomes a critical target later in this module, covered in full in Chapter 8.
The Full Ticket Exchange, Step by Step
A Kerberos logon is four exchanges in a fixed order. The order matters more than the acronyms, so walk through it as a sequence, not a list of terms to memorize.
- AS-REQ, client to AS. The client sends its username plus a timestamp encrypted with a key derived from the user's password. This is pre-authentication: it stops an attacker from harvesting AS-REP traffic offline without already knowing something derived from the password. The password itself never crosses the network.
- AS-REP, AS to client. The KDC decrypts the timestamp with its own copy of the same key and checks it's recent. If that succeeds, it replies with two things encrypted differently: a session key (readable only by the user) and the TGT itself, encrypted entirely with krbtgt's key. The client can't decrypt the TGT and doesn't need to; it just stores it.
- TGS-REQ, client to TGS. When the user wants a specific resource (a file share, a web app), the client doesn't go back to the AS. It sends the TGS the stored TGT, the target's Service Principal Name (SPN), and a fresh authenticator encrypted with the session key. The KDC decrypts the TGT with krbtgt's key, pulls the session key back out, and re-verifies the client's identity without ever touching a password.
- TGS-REP, TGS to client. The KDC replies with a service ticket for that SPN, encrypted not with krbtgt's key but with the target service account's own key. Hold onto that distinction; it's the entire reason Kerberoasting is possible, covered later in this chapter.
- AP-REQ, client to target service. The client presents the service ticket directly to the server, which decrypts it with its own key and grants access. No password, and no further contact with a domain controller was needed for this specific service.
Quick reference for the same five messages:
| Message | Sent By | Contains / Proves |
|---|---|---|
| AS-REQ | Client → KDC (AS) | Username and pre-auth timestamp encrypted with the user's password-derived key |
| AS-REP | KDC (AS) → Client | Session key (encrypted for the user) plus the TGT (encrypted with krbtgt's key) |
| TGS-REQ | Client → KDC (TGS) | The stored TGT, target SPN, and a fresh authenticator proving current possession of the session key |
| TGS-REP | KDC (TGS) → Client | A service ticket encrypted with the target service account's own long-term key |
| AP-REQ | Client → Target Service | The service ticket, decryptable only by the service, granting access |
NTLM Authentication
NTLM predates Kerberos and works on a completely different model: challenge-response, with no trusted third party in the exchange at all.
How the Exchange Works
The server sends the client a random challenge. The client combines it with a value derived from the user's NTLM hash and sends back a response. The server (or a domain controller acting on its behalf via Netlogon) redoes the same computation with its own stored copy of the hash and checks for a match.
- No mutual authentication. The client never verifies the server is legitimate, it just answers whatever challenge arrives.
- Relayable by design. An attacker who sits between client and server, or lures a client to an attacker-controlled listener, can forward the challenge/response pair to a real target and get in. Nothing ties the response to a specific destination unless SMB signing or Extended Protection for Authentication is enforced.
- Deterministic response = pass-the-hash. The response is fully determined by the hash and the challenge. Anyone who captures the hash (via LSASS dumping, offline cracking, or live relay) can authenticate as the user without ever knowing the plaintext password.
This isn't a bug that slipped through, it's a structural property of challenge-response with no trusted intermediary. Kerberos doesn't have this gap: the client's trust sits with the KDC, not the individual server, and the service ticket itself proves the server holds the correct key.
Kerberos vs NTLM in Practice
On a fully modern domain, Kerberos handles essentially all domain-joined interaction: workstation logon, file shares, Integrated Windows Authentication web apps. Windows picks the protocol automatically through Negotiate, which prefers Kerberos and only drops to NTLM when Kerberos genuinely can't be used.
Four Scenarios Where NTLM Is Still Required
- IP-based access. A Kerberos service ticket is bound to an SPN tied to a DNS name. No SPN exists for a bare IP, so Kerberos breaks.
- Workgroup and standalone machines. No domain membership means no KDC to talk to at all.
- Legacy applications. Some older third-party systems were simply never updated to support Kerberos.
- Local logons. With no domain controller in the loop, local logon always uses NTLM-style challenge-response against the SAM database.
Because Negotiate silently falls back rather than failing, NTLM stays enabled by default across most domains, even when Kerberos handles the vast majority of daily authentication. That's exactly what keeps it relevant to attackers: NTLM doesn't need to be the primary protocol to be exploitable, just enabled somewhere reachable. One legacy app on IP-based access, or one service with signing disabled, is enough of a foothold.
Disabling NTLM outright is rarely feasible in a real enterprise, so the practical posture is restriction, not elimination: Group Policy settings that restrict NTLM to specific systems, enforce SMB signing, and require Extended Protection for Authentication. Knowing which protocol is actually in use for a given connection is a prerequisite for scoping any of those controls correctly.
Why Tickets Are a Target
Two structural properties of Kerberos, both already covered above, are what make tickets an attack surface rather than just a transport mechanism. This is a conceptual preview; full attack mechanics wait for Chapter 8.
| Property | Why It's Exploitable | Seeds This Attack |
|---|---|---|
| Service tickets are encrypted with the target account's key | Any authenticated user can request a ticket for any SPN, no special privilege needed, then crack it offline with zero further DC contact and no failed-logon events | Kerberoasting |
| The KDC trusts a ticket's contents purely because krbtgt encrypted it | A DC never re-checks a TGT's claims against a live database, it trusts the encryption. Whoever holds the krbtgt hash can forge a TGT with any identity offline | Golden / Silver Tickets |
Weak or old passwords on SPN-registered service accounts make the first property practical. Compromising the krbtgt hash makes the second one catastrophic.
Authentication Events in the Logs
Every exchange in this chapter leaves a matching entry in the Windows Security event log. Four Event IDs form the backbone of authentication visibility, mapping each log line back to a specific step above is what turns this chapter from theory into something you can use in an investigation.
| Event ID | Fires When | What to Watch |
|---|---|---|
| 4768 | TGT requested (AS-REQ/AS-REP) | Unusual hour or unexpected source IP, often the first visible sign of credential misuse |
| 4769 | Service ticket requested (TGS-REQ/TGS-REP) | Burst against many different SPNs from one account in a short window, a direct Kerberoasting signal (full detection in Chapter 8) |
| 4624 | Successful logon, any protocol | Check the Logon Type and Authentication Package Name fields, the latter tells you Kerberos vs NTLM directly |
| 4625 | Failed logon, any protocol | A string of these against one account followed by a single 4624 is the classic successful-password-guess signature |
4768 and 4769 give visibility into the Kerberos ticket layer specifically. 4624 and 4625 give visibility into any logon's outcome regardless of protocol. Correlating all four by account and timestamp is the foundation of authentication log analysis, and Chapter 6 builds directly on them when it covers logging and detection engineering in depth.
Key Takeaways
- Kerberos is built on a trusted-third-party model: the KDC (split into the AS and TGS) vouches for both client and server so neither has to trust the other directly.
- The full exchange runs AS-REQ/AS-REP to obtain a TGT, then TGS-REQ/TGS-REP to trade that TGT for a service ticket, then AP-REQ to present the service ticket to the target service.
- A TGT is encrypted with the krbtgt account's key; a service ticket is encrypted with the target service account's key. That distinction is the seed of golden vs silver tickets.
- NTLM is challenge-response with no trusted third party, which means it has no mutual authentication and is inherently relayable.
- NTLM survives as a fallback for IP-based access, workgroup and local logons, and legacy systems, and stays enabled by default even on Kerberos-first domains.
- Event IDs 4768 (TGT requested), 4769 (service ticket requested), 4624 (successful logon), and 4625 (failed logon) are the core building blocks of authentication log analysis.
Knowledge Check
Click an answer to reveal the explanation.
A user has already obtained a TGT and now wants to access a file share. Which exchange do they use, and what do they present to the KDC?
A legacy application on the network is only reachable by IP address, not by hostname. A user authenticating to it will most likely use:
You see a single account generate Event ID 4769 requests against fifteen different SPNs within two minutes, none of which the account normally accesses. What does this most likely represent?