NTLM challenge-response: Authentication between the client, server, and DC

1. Core mechanism

The decision arises when a client wants to prove its identity to a server without directly giving its password. Since the server does not keep a secret, authentication authority rests with the authority that knows the key derived from the account's password (an authoritative DC for domain accounts, the accessed machine itself for local accounts). This lesson anchors the message and distribution of authority between those three parties.

Interfaces and specifications

• Client: has the NT hash (key for NTOWFv2) derived from the user's password. The server in Type 2 receives the challenge, generates its own client challenge, calculates NTProofStr and sends it in Type 3. The password itself does not go in any messages.
• Target service: it cannot validate a domain account response using its local account data and passes validation to a DC through Netlogon. For a local account, the target computer is the account authority and uses its own account data. An upper protocol such as SMB or HTTP carries the NTLM messages.
• DC: the validation authority for a domain account. Writable DCs replicate credential material. An RODC can validate an account whose credentials are cached under its Password Replication Policy; otherwise it forwards to a writable DC. This visual does not emulate RODC forwarding.
• Netlogon secure channel: pass-through authentication path between the server and the DC. The server transports the NTLM credential to the DC via Netlogon (MS-NRPC) in the format defined by MS-APDS; This channel is set up with the server's computer account.
• MSV1_0: the authentication package used for NTLM credential validation. Visibility of 4776 depends on applicable Audit Credential Validation coverage; absence of the event does not by itself show that validation did not occur.

Where is the account authority?

A domain account’s credential authority is a DC, not the target member server. A local account uses the target machine’s SAM. “Domain accounts are validated only on writable DCs” is incomplete: an RODC can validate permitted, previously cached credentials during a WAN outage. An uncached account needs a reachable writable DC.

The member server accessed from the domain account cannot verify the incoming response on its own; What it does is generate a random server challenge and have the client's response to that challenge checked by an authoritative DC that holds the identity material. In this case, the member server does not make the verification decision; carries the question and obeys the yes/no answer given by DC. In the local account, the table changes: the accessed machine is the authoritative authority of the account and performs the verification locally itself, without pass-through.

This distinction is the basis for the rest of the lesson. Challenge-response verifies knowledge of the secret, but that alone does not bind the session to a specific target/channel across every transport protocol. Additional relay defenses depend on the target protocol: SMB signing protects session traffic with the negotiated session key; LDAP signing protects message integrity; EPA/channel binding on supported TLS services binds authentication to the target or TLS channel.

Three messages: NEGOTIATE, CHALLENGE, AUTHENTICATE

The NTLM exchange consists of three messages, all starting with the signature 'NTLMSSP\0'. The first message is NEGOTIATE_MESSAGE (Type 1, MessageType 0x00000001): the client tells the server what capabilities it supports (negotiate flags). This message does not yet contain ID.

The second message is CHALLENGE_MESSAGE (Type 2, 0x00000002). Here the server generates the 8-byte ServerChallenge field and the TargetInfo (AV_PAIRs; server/domain names, timestamp, etc.). This challenge is the random value the client will use when calculating the response; is different for each session.

AUTHENTICATE_MESSAGE (Type 3) carries the response and account metadata. EncryptedRandomSessionKey is not a populated payload in every exchange: it may be carried under the applicable KEY_EXCH and sign/seal negotiation conditions; without the key-exchange flag its length fields are zero. The target requests DC validation for a domain account and performs local validation for a local account.

Completion of verification in DC (pass-through)

In the domain account, the server cannot check the challenge/response pair in Type 3 itself because it does not have the NT hash. In the flow defined by MS-APDS, the server transmits the authentication material sent by the client to the DC over the Netlogon (MS-NRPC) secure channel. This is called 'pass-through authentication'.

The DC validates the response using the account material and returns the result to the target service. A 4776 may be visible here when applicable Audit Credential Validation is enabled. Status 0x0 denotes success; a nonzero result denotes failed validation.

The result of this architecture is that a single NTLM login can leave a trace on two different machines: 4624 on the target resource server, indicating that the session has been established, and 4776, on the DC, indicating that credit has been verified. The Blue side cannot complete the picture without reading these two together.

Basic challenge-response alone does not give target/channel bond

Server challenge requires the secret to generate the response; In this respect, it protects identity information. However, the basic NTLM challenge-response alone does not bind the response to the specific TCP connection or parent protocol (SMB session, TLS channel, LDAP connection) on which it is transported to the extent that it relies on the relay. In other words, if there is no additional protection, producing a 'correct answer' does not alone prove that the answer 'belongs to this link'.

Different controls close this gap, depending on the target protocol: required SMB signing protects session-message integrity with the negotiated key; LDAP signing signs LDAP messages; EPA/channel binding on supported TLS services binds authentication to the TLS channel or target service. Defaults and enforcement options vary by Windows version and service support. This lesson establishes the source of relay risk; later lessons cover implementation.

This one-sentence observation is the common root of why both the Red-side relay attack and the 4776 'Source Workstation' field on the Blue side can be misleading.

State and data flow

1. The client sends a NEGOTIATE_MESSAGE (Type 1) to the server and reports the capabilities it supports.
2. The server generates and returns a CHALLENGE_MESSAGE (Type 2) containing the 8-byte server challenge and TargetInfo.
3. The client derives the NTOWFv2 key from the user's NT hash and generates its own client challenge.
4. The client combines the server challenge and client challenge structure and calculates NTProofStr.
5. Client NtChallengeResponse sends AUTHENTICATE_MESSAGE (Type 3) containing user/domain/workstation names.
6. For a domain account FS01 passes validation to DC01 through Netlogon. For a local account FS01 uses its own account data; no DC transfer occurs.
7. The account authority evaluates the response. Compare accepted and rejected fixtures; applicable auditing may make a 4776 visible here.
8. The target receives the result and creates a security context on acceptance. Applicable auditing may show 4624/4625. Evaluate the resource request separately: this fixture grants READ but not WRITE.

2. Exploitation

Broken trust assumption

The assumption that is broken is: 'If the client generated the correct NTLM response, that response is valid only against the server to which the client wants to connect.' In reality, the core challenge/response alone is not tied to a specific target or channel; if the target protocol does not require session signing or enforce supported service/target/channel binding (EPA), a party in between can move the same pair to another server and authenticate on that server.

Technical prerequisites

• The attacker must be able to direct the victim to authenticate with NTLM to an endpoint they control (e.g. a triggered SMB/HTTP connection). This requires a location on the network that can be intercepted or trigger duress.
• The target protocol must not require session signing that blocks relay; for TLS-using services, supported EPA/channel-binding checks must also not be enforced. The applicable control depends on the protocol and service.
• The victim's account must have meaningful authority on the target service to which the attacker is relaying; Otherwise, even a successful relay will not work.
• An SPN alone does not force Kerberos. Suitable target identity, the ticket path, application package choice and policy must be considered together; a path explicitly requiring Kerberos may prevent the NTLM exchange.

Exploitation mechanism

Relay exploits the three-way nature of NTLM: the attacker intrudes into the 'challenge bearer' role played by the server. It transmits the NEGOTIATE coming from the victim to the target server, returns the CHALLENGE produced by the target to the victim, and transmits the AUTHENTICATE calculated by the victim back to the target. The victim knows the secret and produces the correct answer; But since this response does not depend on the channel alone and the target protocol does not require session signing or enforce supported EPA/channel-binding checks, the target server opens the session on the attacker's connection. Thus, the attacker works with the target with the victim's identity without cracking any password or hash.

Difference between challenge accuracy and target engagement

Relay's work relies on the scope of what is being verified, not on breaking the cryptography. NTProofStr cannot be generated without knowing the secret; It is strong in this aspect. But NTProofStr alone is not a control that binds the authenticated session to the same TCP connection across every transport protocol.

The attacker therefore never changes or resolves the response; carries it as it is. The problem is that it is not guaranteed which connection the messages belong to. This is not 'decryption with MITM' but 'placing a valid proof of identity in the wrong context'.

Why pass-through architecture makes the relay invisible

The target server does not verify the incoming response itself; It is making a pass-through to DC. DC, on the other hand, only looks at the question 'did this user answer this challenge correctly?' It does not know which physical connection the response is coming from and verifies it. The channel protection depends on the target protocol: required SMB signing, for example, protects session traffic with the negotiated key; EPA/channel binding on supported TLS services binds authentication to the target or TLS channel.

Relay is possible when the authentication proof is not bound to the intended service. Defense uses the control appropriate to the protocol: signing for SMB and EPA/channel binding on suitable TLS services. These are distinct controls and are not available on every service.

3. Defense & Detection

Telemetry scope

• With applicable auditing, 4776 is visible at the credential authority: a DC for a domain account and the target computer for a local account. The target can produce 4776 when it is the local account authority.
• A successful network logon may be visible as 4624 at the target. For a domain account this differs from the DC writing 4776; for a local account both observations can be on the same machine.
• 4776 is in the 'Audit Credential Validation' subcategory, 4624/4625 is in the 'Audit Logon' subcategory; the two are activated separately. If one is on and the other is off, the correlation picture remains incomplete.
• 4776 Workstation reports the authentication source; domain-account validation is logged on the DC. Do not treat this field as the member server forwarding pass-through validation or as the accessed target; inspect the target session separately with 4624.

Events and relevant fields

• 4776 / PackageName: authentication package that performs the verification; For domain NTLM it is always MICROSOFT_AUTHENTICATION_PACKAGE_V1_0. This indicates that the event was generated by MSV1_0.
• 4776 / TargetUserName: the account considered in the credential-validation attempt (Logon Account). Read it together with Status for success/failure; the account name does not establish target-resource access.
• 4776 / Workstation: Source Workstation, the origin of the logon attempt. In Microsoft’s CLIENT-1 → SERVER-1 example it contains CLIENT-1; the SERVER-1 destination is absent from this event. The name alone proves neither relay nor trustworthy machine identity.
• 4776 / Status: result code ('Error Code'). 0x0 codes for success, non-zero values ​​code for the reason for failure (e.g. 0xC0000234 in the documentation example, account is locked).
• 4624 / LogonType: 3 (Network) for NTLM network session. Along with LogonProcessName 'NtLmSsp' and AuthenticationPackageName 'NTLM', it points to an NTLM network session.

Reading two events together

The most common mistake is to look for NTLM access in a single event. However, credential validation (4776) and the location where the session is opened (4624) are on different machines. Seeing 4776 on the DC and not seeing 4624 on the target resource server, or vice versa, is often a collection gap, not an attack.

The correct reading is to match two events within the same user and recent time window and query the consistency of the source/target names. This enables both understanding legitimate multi-hop access and isolating anomalous patterns.

Why 4776 does not show the target

4776 Workstation identifies the authentication source of the logon attempt; it does not by itself identify the member server forwarding validation to the DC or the accessed target. In Microsoft’s example of CLIENT-1 authenticating to SERVER-1 with a domain account, Workstation is CLIENT-1; SERVER-1 is absent from 4776.

Do not infer that a relay intermediary must appear in this field. Evaluate the account/source in 4776 alongside target 4624 and relevant network/service observations; matching names or times alone establish neither the same exchange nor relay.

Detection logic · KQL

// NTLM erişiminin iki ayrı makinedeki izini eşleştirir: DC'de kredi doğrulama (4776)
// ile erişilen hedef (resource) sunucudaki NTLM ağ oturumu (4624, LogonType 3, NtLmSsp).
// SourceWorkstation (4776) ile WorkstationName (4624) farki sezgisel bir isarettir;
// tek basina saldiri/relay kaniti degildir, yalnizca korelasyonu gorunur kilar.
let cred = SecurityEvent
  | where EventID == 4776 and Status == "0x0"
  | project CredTime = TimeGenerated, TargetUserName, SourceWorkstation = Workstation, Status;
let logon = SecurityEvent
  | where EventID == 4624 and LogonType == 3 and LogonProcessName has "NtLmSsp"
  | project LogonTime = TimeGenerated, DestServer = Computer, TargetUserName, WorkstationName, IpAddress;
cred
| join kind=inner logon on TargetUserName
| where abs(datetime_diff('second', LogonTime, CredTime)) <= 10
| where SourceWorkstation != WorkstationName
| project CredTime, LogonTime, TargetUserName, SourceWorkstation, WorkstationName, DestServer, IpAddress, Status

Query assumptions

• Collecting domain-account 4776 on the DC requires Audit Credential Validation coverage; collecting 4624 on the target retarget resource server requires Audit Logon coverage. Verify collector field mapping and collection coverage at both sources separately.
• The SecurityEvent table and field names (EventID, TargetUserName, Workstation, Computer, LogonType, LogonProcessName, IpAddress) are written according to this schema; Domain names may vary on different collection line.
• Joining is done via TargetUserName; If there are multiple concurrent sessions for the same user, the 10-second window may produce false matches.
• SourceWorkstation vs WorkstationName difference can also occur in normal scenarios (name resolution, multi-named hosts); This is a signal, not a decision.
• The 4776 side selects only successful validation with Status=0x0. Failed 4776 events require separate analysis; matching names and times do not prove the same authentication exchange.

False positives

• Legitimate multi-hop access (one server accessing another server via NTLM on behalf of the user) can cause the resource and workstation name to appear differently.
• Name resolution and NetBIOS/DNS differences may cause the Workstation field to be written differently than expected; This produces inequality without a true relay.
• On clients behind a load balancer, proxy or VPN, IpAddress and workstation information can hide the real source, resulting in unexpected matches.
• With unsynchronized clocks or collection delays, the ten-second window may miss legitimate related events or combine unrelated ones.

Hardening

• Make NTLM usage visible first: Measure which servers and accounts depend on NTLM with 'Restrict NTLM: Audit' policies, then gradually move to blocking.
• Reduce relay risk with protocol-appropriate signing/binding: require SMB session signing; use LDAP signing and channel binding with compatible clients. Check Windows-version defaults and client support before enforcing requirements.
• On TLS-using services that support Extended Protection for Authentication (EPA), enable EPA to bind authentication to the target/channel; audit mode alone does not replace enforcement.
• Schedule aggregation of 4776 (DC) with 4624 (target resource server); Without correlation, neither one alone can make the relay seem reliable.
• Point to Kerberos wherever possible (correct SPN, up-to-date DNS); Inventory and reduce paths falling into NTLM.
• Verify dependencies in the test environment before disabling NTLM altogether on critical servers; otherwise legitimate access will be cut off.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4776</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14336</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:12.503118600Z" />
    <EventRecordID>90714</EventRecordID>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="Workstation">WKSTN-07</Data>
    <Data Name="Status">0x0</Data>
  </EventData>
</Event>

Two reality checks

Assumption: When I connect to a server with NTLM, my password or NT hash goes to that server and is verified there.

In fact: The password does not go through any messages; The server does not know the NT hash either. The client simply sends a response (NTProofStr) generated with its secret to the server challenge. In the domain account, the server cannot verify this response itself; it passes through to the DC via Netlogon; The actual verification happens at DC and 4776 is generated there.

Assumption: If the client generated the correct answer, that answer is valid only on the server it wants to connect to.

In fact: Basic NTLM challenge-response does not by itself provide target/channel binding across every protocol. Relay controls are protocol-specific: SMB signing protects session messages with the negotiated key; LDAP signing protects message integrity; EPA/channel binding binds authentication to the target/channel on supported TLS services. Support and defaults are not the same in every environment.

Sources

• Microsoft Open Specifications · [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol
  §1.3 message flow (NEGOTIATE/CHALLENGE/AUTHENTICATE); §2.2.1 message types and MessageType 0x1/0x2/0x3; §2.2.1.1 NEGOTIATE, §2.2.1.2 CHALLENGE (ServerChallenge 8 bytes), §2.2.1.3 AUTHENTICATE (NtChallengeResponse).
• Microsoft Open Specifications · [MS-APDS]: Authentication Protocol Domain Support
  §1 pass-through authentication between server and DC over Netlogon; validation of the NTLM credential at the DC (server-to-DC).
• Microsoft · NTLM overview
  NTLM challenge-response model, the server not keeping the credential, and validation for domain accounts being carried to the DC; Kerberos migration recommendations.
• Microsoft · 4776(S, F) The computer attempted to validate the credentials for an account
  EventData fields: Authentication Package (PackageName), Logon Account (TargetUserName), Source Workstation (Workstation), Error Code (Status 0x0 success); the event is generated only on the machine authoritative for the credential.
• Microsoft · 4624(S) An account was successfully logged on
  Meaning of Logon Type 3 (Network), Logon Process 'NtLmSsp', and Authentication Package 'NTLM' fields in an NTLM network session.
• Microsoft Open Specifications · [MS-NRPC]: Netlogon Remote Protocol
  Netlogon secure channel between server and DC; interface family carrying pass-through authentication (general scope).
• Microsoft Learn · SMB security hardening
  SMB signing prevents credential-relay attacks; Windows 11 24H2 and Windows Server 2025 require inbound and outbound SMB signing by default.
• Microsoft Learn · LDAP signing for AD DS
  LDAP signing protects message integrity; channel binding binds application authentication to TLS; defaults vary by Windows Server version and deployment type.
• Microsoft Learn · Supporting Extended Protection for Authentication (EPA) in a service
  Session-key signing/encryption protects authenticated traffic; EPA/channel binding protects forwarding over TLS; audit without enforcement does not protect against relay.
• MS-NLMP AUTHENTICATE_MESSAGE
  EncryptedRandomSessionKey KEY_EXCH field-length condition
• MS-NLMP Client Receives a CHALLENGE_MESSAGE
  MsvAvTimestamp or Currenttime; conditional KEY_EXCH/sign/seal
• RODC cached and forwarded authentication
  Cached permitted credentials versus uncached forwarding