hashcat Forum
NTLM vs WPA/WPA2 cracking - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: NTLM vs WPA/WPA2 cracking (/thread-7774.html)

Pages: 1 2

NTLM vs WPA/WPA2 cracking - mtnsec - 08-30-2018

Is there an intentional difference between how hashcat performs a dictionary + rule attack against NTLM vs WPA/WPA2?

While testing different dictionary and rule combinations against a set of test passwords, I found several example passwords that are easily cracked with -m 1000 that are completely missed by -m 2500 when using the same dictionary and rule combinations.

The example passwords used in these tests are:

Roomba123456
Yellow123456
Mountain123456
Rattt1234567

I have run the below tests using hashcat version 4.2.1, 4.2.0 and 4.1.0, multiple dictionaries and rules files, all with the same result.

I’m wondering if I’m using incorrect parameters?  Or is there something else going on?  Can anyone explain the results I’m seeing?

Examples are below:

Key:

testdict.txt - small dictionary that contains only the capitalized base english words for the test passwords (smallest possible dictionary to speed up the tests).
testdictwithpw.txt - small dictionary that also contains the passwords - used for testing pure dictionary attack
test.hccapx - hccapx file with multiple handshakes representing all four test passwords
easy.txt - ntlm hashes for the same test passwords


Test 1:  crack the test NTLM passwords with a dictionary + rockyou-30000.rule attack:

Command:
$ sudo hashcat-4.2.1/hashcat64.bin -m 1000 easy.txt testdict.txt -r hashcat-4.2.1/rules/rockyou-30000.rule


Result:
xxxxx72c839f8192a028681c9b9xxxxx:Roomba123456
xxxxx83e5999052ff069677ef5axxxxx:Yellow123456
xxxxxba6f894f0ff9aee13461c7xxxxx:Mountain123456
xxxxxddc94978e09a8679e8e944xxxxx:Rattt1234567


Session..........: hashcat
Status...........: Cracked
Hash.Type........: NTLM
Hash.Target......: easy.txt
Time.Started.....: Thu Aug 30 14:42:17 2018 (1 sec)
Time.Estimated...: Thu Aug 30 14:42:18 2018 (0 secs)
Guess.Base.......: File (testdict.txt)
Guess.Mod........: Rules (hashcat-4.2.1/rules/rockyou-30000.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   339.8 kH/s (0.05ms) @ Accel:32 Loops:16 Thr:512 Vec:1
Speed.Dev.#2.....:        0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:512 Vec:1
Speed.Dev.#3.....:        0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:512 Vec:1
Speed.Dev.#*.....:   339.8 kH/s
Recovered........: 4/4 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 15232/120000 (12.69%)
Rejected.........: 0/15232 (0.00%)
Restore.Point....: 0/4 (0.00%)
Candidates.#1....: Room83 -> Rattt06
Candidates.#2....: [Copying]
Candidates.#3....: [Copying]
HWMon.Dev.#1.....: Temp: 37c Fan: 27% Util:  1% Core:1771MHz Mem:4513MHz Bus:16
HWMon.Dev.#2.....: Temp: 43c Fan: 27% Util:  0% Core:1771MHz Mem:4513MHz Bus:16
HWMon.Dev.#3.....: Temp: 43c Fan: 27% Util:  0% Core:1771MHz Mem:4513MHz Bus:16

Started: Thu Aug 30 14:42:03 2018
Stopped: Thu Aug 30 14:42:19 2018


Test 2:  Repeat same attack against WPA/WPA2 hccapx and the same passwords

Command: 
$ sudo hashcat-4.2.1/hashcat64.bin -m 2500 test.hccapx testdict.txt -r hashcat-4.2.1/rules/rockyou-30000.rule

Result:

Only one of the four passwords was cracked -

xxxxx65798e44fb4c46d248c408xxxxx:98fc1155eaf2:44032c66aa3a:B:Mountain123456
                                                
Session..........: hashcat
Status...........: Exhausted
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: test.hccapx
Time.Started.....: Thu Aug 30 15:51:59 2018 (24 mins, 38 secs)
Time.Estimated...: Thu Aug 30 16:16:37 2018 (0 secs)
Guess.Base.......: File (testdict.txt)
Guess.Mod........: Rules (hashcat-4.2.1/rules/rockyou-30000.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:       20 H/s (0.10ms) @ Accel:64 Loops:16 Thr:1024 Vec:1
Speed.Dev.#2.....:        0 H/s (0.00ms) @ Accel:64 Loops:16 Thr:1024 Vec:1
Speed.Dev.#3.....:        0 H/s (0.00ms) @ Accel:64 Loops:16 Thr:1024 Vec:1
Speed.Dev.#*.....:       20 H/s
Recovered........: 1/9 (11.11%) Digests, 0/1 (0.00%) Salts
Progress.........: 120000/120000 (100.00%)
Rejected.........: 90000/120000 (75.00%)
Restore.Point....: 0/4 (0.00%)
Candidates.#1....: Mouitain82 -> Mouitain82
Candidates.#2....: [Copying]
Candidates.#3....: [Copying]
HWMon.Dev.#1.....: Temp: 52c Fan: 35% Util:  0% Core:1873MHz Mem:4513MHz Bus:16
HWMon.Dev.#2.....: Temp: 30c Fan: 27% Util:  0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#3.....: Temp: 33c Fan: 27% Util:  0% Core: 139MHz Mem: 405MHz Bus:16

Started: Thu Aug 30 15:51:34 2018
Stopped: Thu Aug 30 16:16:38 2018


Test 3:  Pure dictionary attack against WPA/WPA2 hccapx to rule out a problem with the hccapx file

Command:
$ sudo hashcat-4.2.1/hashcat64.bin -m 2500 test.hccapx testdictwithpw.txt 

Result:
xxxxxf6505b637b12f4cf17f057xxxxx:98fc1155eaf2:44032c66aa3a:B:Roomba123456
xxxxx65798e44fb4c46d248c408xxxxx:98fc1155eaf2:44032c66aa3a:B:Mountain123456
xxxxx2fa3e3b28707dd45fc26c8xxxxx:98fc1155eaf2:44032c66aa3a:B:Yellow123456
xxxxx54af681e7f32975be84f37xxxxx:98fc1155eaf2:44032c66aa3a:B:Rattt1234567
                                                
Session..........: hashcat
Status...........: Exhausted
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: test.hccapx
Time.Started.....: Thu Aug 30 16:18:46 2018 (1 sec)
Time.Estimated...: Thu Aug 30 16:18:47 2018 (0 secs)
Guess.Base.......: File (testdictwithpw.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:        0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Speed.Dev.#2.....:      136 H/s (0.10ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Speed.Dev.#3.....:        0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Speed.Dev.#*.....:      136 H/s
Recovered........: 4/9 (44.44%) Digests, 0/1 (0.00%) Salts
Progress.........: 8/8 (100.00%)
Rejected.........: 3/8 (37.50%)
Restore.Point....: 0/8 (0.00%)
Candidates.#1....: [Copying]
Candidates.#2....: Mountain -> Rattt1234567
Candidates.#3....: [Copying]
HWMon.Dev.#1.....: Temp: 45c Fan: 29% Util:  0% Core:1771MHz Mem:4513MHz Bus:16
HWMon.Dev.#2.....: Temp: 42c Fan: 27% Util:  0% Core:1771MHz Mem:4513MHz Bus:16
HWMon.Dev.#3.....: Temp: 46c Fan: 28% Util:  0% Core:1898MHz Mem:4513MHz Bus:16

Started: Thu Aug 30 16:18:20 2018
Stopped: Thu Aug 30 16:18:48 2018

RE: NTLM vs WPA/WPA2 cracking - philsmd - 08-30-2018

-m 2500 = WPA/WPA2 has a minimum password length of 8
hashcat will reject all input words immediately if they are < 8 (even before the rules are applied, because the rule engine is on-GPU and doesn't perform rejection rules).

you could use pipes or -j to modify the password earlier on to test if the same problem happens with base passwords that are already long enough

RE: NTLM vs WPA/WPA2 cracking - mtnsec - 08-30-2018

(08-30-2018, 07:25 PM)philsmd Wrote: you could use pipes or -j to modify the password earlier on to test if the same problem happens with base passwords that are already long enough

These are the test passwords:

Roomba123456
Yellow123456
Mountain123456
Rattt1234567

The shortest test password I'm using is 12 characters in length.

Did I misunderstand what you meant?  Is it excluding words in my dictionary/wordlist that are shorter than 8 characters?

RE: NTLM vs WPA/WPA2 cracking - mtnsec - 08-30-2018

Thanks for your help! I was able to confirm that it does appear to be skipping dictionary words less than 8 characters, even when rules would prepend/append enough characters to create a 8+ character password.

For the password:

Yellow123456

Dictionary with “Yellow” and “Yellow1” fails while dictionary with “Yellow12” works.

So. Are there any workarounds for this? Or options that would allow me to disable that 8 character check of dictionary words when using a rules based attack?

I am noticing a lot of passwords that are short dictionary words with the year appended to the them (or similar style) that are easy to identify with the appropriate rules, but this optimization check is making it difficult for me to identify them with a traditional dictionary + rule attack. I’m surprised how often I still see something like “Spring2018”.

Thank you!

RE: NTLM vs WPA/WPA2 cracking - mtnsec - 08-31-2018

Anyone have any ideas or workarounds for this limitation? As it stands, this means we can't use a rules based attack to crack any of the simplest/lowest hanging fruit such as:

Spring2018
Hello123
Yellow456
Home2000

....etc, because the base words are getting kicked out before the rules can process them.

RE: NTLM vs WPA/WPA2 cracking - philsmd - 08-31-2018

I already mentioned in my previous post that you can easily workaround this limitation with either pipes (stdin mode) or -j/-k single rules.

There are some considerations to develop/implement/allow a non-GPU (slow) rule engine in future releases of hashcat, but this was just an idea until now and it's not sure if devs are convinced by the speed/effectiveness of this type of rule-engine-on-CPU-but-attack-on-GPU design.
However, if something like this will be implemented in future releases of hashcat, it will for sure be an opt-in command line switch whereby the user will be forced to enable this specific slow attack mode.

I think pipes, pre-generated small dicts, -j/-k rules etc are a very good compromise for now (as I already mentioned)... of course all of them have some disadvantages (but as we saw also a on-CPU rule engine has disadvantages, namely the speed drop !).

RE: NTLM vs WPA/WPA2 cracking - undeath - 08-31-2018

Really, it would be useful if rejection based on min length can be disabled if there is no technical reason to do so. And for WPA there clearly isn't.

RE: NTLM vs WPA/WPA2 cracking - philsmd - 08-31-2018

of course there is reason to reject passwords < 8 for WPA/WPA2 because the algorithm only allows a minimum length of 8. The problem is that if everything happens on GPU (rule engine + hashing/attack) we can't reject the candidates there (there is currently no way rejecting candidates on GPUs, that would be a waste of resources and sometimes actually quite difficult to do on GPU, you would need to do it in the main kernel and loosing a lot of speed probably Sad ), therefore we need to do the rejection before the candidates are loaded into the GPU buffers (which is currenly done before the rule engine+hashing)... again there are some ideas to have/implement a new special attack where the rules are applied on CPU already, but I can't promise anything there.
If we allow passwords that are smaller than the minimum allowed password length (for instance < 8 for WPA/WPA2), all strange things could happen and this should be avoided for sure.

RE: NTLM vs WPA/WPA2 cracking - undeath - 08-31-2018

Well, the thing is, hashcat does obviously not check the candidates but the input words, which is a significant difference. And only performing the check on the input words does not achieve any of the things you claim.

imagine:
Code:
$ cat wordlist
password
$ cat rule.rule
]]

So in the end the input word is not rejected and you try the invalid candidate which you claim should be avoided at all cost.

RE: NTLM vs WPA/WPA2 cracking - mtnsec - 08-31-2018

Thanks for the quick response philsmd! Unfortunately, stdin does not appear to bypass the character limitation. Using a dictionary of just 3 words (all less than 8 characters) results in a very quick exit (output below). 3 words, 30000 rules, 90000 rejects.

Attempting to use -j/-k basically requires a while loop to iteratively run hashcat for every rule. Adding in initializing time for each run is just not practical for more than say, 500 hundred rules (which would still take ~7 hours on a 450k dictionary and using 3 1080’s). I’m also seeing hashing speed dropping by 20-30% this way.

So the only realistic remaining option is pre-generated rule based dictionaries which is presenting major storage issues. Still, I have also been working on this for the last few days. Definitely not optimal.

Maybe I just don’t realize what I’m asking for, but I don’t understand what the problems would be for testing a candidate with less characters as undeath points out. If there is not a real technical concern other than performance, I’d really like to test for myself. Admittedly I don’t have much programming background, but if someone could provide a hint as to where to look to modify the character input limitation in the source (even just to change from 8 to 5) for mode 2500 I would appreciate it. Would like to test and see what kind of a hit performance takes, or if it causes any other problems!

Thanks!

hasher@hash01:~$ sudo hashcat-4.2.1/hashcat64.bin -m 2500 test.hccapx -r hashcat-4.2.1/rules/rockyou-30000.rule < test3.txt
hashcat (v4.2.1) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU

Hashes: 17 digests; 9 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 30000

Applicable optimizers:
* Zero-Byte
* Single-Salt
* Slow-Hash-SIMD-LOOP

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63

Watchdog: Temperature abort trigger set to 90c

Starting attack in stdin mode...

Session..........: hashcat
Status...........: Exhausted
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: test.hccapx
Time.Started.....: Fri Aug 31 18:06:39 2018 (1 sec)
Time.Estimated...: Fri Aug 31 18:06:40 2018 (0 secs)
Guess.Base.......: Pipe
Guess.Mod........: Rules (hashcat-4.2.1/rules/rockyou-30000.rule)
Speed.Dev.#1.....: 0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Speed.Dev.#2.....: 0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Speed.Dev.#3.....: 0 H/s (0.00ms) @ Accel:32 Loops:16 Thr:1024 Vec:1
Speed.Dev.#*.....: 0 H/s
Recovered........: 0/9 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 90000
Rejected.........: 90000
Restore.Point....: 0
Candidates.#1....: [Copying]
Candidates.#2....: [Copying]
Candidates.#3....: [Copying]
HWMon.Dev.#1.....: Temp: 44c Fan: 27% Util: 0% Core:1898MHz Mem:4513MHz Bus:16
HWMon.Dev.#2.....: Temp: 43c Fan: 27% Util: 27% Core:1771MHz Mem:4513MHz Bus:16
HWMon.Dev.#3.....: Temp: 47c Fan: 29% Util: 0% Core:1898MHz Mem:4513MHz Bus:16

Started: Fri Aug 31 18:06:14 2018
Stopped: Fri Aug 31 18:06:40 2018