01-30-2013, 05:45 AM
Hi
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:
https://en.wikipedia.org/wiki/NTLM
https://davenport.sourceforge.net/ntlm.html
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:
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.) :
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:
Step 6
The ciphertext blocks are then concatenated together to provide the final result:
Let me know if any clarification is needed
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:
https://en.wikipedia.org/wiki/NTLM
https://davenport.sourceforge.net/ntlm.html
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:
Code:
hashcat -> b4b9b02e6f09a9bd760f388b67351e2bStep 2
5 null bytes are appended to the hash to take it to 21 bytes:
Code:
b4b9b02e6f09a9bd760f388b67351e2b0000000000Step 3
The value is then split in 3 x 56 bit parts:
Code:
b4b9b02e6f09a9
bd760f388b6735
1e2b0000000000Step 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.) :
Code:
b4b9b02e6f09a9 -> b55d6d04e6792652
bd760f388b6735 -> bcba83e6895b9d6b
1e2b0000000000 -> 1f15c10101010101Step 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:
Code:
b55d6d04e6792652 KEY-> DES(1122334455667788) -> 51a539e6ee061f64
bcba83e6895b9d6b KEY-> DES(1122334455667788) -> 7cd5d48ce6c68665
1f15c10101010101 KEY-> DES(1122334455667788) -> 3737c5e1de26ac4cStep 6
The ciphertext blocks are then concatenated together to provide the final result:
Code:
51a539e6ee061f647cd5d48ce6c686653737c5e1de26ac4cLet me know if any clarification is needed