Add ntlm v1/v2 challenge respose (netntlm, netntlmv2) support to hashcat plus

We have been using oclhashcat-plus for several months now to do GPU cracking of passwords obtained during pentests, and it works great!

During this period however, theres one hash type that we continually find ourselves capturing that hashcat doesnt support - NTLM challenge response hashes. We often grab these using something like the SMB capture module from Metasploit, and have always had to resort to using John the Ripper to crack them, as there is no GPU based cracker that we are aware of that will do the job. Attempting to crack these hashes using CPU when you have an 8 GPU system sitting idle is the definition of pain.

Consequently, Id like to request that support be added for NTLM challenge response version 1 and 2 (known in john as netntlm and netntlmv2) in oclHashcat-plus.

References for these protocols are here:

I'll provide a quick summary of the generation of NTLMv1, since that the bit Im most interested in at the moment. Im happy to also do this for NTLMv2 if it will help and youre interested in implementing it.

Hash creation requires a password ('hashcat' in the example below) and a variable 8 byte challenge (0x1122334455667788 is used in the example below) which is provided by the server to the client during the auth process. NTLMv1 usually generates two hashes, one based on LM hashes, and the other based on NTLM ones, although if LM hashes are disabled (e.g. via domain policy) then you wont get anything useful for the LM portion. I'll cover the generation of the NTLM version of the hash below (this is what is implemented as netntlm in john). The generation of the LM hash in NTLMv1 (implemented in john as netlm) is exactlty the same, but uses the LM hash in place of the NTLM one.

Step 1

The client converts the password (hashcat) to a NTLM hash by Unicoding the password and running it though MD4:
hashcat -> b4b9b02e6f09a9bd760f388b67351e2b

Step 2

5 null bytes are appended to the hash to take it to 21 bytes:

Step 3

The value is then split in 3 x 56 bit parts:

Step 4

Each 56 bit part is odd parity adjusted to result in 3 x 64 bit parts. (Convert to binary, break into 8 x 7 bit chunks, append an odd parity bit to each chunk to result in 8 x 8 bit chunks. Then concatenate the chunks into 64 bit parts.) :

b4b9b02e6f09a9 -> b55d6d04e6792652
bd760f388b6735 -> bcba83e6895b9d6b
1e2b0000000000 -> 1f15c10101010101

Step 5

Each of these values is then used as a key to DES encrypt the 8 byte challenge (for this example a value of 1122334455667788 is used) resulting in 3 ciphertext blocks:

b55d6d04e6792652 KEY-> DES(1122334455667788) -> 51a539e6ee061f64
bcba83e6895b9d6b KEY-> DES(1122334455667788) -> 7cd5d48ce6c68665
1f15c10101010101 KEY-> DES(1122334455667788) -> 3737c5e1de26ac4c

Step 6

The ciphertext blocks are then concatenated together to provide the final result:


Let me know if any clarification is needed
+1 for this one. Would be great to impletement.
Excellent description. Please add this as a trac ticket, I will accept it.
Cool, thanks.

Added as ticket 51.

I'll work on a description for NTLMv2 as well.
Perfect! If you are done with the description please add it as Ticket.

Oh and btw, i've already finished v1 on CPU. Porting to GPU will be next.
Wow, that's an awesomely quick response atom.

Here goes with the description of NTLMv2, added as ticket 56.

The NTLMv2 algorithm requires a username, authentication target (i.e. domain name) which is case sensitive but usually provided in all caps, a variable 8 byte server challenge and a variable sized blob of data which includes a variable client challenge and some other data like a timestamp. This last field is referred to in the Metasploit SMB capture output as NT_CLIENT_CHALLENGE, and in other sources its referred to as a 'blob', which is what I will call it.

In the example I will use the following values:

Password: hashcat
Username: user
Domain: DOMAIN
Challenge: 0x1122334455667788
Blob: 0x0101000000000000e3a17e6c2600ce0191f59c598f8c6f4d00000000020000000000000000000000

The generation process is as follows:

Step 1

A regular NTLM hash is produced from the password (hashcat) by unicoding it and passing through MD4.

hashcat-> b4b9b02e6f09a9bd760f388b67351e2b

Step 2

The username (user) is converted to uppercase and concatenated with the domain name (DOMAIN). This string is converted to unicode and hashed using HMAC_MD5 with the NTLM hash generated earlier used as the key.

USERDOMAIN -> HMAC_MD5 KEY(b4b9b02e6f09a9bd760f388b67351e2b) -> fb659fcf061b8a92be83024db10434b1

Step 3

The server challenge (0x1122334455667788) is then concatenated with the blob (0x0101000000000000e3a17e6c2600ce0191f59c598f8c6f4d00000000020000000000000000000000) and this is fed into HMAC_MD5 with the hash just generated (fb659fcf061b8a92be83024db10434b1) used as the key.

-> HMAC_MD5 KEY(fb659fcf061b8a92be83024db10434b1) -> d2d10fab083e422123c693587315814a

Step 4

The final result.


Let me know if any clarification is needed.