05-07-2018, 03:15 PM
Well since there is a revival of the thread, I would like to ask whether the following makes sense in theory and then, if it is feasible to be implemented.
tl;dr I believe that we can reduce 25% the time required to bruteforce a NetLMv1 hash by offloading the bruteforce candidates to an MD4 bruteforce where we know the last 2 bytes.
Please bear with me, it is quite long.
Taking the example above:
hash = "u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c"
we can quickly get the last 2 bytes of the MD4 of the password, i.e. "1e2b" in our case.
If (I know this is not the case - https://hashcat.net/forum/archive/index....-7049.html) hashcat would support wildcards in hashes, we could provide an MD4 hash with 14 wildcard bytes and 2 fixed ones, in a (let's say) mask attack of 8 characters, for example:
(1) hashcat -m 900 -a 3 ****************************1e2b ?a?a?a?a?a?a?a?a
and let's say this is done in time = T1
This would give a lot of potential candidates but I cannot estimate how many; I can roughly make the following abstraction:
(Please be gentle if this is totally nonsense, I am new to this)
The total keyspace of the candidates is:
(2) 101 (if I counted correctly all characters - upper/lower/numeric/special) to the power of 8, i.e. 101^8 = ~11 Peta combinations
The portion of MD4 hashes ending in "1e2b" compared to all MD4 hashes is:
(3) 2^8 (one byte) for 14 bytes / 2^8 (one byte) for 16 bytes = 1 / 2^2 = 1/4
If we assume that MD4 provides uniformly distributed outputs for all possible 8 characters inputs, we could also assume that the candidates of our hashcat command (1) will be the 1/4 of all the candidates, i.e. (2) (3)~2.75 Peta
Now, if we pipe/direct these candidates as dictionary to the normal netlmv1 hashcat command:
(4) | hashcat -m 5500 -a 0 "u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c"
we have reduced 3/4 of the required time for 8 characters (upper/lower/numeric/special as in (1)) candidates for netlmv1, at the cost of T1.
Taking a random benchmark (setup is not very important since we will be doing comparisons - https://gist.github.com/epixoip/a83d38f4...804a270c40) we have:
MD4 = 350 Gh/s
NetLMv1 = 180 Gh/s
Let's say roughly, MD4 is two times faster than NetLMv1.
So if T2 the time to brute force all 8 length candidates for NetLMv1:
hashcat -m 5500 -a 3 "u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c" ?a?a?a?a?a?a?a?a
we have that T1 = ~T2/2.
Then by using the above mentioned method we need:
T2/2 + T2/4 = (3/4)T2
i.e. 25% reduction in time for bruteforcing NetLMv1 hashes comparing to the current method.
Does it make any sense or I lost it somewhere?
Regarding the implementation side, I have no idea if this is feasible or how you should feed the ouput candidates of the MD4 command to the NetLMv1 one or what kind of delay you may introduce by modifying the actual implementation or if it's even worth it.
Thanks for making it this far
tl;dr I believe that we can reduce 25% the time required to bruteforce a NetLMv1 hash by offloading the bruteforce candidates to an MD4 bruteforce where we know the last 2 bytes.
Please bear with me, it is quite long.
Taking the example above:
hash = "u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c"
we can quickly get the last 2 bytes of the MD4 of the password, i.e. "1e2b" in our case.
If (I know this is not the case - https://hashcat.net/forum/archive/index....-7049.html) hashcat would support wildcards in hashes, we could provide an MD4 hash with 14 wildcard bytes and 2 fixed ones, in a (let's say) mask attack of 8 characters, for example:
(1) hashcat -m 900 -a 3 ****************************1e2b ?a?a?a?a?a?a?a?a
and let's say this is done in time = T1
This would give a lot of potential candidates but I cannot estimate how many; I can roughly make the following abstraction:
(Please be gentle if this is totally nonsense, I am new to this)
The total keyspace of the candidates is:
(2) 101 (if I counted correctly all characters - upper/lower/numeric/special) to the power of 8, i.e. 101^8 = ~11 Peta combinations
The portion of MD4 hashes ending in "1e2b" compared to all MD4 hashes is:
(3) 2^8 (one byte) for 14 bytes / 2^8 (one byte) for 16 bytes = 1 / 2^2 = 1/4
If we assume that MD4 provides uniformly distributed outputs for all possible 8 characters inputs, we could also assume that the candidates of our hashcat command (1) will be the 1/4 of all the candidates, i.e. (2) (3)~2.75 Peta
Now, if we pipe/direct these candidates as dictionary to the normal netlmv1 hashcat command:
(4) | hashcat -m 5500 -a 0 "u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c"
we have reduced 3/4 of the required time for 8 characters (upper/lower/numeric/special as in (1)) candidates for netlmv1, at the cost of T1.
Taking a random benchmark (setup is not very important since we will be doing comparisons - https://gist.github.com/epixoip/a83d38f4...804a270c40) we have:
MD4 = 350 Gh/s
NetLMv1 = 180 Gh/s
Let's say roughly, MD4 is two times faster than NetLMv1.
So if T2 the time to brute force all 8 length candidates for NetLMv1:
hashcat -m 5500 -a 3 "u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c" ?a?a?a?a?a?a?a?a
we have that T1 = ~T2/2.
Then by using the above mentioned method we need:
T2/2 + T2/4 = (3/4)T2
i.e. 25% reduction in time for bruteforcing NetLMv1 hashes comparing to the current method.
Does it make any sense or I lost it somewhere?
Regarding the implementation side, I have no idea if this is feasible or how you should feed the ouput candidates of the MD4 command to the NetLMv1 one or what kind of delay you may introduce by modifying the actual implementation or if it's even worth it.
Thanks for making it this far