3

Background

I am unclear about the difference between NTLM hashes and the NTLM protocol, regardless of version.

My tentative understanding is that there is such a thing as an "NTLMv2 hash", and that these hashes, being unsalted, would be viable targets for pre-computation attacks using rainbow tables.

That being so, I was surprised to find that a web search for "NTLMv2 rainbow tables" brings up no showing published rainbow tables for NTLMv2. The Distributed Rainbow Table Project created rainbow tables for NTLM but not, as far as I can see, for NTLMv2. Nor it appears, did its community show much interest in generating NTLMv2 rainbow tables. Maybe this is because NTLMv2 rainbow tables are more expensive to compute, and no-one who has invested in generating them has so far been willing to publish any?

Questions

Is there such a thing as an "NTLMv2 hash", and if so, would these be viable targets for pre-computation attacks using rainbow tables? If not, then is that because there is no such thing as an "NTLMv2 hash", or because there is, but rainbow tables are not viable attacks against them?

2

When considering the risk applicable to brute-force attacks against user passwords in a Windows environment it is worth considering the nature of the compromise that will enable an attacker to capture a hash.

For an attack that relies on a network capture of hashes during user authentication, rainbow tables will not be effective - the NTLMv2 protocol provides the additional hashing calculations that effectively introduces a salt (as described in the previous answer).

However, if an attacker can successfully extract password hashes from the SAM database the same is not true. The stored 'NT hashes' have not had additional hashing operations / salting applied.

The following quote is from this Microsoft article:

The NT hash of the password is calculated by using an unsalted MD4 hash algorithm. MD4 is a cryptographic one-way function that produces a mathematical representation of a password. This hashing function is designed to always produce the same result from the same password input, and to minimize collisions where two different passwords can produce the same result. This hash is always the same length and cannot be directly decrypted to reveal the plaintext password. Because the NT hash only changes when the password changes, an NT hash is valid for authentication until a user’s password is changed.

Note To protect against brute-force attacks on the NT hashes or online systems, users who authenticate with passwords should set strong passwords or passphrases that include characters from multiple sets and are as long as the user can easily remember.

2

NTLMv1 or NTLMv2 is a Windows Challenge-Response authentication protocol used in authenticating users in interactive and non-interactive logons. Interactive logons and non-interactive logons are explained here

https://msdn.microsoft.com/en-us/library/gg604699.aspx and https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

NTLMv1 and NTLMv2 authentication protocols have vulnerabilities like pass-the-hash, reflection and relay attacks but are immune to Rainbow Tables attacks.

NT Hash is referred to as NT One-Way Function (NTOWF) in MSDN Documentation on NTLMv1 and NTLMv2 and uses the MD4 or MD5 hashing algorithm to obtain the hash from a user’s password. NTOWF uses MD4 or MD5 hashing algorithms to compute the hash from a user’s password. The NT Hashes of all users in a Windows domain are stored in the ntds.dit file on the Domain Controllers. While the NT Hash of user’s password can also be retrieved from the Security Account Manager (SAM) and SECURITY Registry hives of Windows systems they interactively logon.

NTLM is often used interchangeably to refer the NTLM Challenge-Response Protocol and the NTOWF, which is the root cause of this confusion.

The lack of salting in storing users password NTOWF on Windows systems or Domain Controllers makes it vulnerable to Rainbow Tables attacks.

Here is how the string ‘hashcat’ looks like as NTOWF and when used in NTLMv1 and NTLMv2. I have borrowed this from hashcat’s example hashes webpage.

NTOWF b4b9b02e6f09a9bd760f388b67351e2b => This remains static and will be stored in identical format in the SAM or Domain Controller until the password is changed.

NTLMv2 admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030 => This authentication response will change even if the password is ‘hashcat’ as the challenge used to compute this response changes everytime the Challenge-Response protocol is negotiated.

NTLMv1 u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c => This authentication response will change even if the password is ‘hashcat’ as the challenges used to compute this response changes everytime the Challenge-Response protocol is negotiated.

Wikipedia has a good writeup on how NTLMv1 and NTLMv2 authenticate users by using their passwords (aka NTOWF) in “NT Lan Manager”.

In case you are curious why NTLMv1 and NTLMv2, the prior authenticates client to server and not vice-a-versa while the later authenticates both the client and server to each other.

  • Thanks for your answer :) "I have borrowed this from hashcat’s example hashes webpage." Please could you include a link to that webpage? – sampablokuper May 31 '17 at 20:07
  • I wasn't able to get the link in the earlier post due to the two hyper link limits. Here is the link you can refer: hashcat.net/wiki/doku.php?id=example_hashes – sh4ilesh Jun 1 '17 at 20:35
1

Even though NTLMv2 hashes do not have a true salt, it's still the case that the password alone is not the only thing being hashed. From your wiki link:

Both LMv2 and NTv2 hash the client and server challenge with the NT hash of the user's password and other identifying information. The exact formula is to begin with the NT Hash, which is stored in the SAM or AD, and continue to hash in, using HMAC-MD5, the username and domain name.

In this case the username and domain name are effectively acting as the unique salt.

As such, salted hashes which are unique are not vulnerable to attack via rainbow tables.

  • Is this true even in the case of a standalone PC, i.e. with no client or server as such? – sampablokuper Aug 30 '16 at 14:30
  • 1
    @sampablokuper - I'm not sure if it would make sense to use NTLMv2 on a standalone machine. The point of NTLM is for challenge/response so that the user's password and password hash do not need to be sent over the network. – TTT Aug 30 '16 at 14:59
  • OK, thanks. One reason to store passwords using a stronger hash is so that if the hash were ever stolen, it would be harder for the thief to recover the plaintext password. Even so, I am tentatively marking your answer as correct. – sampablokuper Aug 30 '16 at 15:07
  • @sampablokuper - The NTLMv2 is not used for storing the hash locally, which would be the attack vector of a standalone machine. So, it would not help you if you are worried about someone accessing a local machine and trying to crack the stored hash. – TTT Aug 30 '16 at 17:26

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.