This Converter makes it possible to follow the inverse sequence to deduce a NT-hash.
The integrity and validity of the resulting NT-hash is checked automatically against the keys K1, K2 and K3, the challenge and NTresp (CT1, CT2 and CT3).
- : Means that the entered or calculated value is valid.
- : Means that the value is unknown or invalid (try to replace K1 by K2 and K2 by K1 if known).
This online module integrates the algorithms of the evilmog tools (ntlm-to-des)
as well as the hashcat-utils
) in order to simplify the manipulation of these values in a single place to obtain the right NT-hash.
To find the initial NT-hash corresponding to an authentication token of the NTLM protocol, the main problem is to recover the 3 DES keys K1, K2 and K3.
- The token can be split into 3 ciphertexts of 8 bytes each, called CT1, CT2 and CT3.
- The final challenge is also present in the token:
- Either the challenge defined on the client side only is present in the token in the absence of ESS/SSP security;
- Either the client challenge is present and the challenge server is located in the first 8 bytes of the LM-response completed with 0s when using ESS/SSP. In which case the final challenge corresponds to the first 8 bytes of the MD5 hash from the concatenation of the client challenge and server challenge.
- At this stage of the dissection, the following symmetric cipher formulas can be established where only the keys K1, K2 and K3 are unknown:
DES-ECB(K1, FinalChallenge) === CT1
DES-ECB(K2, FinalChallenge) === CT2
DES-ECB(K3, FinalChallenge) === CT3
We know the clear (CT1, CT2 and CT3) as well as the final challenge, so it is a DES-KPA attack (Known-Plaintext-Attack) which is necessary.
- The K3 key, derived by binary operations from the last two bytes of the NT-hash (PT3), turns out to be weaker than the others. Indeed, it is possible to brute-force it almost instantly by browsing all the possible PT3-candidates on 2 bytes (0x0000-0xFFFF).
- To obtain K1 and K2, a more time-consuming and resource-intensive DES-KPA attack is required. These keys can also be obtained almost instantly via the Hash-Shucking module, by searching among a selected subset of NT-hash-candidates (ending with known PT3).
- Once K1, K2 and K3 are known, the parts of the final NT-hash PT1, PT2 and PT3 can be derived via binary operations:
arrayout.push((((arrayin & 0xfe) | (arrayin >> 7)) & 0xff));
arrayout.push((((arrayin << 1 & 0xFc) | (arrayin >> 6)) & 0xff));
arrayout.push((((arrayin << 2 & 0xf8) | (arrayin >> 5)) & 0xff));
arrayout.push((((arrayin << 3 & 0xF0) | (arrayin >> 4)) & 0xff));
arrayout.push((((arrayin << 4 & 0xe0) | (arrayin >> 3)) & 0xff));
arrayout.push((((arrayin << 5 & 0xc0) | (arrayin >> 2)) & 0xff));
arrayout.push((((arrayin << 6 & 0x80) | (arrayin >> 1)) & 0xff));
- Finally, the NT-hash can be reconstructed via the concatenation of PT1, PT2 and PT3.
How to obtain DES-keys K1 and K2?
3 main methods are possible:
- To obtain the DES-keys K1 and K2, the first method is to submit the authentication token to the Hash-Shucking module. If a collision with an NT-hash from the HaveIBeenPwned database is obtained, all key details are delivered (K1, K2, K3 and the corresponding NT-hash).
- The second method consists of submitting the token to the Crack.sh online service in an appropriate format (which may be chargeable), in order to obtain the NT-hash in return. This NT-hash in your possession, it can be entered in the Generator to retrieve all DES-keys K1, K2 and K3. This method is 100% guaranteed regardless of the complexity of the authentication token password.
- If the Hash-Shucking module does not give a result, and you don't want to use Crack.sh, a third method is possible by using the DES-KPA (DES Known Plaintext Attack) mode of Hashcat (14000). This method is 100% guaranteed regardless of the complexity of the authentication token password.
Using this mode requires an input file (inputs.txt) consisting of two lines as follows:
Then, it is possible to launch Hashcat to break the 2 DES keys K1 and K2 as follows (K3 is instantly brute-forced via the Converter):
hashcat -m 14000 -a 3 inputs.txt --hex-charset -1 /usr/share/hashcat/charsets/DES_full.hcchr ?1?1?1?1?1?1?1?1
This process can take several days, depending on the computing power (CPU, GPU, etc.) allocated to Hashcat. My tests with an NVidia RTX 3080 Ti / i7 12th Gen / 32GB RAM graphics card lasted a maximum of 15 days, so 7.5 days on average to obtain the two keys: K1 and K2.
#93D9F1C5274F55BB is K1 (or K2?)
#B9E599C1BBDD47C5 is K2 (or K1?)
Once the corresponding keys have been obtained, all you have to do is enter them in the Converter form in addition to the initial token, to have the corresponding NT-hash.
Warning: Hashcat does not distinguish "K1" from "K2", so it is possible that they are reversed (K2 then K1). Try both combinations to produce candidate NT-hashes in the Converter.
These methods are intended to recover the NT-hash corresponding to an authentication token, but not to recover the plaintext. Thus these methods are efficient whatever the complexity of the initial password ("user account" or "computer account" in Active Directory), which remains unknown. But having the NT-hash is enough, especially with the Pass-the-Hash Attack
Compatibility & Formats:
The output results are in various formats summarized in the following table with their tool's compatibility.
How to convert formats?
To convert an authentication token from one format to another, simply submit it freely to the Hash-Shucking module or use the Converter to follow algorithm's dissection.