Why are the NT hash and the NTLMv2 response not the same thing?

1. Core mechanism

The decision point is when someone looking at an NTLM event or a captured response asks 'what material do I have and what can I do with it?' Although NT hash, response and SessionBaseKey derive from each other, they have different security values; Substituting one for the other leads to wrong conclusions on both Red and Blue's part.

Interfaces and specifications

• NT hash: MD4(UTF-16LE(password)). It is not salted and derives only from password; the same password yields the same NT hash on every account. The password is fixed unless changed; In the domain account, it is kept in the directory on the DC side, in the local account it is kept in the SAM. It is credential-equivalent: if captured, it can be used as proof of identity without knowing the password (pass-the-hash).
• NTOWFv2: HMAC_MD5(NT hash, UNICODE(Uppercase(User) + UserDom)). In NTLMv2, this is the real key; NT derives from hash and user+domain name. 'Salt' is not random here, it is the username and domain name.
• NTProofStr is the proof component of the response. Fresh challenge inputs affect it; timestamp ownership is conditional on server TargetInfo. The wire response carries NTProofStr with temp, not the NT hash.
• temp / NTLMv2_CLIENT_CHALLENGE: structure embedded in response; Contains RespType 0x01, timestamp (FILETIME), 8-byte client challenge and TargetInfo AV_PAIRs. These variables explain why Response changes every time.
• SessionBaseKey: HMAC_MD5(NTOWFv2, NTProofStr). It is the basis of session key derivation; It does not go open on the wire and cannot be read directly from the response.

NT hash: unsalted, password-derived, credential-equivalent

The NT hash is a one-way digest of the password: MD4 is applied to the UTF-16LE encoding of the password. There is no mere salting or iteration; the same password always returns the same NT hash. This means that the hash depends on the password, not the account: two different accounts sharing the same password have exactly the same NT hash. The NT hash is therefore a secret as sensitive as the password itself: whoever knows it can authenticate without knowing the password.

This feature is called 'credential-equivalent' and is the basis of the pass-the-hash attack. If the attacker has the NT hash, he has the only input needed to produce the correct response in the NTLM exchange; There is no need to crack the password.

The NT hash does not change from session to session. Although the responses seen in an environment may be different, the NT hash behind them is the same until the password is changed. This is the main difference between response and NT hash: one is a session secret, the other is a persistent secret. Password reuse creates a direct risk here: since accounts that share the same password have the same NT hash, compromise of one hash will affect all accounts that share that password.

NTLMv2 response: NTProofStr MAC plus temp blob

NtChallengeResponse carries NTProofStr together with temp. ClientChallenge inside temp is generated by the client. TimeStamp does not always come from the client clock: when CHALLENGE TargetInfo contains MsvAvTimestamp, that server value is copied; otherwise Currenttime is used. This distinction matters when interpreting response variation or clock differences.

Fresh server and client challenges make responses differ across normal exchanges; timestamp ownership follows the condition above. The same password can yield the same NT hash while exchange inputs differ. Captured bytes do not refresh themselves when replayed; fresh inputs and a replayed record are different things.

NTProofStr is a MAC; It does not contain the NT hash and the NT hash cannot be obtained by reversing it. Cannot read NT hash or SessionBaseKey directly from Response. So capturing a response is not the same as capturing the NT hash.

# MS-NLMP 3.3.2 (NTLMv2), symbolic notation; this is not real byte generation.
# Key: derived from the NT hash, salt is user+domain, no iteration.
NTOWFv2 = HMAC_MD5( MD4(UNICODE(Passwd)), UNICODE( Uppercase(User) + UserDom ) )

# temp: client challenge structure embedded in the response (time, client challenge, target information)
temp = RespType(0x01) || HiRespType(0x01) || Reserved || TimeStamp(8) ||
       ClientChallenge(8) || Reserved || TargetInfo(AV_PAIRs) || Reserved

# NTProofStr: MAC over the server challenge, produced with a key derived from the NT hash
NTProofStr = HMAC_MD5( NTOWFv2, ServerChallenge || temp )

# NtChallengeResponse on the wire = NTProofStr (16 bytes) || temp
NtChallengeResponse = NTProofStr || temp

# Session key material; derived from the NT hash, does not travel in cleartext on the wire
SessionBaseKey = HMAC_MD5( NTOWFv2, NTProofStr )

Keeping SessionBaseKey and three separate

SessionBaseKey is a third material derived from NTOWFv2 and NTProofStr with HMAC-MD5 and is the basis for session signing/sealing keys. It does not go open on the cable; Someone looking at response cannot directly deduce it. The party that knows the NT hash can recalculate the SessionBaseKey.

It is important in practice to keep these three concepts separate. Someone who has an NTLMv2 response automatically has neither the NT hash nor the SessionBaseKey; At most, if the password is weak, it can try to find the password by guessing offline. Someone who has an NT hash can both produce a response and derive the SessionBaseKey.

In short, the type of material determines what the attacker can do. There is no such thing as 'NTLM material'; NT hash, session response and SessionBaseKey open different capabilities. This distinction directly affects attack classes on the Red side and event interpretation on the Blue side.

State and data flow

1. When the password is entered, the client calculates the NT hash: MD4(UTF-16LE(password)); This value is fixed until the password is changed.
2. The client derives the NTOWFv2 key from the NT hash and the user+domain name (HMAC-MD5, salt = user+domain).
3. FS01 sends ServerChallenge and TargetInfo. WS01 generates ClientChallenge. TimeStamp is copied from FS01 when MsvAvTimestamp is present; otherwise WS01 uses Currenttime.
4. Sets up the client temp structure (client challenge, time, TargetInfo) and calculates NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge || temp).
5. In wire NtChallengeResponse = NTProofStr || temp is moved; NT hash and SessionBaseKey are not sent explicitly.
6. SessionBaseKey depends on two inputs: ResponseKeyNT and NTProofStr. It is derived at the client and validator; reading a response is not reading the key.
7. The verifier (DC in the domain account) recalculates and compares NTProofStr from the same NT hash.
8. With a successful logon and applicable auditing, the target may show 4624. LmPackageName/KeyLength describe package and session-security context; they are not NT hash or SessionBaseKey.

2. Exploitation

Broken trust assumption

The assumption being broken is: 'Capturing an NTLMv2 response is the same as capturing that account's NT hash or session key.' In fact, response is an irreversible MAC; At most, if the password is weak, the password can be found by guessing offline. Attacks that require the NT hash (pass-the-hash) work with the hash itself, not with the response.

Technical prerequisites

• For offline password guessing, the attacker must have caught the NTLMv2 response (including the server challenge) and the target password must be weak enough to be found by dictionary/canonical try; This method is not practical for strong passwords.
• To pass-the-hash, the attacker must have possession of the NT hash itself; this hash cannot be derived from the response, it must be obtained from a separate source (e.g. identity store on an endpoint).
• The fact that Response is NTLMv2 (not v1/LM) makes the attack difficult; The downgraded NTLMv1/LM material is much weaker and imposes different limits.
• Offline prediction does not require additional authorization on the network; The attacker only works offline with the data he captures, so detection should look at how the capture is possible, not the network.

Exploitation mechanism

It is necessary to distinguish two classes of attacks. The first is offline password guessing: the attacker chooses a password candidate to verify the captured NTProofStr, derives NT hash and NTOWFv2 from it, recalculates HMAC-MD5 with the same server challenge and temp; If the result is equal to the captured NTProofStr, the password has been found. The lack of iteration in NTLMv2 and the fact that salt is user+domain makes this experiment faster; The only real obstacle is the strength of the password. Second, pass-the-hash: this attack uses the NT hash itself, not the response; The party who has the hash authenticates without ever knowing the password, as it can produce the correct response to any server challenge. A captured response does not grant this ability; The two work with different inputs.

What does the captured response give and what does it not give?

An attacker who captures an NTLMv2 response has an irreversible MAC and accompanying server/client challenges. This material acts as an 'oracle' to verify the password: if a password candidate is correct, the same NTProofStr is generated. But this does not reveal the NT hash; False candidates do not leak any information.

Therefore, the response captured in a strong, unpredictable password is practically useless. The value of the attack depends on the weakness of the password, not the cryptographic strength of the response. The inference that 'Response was caught, account was dropped' is wrong.

Why pass-the-hash is a world apart

Pass-the-hash occurs because the NT hash is credential-equivalent. If the attacker has the hash, he produces the correct response to every server challenge given by the target server; There is no need to know or crack the password. There is no 'breaking' phase here at all.

The critical distinction is that the NT hash required for pass-the-hash cannot be obtained from a captured wire response. The hash must come from somewhere else (the identity store in a system). Therefore, 'capturing a response' and 'capturing a hash' are different problems in terms of defense and are handled with different controls.

3. Defense & Detection

Telemetry scope

• 4624 (Audit Logon) Generated in NTLM network session with LogonType 3 and LogonProcessName 'NtLmSsp'; This event indicates 'which version of NTLM was used', not which secret material was derived from.
• LmPackageName ('Package Name (NTLM only)') is only populated when AuthenticationPackageName is 'NTLM'; values ​​can be 'NTLM V1', 'NTLM V2' or 'LM'. This area is the primary signal in downgrade hunting.
• KeyLength describes the NTLM session-security key. It is 0 for Kerberos, including Kerberos selected through Negotiate; Negotiate alone does not imply zero. A recorded length is not a leaked secret.
• 4624 events are generated on the originating server; NT hash, NTProofStr or SessionBaseKey are not included in any event fields. It does not follow from the incident that 'the secret has been uncovered'.

Events and relevant fields

• 4624 / AuthenticationPackageName: 'NTLM' value indicates NTLM login; The meaningfulness of the LmPackageName field depends on this value.
• 4624 / LmPackageName: 'NTLM V2' is the expected strong state; 'NTLM V1' or 'LM' is a sign of downgrade or legacy client and is the weakness to hunt for.
• 4624 / KeyLength: NTLM session security key length (128 strong, 56 weak). Low values ​​may signal poor configuration; The incident does not constitute a revelation of a secret.
• 4624 / LogonType 3 + LogonProcessName 'NtLmSsp': distinguishes NTLM session over the network; It is separated from local/interactive sessions by these fields.
• 4624 / TargetUserName and TargetDomainName: NTLM authenticated account; It gives information about 'which identity logged in', not 'which secret was derived'.

Event points to 'version', not 'secret'

The 4624's NTLM fields (LmPackageName, KeyLength) tell which version and key length is used. This is valuable information because it reveals downgrades and poor configurations. But these fields do not contain secret material such as NT hash, NTProofStr or SessionBaseKey; It does not follow from the incident that a secret has been 'revealed'.

The example monitoring policy expects NTLM V2 and a 128-bit session-security key. LM/NTLM V1 or a different recorded length warrants review. KeyLength=0 alone proves neither a weak exchange nor an attack; interpret the package, negotiated session security and collection context.

Difference between downgrade hunt and secret hunt

There are two different questions on the Blue side. The first is 'are you using a weak version of NTLM' (downgrade hunt): the answer to this is given by LmPackageName/KeyLength at 4624 and leads to fixing the configuration. The second is 'has a secret been compromised': the answer to this is not sought in NTLM session events, but in identity store access and credential theft telemetry.

It is a common mistake to confuse these two questions. The NTLM session event neither proves pass-the-hash nor indicates that a hash was stolen; it only documents which protocol version is logged in. The question of secret retrieval is pursued through separate sources.

Detection logic · XPath

<!-- Example policy: NTLM V2 and 128-bit session security are expected. -->
<!-- LM/NTLM V1 or KeyLength != 128 is selected for review, not as attack/secret evidence. -->
<!-- Interpret KeyLength=0 in context; it does not alone establish weak NTLM. -->
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)] and EventData[Data[@Name='AuthenticationPackageName']='NTLM'] and EventData[Data[@Name='LmPackageName']='NTLM V1' or Data[@Name='LmPackageName']='LM' or Data[@Name='KeyLength']!='128']]</Select>
  </Query>
</QueryList>

Query assumptions

• The query is written against the Windows Event Viewer/wevtutil XPath subset and runs on a single machine's local Security log; The central collection scheme is different.
• The Audit Logon subcategory must be active and 4624 events must contain the LmPackageName field; This field is filled only when AuthenticationPackageName is 'NTLM'.
• Field names (AuthenticationPackageName, LmPackageName) are according to the 4624 Version 2 schema; Additional fields may be available in different Windows versions.
• The query only flags version/key vulnerability; does not determine whether a session is malicious or not.
• The selector’s 128-bit expectation is an example monitoring policy, not a universal weakness threshold. AuthenticationPackageName=NTLM prevents applying this KeyLength interpretation to Kerberos/Negotiate. It has not been executed in Windows Event Log.

False positives

• Legacy clients or applications can legitimately use NTLM V1; This is a sign of technical debt, not attack.
• Some software/appliances do not support NTLM V2 so they connect with low KeyLength; Might be an expected exception.
• Weak NTLM settings may have been temporarily enabled during testing and maintenance processes; Alarm alone without context is misleading.
• Optionally, these events may be expected noise only in environments where exceptions are defined for certain accounts.

Hardening

• LAN Manager authentication level 'Send NTLMv2 response only. Reject NTLMv1/LM by setting 'Reuse LM & NTLM' (level 5); Prevent 'NTLM V1'/'LM' from appearing in 4624.
• Prevent LM hashes from being stored with NoLMHash policy; ensure that old, very poor material is not produced at all.
• Strengthen password policies: The only real obstacle to NTLMv2 response offline guessing is password strength; Require long, unpredictable passwords/secret keys.
• Use high-entropy managed identities like gMSA for service and automation accounts; thus, offline prediction becomes practically impossible.
• Prevent password reuse: since accounts sharing the same password have the same NT hash, disclosure of a single hash affects multiple accounts; Require a unique, high-entropy password/secret, especially on privileged and local admin accounts.
• Routinely hunt for LmPackageName and KeyLength: Inventory and remove requests and applications that produce 'NTLM V1'/'LM' or low KeyLength.
• Where possible, reduce NTLM altogether and move towards Kerberos; Measure, justify and gradually close paths that fall within NTLM.

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>4624</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:12.902551700Z" />
    <EventRecordID>552013</EventRecordID>
    <Channel>Security</Channel>
    <Computer>FS01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-5-21-1004336348-1177238915-682003330-2117</Data>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetLogonId">0x1f4c7a9</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">NtLmSsp </Data>
    <Data Name="AuthenticationPackageName">NTLM</Data>
    <Data Name="WorkstationName">WKSTN-07</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">NTLM V2</Data>
    <Data Name="KeyLength">128</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">203.0.113.24</Data>
    <Data Name="IpPort">49712</Data>
    <Data Name="ImpersonationLevel">%%1833</Data>
  </EventData>
</Event>

Two reality checks

Assumption: Capturing an NTLMv2 response is the same as capturing the NT hash of that account; The hash is extracted from the response.

In fact: NTLMv2 response is not a single MAC: NtChallengeResponse = NTProofStr || carried on the wire is temp; NTProofStr is a 16-byte HMAC-MD5 MAC, temp is the client challenge/timestamp/TargetInfo blob that generated it. No part of it contains the NT hash and cannot be converted back into an NT hash. The captured response is at most a verification tool for offline password guessing; If the password is strong, it is practically useless. Pass-the-hash, which requires an NT hash, works from the hash itself, not from the response.

Assumption: Because NTLMv2 is salted and recursive, it is resistant to offline guessing like modern password hashes.

In fact: In NTLMv2, 'pure' is not random, it is user+domain name and there is no iteration (slowdown) in key derivation. Therefore, password candidates can be tried very quickly against a captured response. The only real protection is the strength of the password; NTLMv2's structure does not slow down offline prediction.

Sources

• Microsoft Open Specifications · [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol
  §3.3.2 NTLMv2 calculation: NTOWFv2 = HMAC_MD5(MD4(UNICODE(Passwd)), UNICODE(Uppercase(User)+UserDom)); NTProofStr = HMAC_MD5(ResponseKeyNT, ServerChallenge || temp); SessionBaseKey = HMAC_MD5(ResponseKeyNT, NTProofStr).
• Microsoft Open Specifications · [MS-NLMP] §2.2.2.7 NTLMv2_CLIENT_CHALLENGE
  §2.2.2.7 NTLMv2_CLIENT_CHALLENGE (temp): RespType 0x01, HiRespType 0x01, TimeStamp (FILETIME), ChallengeFromClient (8 bayt), AvPairs; §2.2.2.8 NTLMv2_RESPONSE = Response(NTProofStr,16) + client challenge.
• Microsoft · NTLM overview
  NTLM challenge-response model, the NT hash being a fixed digest derived from the password, and the password not going over the wire during authentication; Kerberos migration guidance.
• Microsoft · 4624(S) An account was successfully logged on
  Package Name (NTLM only) / LmPackageName values ('NTLM V1','NTLM V2','LM'); Key Length; Authentication Package 'NTLM'; Logon Type 3; fields meaningful only in an NTLM session.
• Microsoft · Access tokens
  Access token concept created as the result of successful authentication; identity represented by the token after logon (authorization context independent of NT hash/response).
• MS-NLMP Client Receives a CHALLENGE_MESSAGE
  MsvAvTimestamp or Currenttime; conditional KEY_EXCH/sign/seal