|Informative Information for the Uninformed
Now there's a big problem concerning the creation of the NTLM lookup tables. The first 8 byte of the final hash are derived from the first 7 byte of the LM hash, which are derived from the first 7 byte of the plaintext password. Creating tables to match the first 8 byte of the NTLM hash to the first 7 bytes of the password is thus possible, but the same tables do not work for the second or even third block of the 24 byte NTLM hash.
The second 8 byte chunk of the hash is derived from the last byte of the first LM hash, and the first 6 byte of the second LM hash. This first byte adds 256 possible values to the second LM hash. While the first 8 byte chunk of the 24 byte LM hash stems purely from a LM hash of a plaintext password, the second 8 byte chunk stems from an undetermined byte and additional 6 byte of a LM hash.
Being able to look up the first up to 7 bytes of the password is a big advantage already though. The second part of the password, if it's longer than 7 bytes at all, can now usually be easily guessed or brute forced. Having determined that the password starts with "ILLUSTR" for example, most often it may end with "ATION" or "ATOR". On the other hand, when applying the brute force approach to this example after looking up the first 7 bytes, it'd require to brute force 4-5 characters until the final password is revealed. Even off-the-shelf hardware does this in seconds. While taking a bit longer, even brute forcing 6 bytes is nothing one couldn't sit out. 7 bytes, however, requires an inconvenient amount of time. That's where being able to look that part up as well would really come in handy. Well, guess what. There is a way.