2

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/

  • 1
    potential duplicate? security.stackexchange.com/questions/33479/… Or at least your answer can be derived there? – schroeder May 1 '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 1 '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 1 '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 1 '18 at 21:22
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.

  • 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 1 '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 1 '18 at 21:36
  • 1
    @Vicer I found another reference supposedly demonstrating this but it doesn't explain how: zone13.io/post/… 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 1 '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 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 1 '18 at 21:59
  • so the output from responder could be in the format of - "username:domain:SC:CC*:full_response_hash" – Vicer May 1 '18 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.