|Informative Information for the Uninformed
As described earlier in this paper, the second part of the password, just as the first one, is used to encrypt a known string to form an 8 byte LM hash. Knowing the challenge sent from the server to the client, it is possible to deduce the final 2 bytes of that LM hash out of the third chunk of the NTLM hash. Doing so was explained in section 2.2.
So the final 2 byte of the LM hash of the second half of the original password are known. If a similar approach to breaking the first half of the password is being applied now, looking up the second part of the password as well becomes quite possible.
The key here is to create a set of precomputed LanMan tables that are sorted by the final 2 bytes of the LM hash. So once the final 2 byte of the LM hash are known, a file is thus identified that contains plaintext passwords that when hashed result in a matching 2 byte sequence at the end.
The second chunk of the NTLM hash is derived from 6 bytes that are the start of the hash of one of the plaintext passwords out of the file that just got identified, and a single byte, the first one, which is the final byte of the first LM hash.
Considering the first part of the password broken, that byte is known. So all that's left to do is hash all the possible passwords in the file, fit the single known byte into the first position of a string and concatenate this one with 6 bytes from the just created hash, hashing those 7 bytes again and comparing the result to the second chunk of the NTLM hash. If it matches, the second part of the password has been broken too.
Even if looking up the first part of the password didn't prove successful, the method may still be applied. The only change would be that up to 256 possible values for the first byte would have to be computed and tested as well.
What's really interesting to note here, is that the second set of tables, the sorted LM tables, unlike the first set of NTLM tables, does NOT depend on a certain challenge. It will work with just any challenge, which is usually sniffed or aquired from the wire when the password hash and the username are being taken.