3

With regards to the following question about the feasibility of (brute|dictionary|rainbowtable)-forcing an NTLMv2 hash: How feasible is it for an attacker to brute-force an NTLMv2 response captured off the network?

..I'm trying to understand how is it that tools like Hashcat and John-the-ripper are able to bruteforce them using wordlists.

How is that hashchat and JTRare able to do this to an NTLM hash without knowing the Server Challenge (SC) and Client Challenge (CC, CC*) bits in the formula?..

All those 3 values are supposed to make the hash ‘Random’.

Or is it that those tools brute force the 8-byte SC and and CC, CC* values as well?

Articles listing how the attack is done can be found everywhere so I'm trying to understand the actual mechanism behind the attack. e.g.: https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/

Vicer
  • 113
  • 8
  • 1
    potential duplicate? https://security.stackexchange.com/questions/33479/ntlmv2-resistance-to-bruteforcing Or at least your answer can be derived there? – schroeder May 01 '18 at 14:16
  • Where are you getting that these tools can do it without the challenge? If you can capture the hash, you can capture the challenges too. – JimmyJames May 01 '18 at 14:50
  • @JimmyJames, that's a very a good point I've been wondering as well. But looking at the captured hash which gets fed into the bruteforce tool (eg John) all I can see is the NTLMv2 hash and no more info. Maybe I am missing something. Is there any doco that explain whether tools like responder outputs the SC and CC along with the hash? – Vicer May 01 '18 at 21:20
  • @schroeder, actually that question asks about the feasibility of an NTLM hash crack where I am asking about the specifics of how it's actually getting cracked successfully (even given a known password as PoC) when the randomisation values such as SC, CC are supposed to have salted it. – Vicer May 01 '18 at 21:22

1 Answers1

1

I actually spent a good deal of time looking into this when I got a little sidetracked one day. The NTLM suite of protocols is complicated. There are many versions out there and some have distinct weaknesses such as the one I discussed in this question a while back. This reference page provides a lot of technical details and code examples on how to build and verify these messages.

With the specific attack you point to one factor is that the attacker controls the server. That means that the attacker can see all the challenges and actually control things such as the server challenge. It's also possible for the server to attempt negotiate to a weaker version of the protocol but it's not clear if that's part of it. You could tell if you want to go through all the packets in the article.

JimmyJames
  • 2,956
  • 2
  • 16
  • 25
  • Thanks for your response. Yes I initially thought the attacker tool that acts as the server (e.g. responder) would pass on the SC and CC values it gather from the victim over to the brute-force tool like JTR or hashcat. But this was not the case and JTR was able to crack the password with simply the input of the recorded NTLMv2 hash. This is what lead me to wonder whether they actually brute-force the random SC, CC & CC* bytes as well. As you said attacker server could be making it easier by negotiating to weaker versions of the hashes used. Thanks for resources I will follow up further. – Vicer May 01 '18 at 21:13
  • @Vicer I wouldn't think that would work. I'll look again and see if I can make sense of it. – JimmyJames May 01 '18 at 21:36
  • 1
    @Vicer I found another reference supposedly demonstrating this but it doesn't explain how: https://zone13.io/post/cracking-ntlmv2-responses-captured-using-responder/ I can't imagine these are trying all the possible challenges. It looks to me that the entire response is being put into the hash file. I need to check to be sure but I think it contains the challenges. Could it be that these tools understand and detect the NTLMv2 format? – JimmyJames May 01 '18 at 21:50
  • I think you are on to it there. I checked the article you mentioned and the ouput format seems to be of -> username:domain:SC:response_hash. Look at https://crack.sh/netntlm/ at it's the same SC challenge used. Now reponder nowadays is configured to randomise the SC as you can see in /etc/responder/Responder.conf -> "Challenge = Random". But it seems to output the SC it used as the third portion of the output as mentioned above. Thanks, a good find! I think this explains it – Vicer May 01 '18 at 21:59
  • so the output from responder could be in the format of - "username:domain:SC:CC*:full_response_hash" – Vicer May 01 '18 at 22:03