Downgrade to NetNTLMv1 in the challenge-response

[obilodeau]

Now that we can capture NetNTLM hashes (#367), someone from pentest told me that we should test downgrading to NetNTLMv1. This version is easier to crack and you can even rainbowtable it. Some tests would be required and its possible that some client reject the downgrade.

To check: https://githubmemory.com/repo/lgandx/Responder/issues/149

@ecapson also said responder doesn't perform downgrade attacks with this (not sure if on RDP):

responder --disable-ess

[lubiedo]

ESS disabling on responder: https://github.com/lgandx/Responder/pull/163

According to the PR, the downgrade from NTLMv2 to NTLMv1 is done via the negotiation flags in the CHALLENGE message, as it is the options that the server supports. The flag that is unset in this case is the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY (more info). Here's the description:

P (1 bit): If set, requests usage of the NTLM v2 session security. NTLM v2 session security is a misnomer because it is not NTLM v2. It is NTLM v1 using the extended session security that is also in NTLM v2. NTLMSSP_NEGOTIATE_LM_KEY and NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY are mutually exclusive. If both NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY and NTLMSSP_NEGOTIATE_LM_KEY are requested, NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY alone MUST be returned to the client. NTLM v2 authentication session key generation MUST be supported by both the client and the DC in order to be used, and extended session security signing and sealing requires support from the client and the server in order to be used.<25> An alternate name for this field is NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY.