Impossible NTLMv2 hash format with Responder lm option
While doing an internal assessment, I stumbled upon a very weird looking NTLMv2 hash (I will not use the "Net-NTLM" terminology but I'm talking about the NTLM protocol ) while using Responder with the --lm option (which afaik/what I read in the code, forces the uses of legacy NTLM authentication server) :
For this client response (or often mistakenly called "client hash"), I have labelled :
In yellow the server challenge.
In green the client ciphertext.
In blue the reserved part of the "blob", or more formally called "NTLM_client_challenge".
In pink, what is supposed to be a timestamp in WindowsNT format.
In purple, what is supposed to be the client random nonce.
In red and orange, respectively what is supposed to be the AvPair ID and Value.
The thing is, this hash does not make sense according to the understanding I have of NTLMv2 hash.
According to the MS-NLMP, MS's official documentation on the subject, the AvID 0x0000, 0x0001 and 0x0002 must be present (2.2.2.1). They are not here.
It's missing the 0x0002's AvPair entire value.
The timestamp makes no sense, https://www.epochconverter.com/ldap does not give anything logical contrary to the any other timestamp I tried decoding.
The timestamp doesn't seem to be fully random either:
This weird response is fully valid. I have been able to bruteforce it locally like a normal NTLMv2 response, and it is relayable (tested with rbcd with relay to LDAPS).
To give full insights on the last 5-responses image: this is the client (SRV01, Windows Server 2016) responses after being SMB coerced, but each time with different LmCompatibilityLevel values (1 through 5, skipped 0), so this happens as soon as the client is forced to do NTLMv2 with the legacy NTLM server (forced by --lm).A note that might be important too to understand the issue: SMB signing on the client must be off for this to work.
Does anyone have any idea what is happening on the Windows client side? I made sure that this is not a Responder issue, this is truly the response it gets.
I might dig into the diff between the packets leading to the client response if I have time.
Cheers
