NTLM Authenticate and Validation
AUTHENTICATE_MESSAGE
The client's answer is made from the user's NT hash, and a DC checks it for the server.
Why It Matters
Most NTLM attacks lean on this step, because the answer needs only the NT hash and the server trusts whatever the domain controller approves. It is also where the useful events are written, on the DC and on the server.
Where It Sits
The strip shows every step of the NTLM sign-in, with this page's steps marked. Each of the others links to its own page, and Step Through It opens the walk-through on the topic page.
- Step 1 of 6, Negotiate, ws-017 to srv-fin-01
- Step 2 of 6, Challenge, srv-fin-01 to ws-017
- Step 3 of 6, Authenticate, ws-017 to srv-fin-01
- Step 4 of 6, Pass-Through, srv-fin-01 to dc-01
- Step 5 of 6, DC Answer, dc-01 to srv-fin-01
- Step 6 of 6, Access, srv-fin-01 to ws-017
What Happens
ws-017 sends an AUTHENTICATE_MESSAGE with dana's user name, domain and workstation in the clear, and her NTLMv2 response. The response is a keyed hash over srv-fin-01's challenge, a client challenge, the time and the target information. Its key is made from her NT hash, user name and domain.
Into that target information ws-017 adds the name of the server it meant to reach and, over TLS, a hash of the channel. An SMB server that checks the name, or a web server enforcing Extended Protection for Authentication, refuses an answer meant for somewhere else. A message integrity code (MIC) over all three messages stops a machine in the middle removing options such as signing, since only the DC or a holder of her NT hash can work out its key.
srv-fin-01 cannot check a domain account's answer, because it does not hold dana's hash, so it passes her name, its challenge and her response to dc-01 over its Netlogon secure channel. dc-01 works out the expected response from its own copy of the hash and, if they match, returns her group SIDs and the session key. A local account is checked against the server's own SAM instead.
srv-fin-01 then builds dana's access token and accepts the session. Where SMB signing is required, every message is signed with a key from that session key. A machine relaying the exchange never learns the key, so it cannot sign, though the logon itself has already succeeded.
dc-01 writes event 4776 to its Security log, naming the client in Source Workstation and never the server, and srv-fin-01 writes event 4624 to its own Security log with Authentication Package NTLM and Package Name NTLM V2. In the DC's Microsoft-Windows-NTLM/Operational log, event 8004 names the server's secure channel where NTLM auditing is on, and the enhanced event 4032 names the client, the server, the NTLM version and the MIC status.
What Is Sent
Each part of the message is listed with what it holds and what protects it. A part sealed with a key can be read only by whoever holds that key, and a part marked In the clear has no protection of its own.
Authenticatews-017 to srv-fin-01
| Part | What It Holds | Protection and Who Can Read It |
|---|---|---|
Who is signing in UserName, DomainName, Workstation | dana, her domain CORP and her machine WS-017. | In the clearAnyone who sees the traffic can read it. |
The NTLMv2 response NtChallengeResponse | A keyed hash over srv-fin-01's challenge, a challenge of ws-017's own, the time and srv-fin-01's details, with a key made from her NT hash, user name and domain. | Computed with dana's NT hashOnly ws-017 and dc-01 can make or check it. |
The intended server MsvAvTargetName, MsvAvChannelBindings | The name of the server ws-017 meant to reach and, over TLS, a channel binding, both inside the response, so changing either breaks it. | In the clearAnyone who sees the traffic can read it. |
A message integrity code MIC | A keyed hash over all three messages, so no one in the middle can strip options such as signing without her NT hash. | In the clearAnyone who sees the traffic can read it. |
Pass-Throughsrv-fin-01 to dc-01
| Part | What It Holds | Protection and Who Can Read It |
|---|---|---|
dana's name NETLOGON_NETWORK_INFO | Her user name and domain, with WS-017, the machine her answer named. | Protected by the Netlogon secure channelOnly srv-fin-01 and dc-01 can open it. |
Challenge and response LmChallenge, NtChallengeResponse | srv-fin-01's challenge and dana's NTLMv2 response, passed on unchanged. | Protected by the Netlogon secure channelOnly srv-fin-01 and dc-01 can open it. |
DC Answerdc-01 to srv-fin-01
| Part | What It Holds | Protection and Who Can Read It |
|---|---|---|
| The verdict | Yes, or a failure status when the response does not match. | Protected by the Netlogon secure channelOnly srv-fin-01 and dc-01 can open it. |
dana's groups NETLOGON_VALIDATION_SAM_INFO4 | Her SID and group memberships from the directory, for her access token. | Protected by the Netlogon secure channelOnly srv-fin-01 and dc-01 can open it. |
A session key UserSessionKey | The key srv-fin-01 needs to check the MIC and to sign the session. | Protected by the Netlogon secure channelOnly srv-fin-01 and dc-01 can open it. |
Accesssrv-fin-01 to ws-017
| Part | What It Holds | Protection and Who Can Read It |
|---|---|---|
Session accepted Status | Success, signed with a key derived from the NTLM session key. Where signing is required, every later message is signed too. | In the clearAnyone who sees the traffic can read it. |
Error Code in Event 4776
When an NTLM check fails, event 4776 in the Security log records why in its Error Code. These are the codes you will meet most, from a wrong password to a locked account.
| Error Code | Meaning |
|---|---|
| 0x0 | Success |
| 0xC0000064 | The user name does not exist |
| 0xC000006A | The user name exists but the password is wrong |
| 0xC000006D | A general failure, such as a bad name or password, or a LAN Manager level mismatch |
| 0xC0000071 | The password has expired |
| 0xC0000072 | The account is disabled |
| 0xC0000193 | The account has expired |
| 0xC0000234 | The account is locked out |
What Is Logged
Each event below names the log it is written to, the machine that writes it and the audit setting that switches it on, then what to read in it for this page.
| Event and Log | Written On | Switch It On | What It Tells You |
|---|---|---|---|
| 4020 and 4021 This machine attempted to authenticate to a remote resource via NTLM (opens in a new tab) Microsoft-Windows-NTLM/Operational log | The client that sends the NTLM sign-in (4021 flags a weaker one, such as NTLMv1) | On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The NTLM Enhanced Logging policy (System > NTLM) controls it | AuthenticateThe target, its address and the Reason NTLM was used, which reads "The target name contains an IP address."When enabled |
| 4776 The computer attempted to validate the credentials for an account (opens in a new tab) Security log | The computer that holds the account, a domain controller for a domain account or the computer itself for a local one | Audit Credential Validation | DC AnswerLogon Account dana, Source Workstation WS-017, Error Code 0x0. It does not name srv-fin-01. |
| 8004 Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller (opens in a new tab) Microsoft-Windows-NTLM/Operational log | Domain controllers | Network security: Restrict NTLM: Audit NTLM authentication in this domain, set to Enable all, on domain controllers | DC AnswerUser name dana, Workstation name WS-017 and Secure Channel name SRV-FIN-01, the server that 4776 leaves out.When enabled |
| 4030 to 4033 The DC <DC Name> processed a forwarded NTLM authentication request originating from this domain (opens in a new tab) Microsoft-Windows-NTLM/Operational log | Domain controllers, which log 4032 and 4033 when the server is in its domain and 4030 and 4031 when only the client account is | On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The Log Enhanced Domain-wide NTLM Logs policy (System > Netlogon) controls it | DC AnswerThe client, the server and the NTLM version in one event, 4032 here, as dana and srv-fin-01 are both in dc-01's domain, or 4033 when it flags a weaker sign-in.When enabled |
| 4624 An account was successfully logged on (opens in a new tab) Security log | The computer that was logged on to | Audit Logon | AccessLogon Type 3, Authentication Package NTLM, Package Name (NTLM only) NTLM V2, Workstation Name WS-017, Source Network Address 192.0.2.17.Reading Logon Events explains how to read it. |
| 4022 and 4023 A remote client is using NTLM to authenticate to this workstation (opens in a new tab) Microsoft-Windows-NTLM/Operational log | The server the NTLM sign-in reaches (4023 flags a weaker one, such as NTLMv1) | On by default on Windows 11 24H2, Windows Server 2025 and, with October 2026 updates, Windows Server 2019 and 2022. The NTLM Enhanced Logging policy (System > NTLM) controls it | AccessUsername dana, Client Machine WS-017 and Client IP 192.0.2.17, with the NTLM Version and the MIC Status.When enabled |
- Pass-ThroughNothing is logged for the request itself, and dc-01 writes its check to its Security log as event 4776 when it answers.
Check It on a Machine
These Windows Registry keys hold the settings this page names. Open one to see where it lives and how to read it on a machine.
Attacks That Hook in Here
These attacks work through what this page describes. Each card says what the attack is and, where it uses one of these steps, what it does there.
- Pass-the-Hash
Signs in over NTLM with a stolen NT hash, never needing the password.
At This Step This answer is computed from dana's NT hash, never her password itself, so a stolen copy of the hash can make it.
- LLMNR, NBT-NS and mDNS Poisoning
Answers the local network's name queries so victims sign in to the wrong machine.
At This Step The fake server keeps this answer. Guessed against offline, it gives up a weak password.
- NTLMv1 Downgrade
Gets a weak NTLMv1 response from a client still allowed to send one, then the NT hash.
At This Step Sent in version 1, this answer is weak, because it can be turned back into the NT hash offline, however strong the password.
- NTLM Relay
Passes a victim's NTLM sign-in to another server and keeps the session it opens.
At This Step The machine in the middle forwards this answer unchanged to the server it chose, and keeps the session that opens.
- Password Spraying
One guessed password tried against many accounts, over Kerberos and NTLM.
At This Step Wrong guesses fail here, and the DC's Security log gets 4776 with Error Code 0xC000006A for a bad password or 0xC0000064 for no such name.
- Skeleton Key
Patches LSASS on a DC so one master password signs in as any account.
At This Step A DC whose NTLM check is patched in memory can also approve an answer made from the master password instead of the account's own.
Sources
- [MS-NLMP] AUTHENTICATE_MESSAGE (opens in a new tab)
- [MS-NLMP] 3.3.2 NTLM v2 Authentication (opens in a new tab)
- [MS-APDS] 1.4.1 NTLM Logon (opens in a new tab)
- [MS-NRPC] 1.3.1 Pass-Through Authentication (opens in a new tab)
- Microsoft Learn: Security Event 4776 (opens in a new tab)
- Ask the Directory Services Team: NTLM Blocking and You (Event 8004) (opens in a new tab)
- Microsoft Learn: Security Event 5168 (opens in a new tab)
- Microsoft Learn: Microsoft Network Server: Server SPN Target Name Validation Level (opens in a new tab)
- Microsoft Learn: Control SMB Signing (opens in a new tab)
- Microsoft Security Advisory 973811: Extended Protection for Authentication (opens in a new tab)
- Microsoft Support: KB5064479, NTLM Auditing Enhancements (opens in a new tab)