Are rainbow tables a viable tool for cracking NTLMv2 hashes?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.