NTLM password not found

[Dr-Tibetor]

Hello,

I try find/verify password František1 for NTLM hash 902BD6FDDF5248CE7902174E408F3F1F

JtR find it. Input file utf-8

I try encode input word with different charset, but without result.


I try Franti?bek1 or Franti?b?bek1 for substitute special character, but not fount it.

Some idea ?


Thank you.

[Banaanhangwagen]

The special character š is a 2-byte hex value.
You need to force Hashcat to attempt 2-byte hex values. (with ?b?b or with --hex-charset)

The corresponding hex-value for š is 0xc5 0xa1.

When doing so, it does the job...

Code:

$ echo -n František1 | md5sum
357462a768a498cf3b7967591884880f

hashcat -m0 357462a768a498cf3b7967591884880f -a3 Franti?b?bek1

357462a768a498cf3b7967591884880f:František1

Probably your NTLM-hash is not correct.

[DanielG]

Using https://tobtu.com/lmntlm.php I can turn František1 into the NTLM hash 902BD6FDDF5248CE7902174E408F3F1F which means your NTLM-hash is correct.

You also say you used ?b?b which did not lead to hashcat cracking it.

I too tried ./hashcat -a 3 -m 1000 902BD6FDDF5248CE7902174E408F3F1F Franti?bek1 and ./hashcat -a 3 -m 1000 902BD6FDDF5248CE7902174E408F3F1F Franti?b?bek1 but hashcat did not crack it.

If I make a NTLM hash of a variant without unicode char: Frantisek1 (64436D005F319C8AC790209424608CD2) and run ./hashcat -a 3 -m 1000 64436D005F319C8AC790209424608CD2 Franti?bek1 then hashcat does find it.

This is very strange, maybe hashcat doesn't do unicode well?

EDIT:

also trying  --hex-charset did not work, Franti in hex is 4672616e7469 and ek1 in hex is 656b31:

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?b656b31

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?b?b656b31

Nor does using ?h for hex chars:

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?h?h656b31

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4672616e7469?h?h?h?h656b31

[hops]

This is very strange, maybe hashcat doesn't do unicode well?

That's correct. At least for NTLM or any other kernel using the make_utf16* functions (defined in OpenCL/inc_common.cl).
NTLM is simply MD4 but the password is encoded in UTF-16.

Code:

$ echo -n František1 | iconv -f utf8 -t utf16le | xxd
00000000: 4600 7200 6100 6e00 7400 6900 6101 6500  F.r.a.n.t.i.a.e.
00000010: 6b00 3100                                k.1.

This is what's supposed to be fed into the MD4 hash function.
make_utf16le() cheats a bit and simply appends a null byte after every input byte. That works fine as long as all the characters are ASCII.
But in your case hashcat feeds this into the MD4 hash function which results in a different hash.

Code:

00000000: 4600 7200 6100 6e00 7400 6900 c500 a100  F.r.a.n.t.i.....
00000010: 6500 6b00 3100                           e.k.1.

(technically it's 0072 0046... etc. because of little endian)

So until someone contributes a valid UTF-16 encoder this will be an issue.

[DanielG]

Shouldn't this then work?:

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4600720061006e0074006900?b?b65006b003100

./hashcat -a 3 -m 1000 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 004600720061006e00740069?b?b0065006b0031

here you add the null bytes manually and the two byte unicode š (6101) should fall in the ?b?b ? However hashcat doesn't find it in this case either.

[hops]

Good thinking but no that does not work. The reason: the UTF-16 expansion will still be applied (happens on GPU).
So 46007200 will become 46000000 72000000 etc. However if you use -m 900 (MD4) hashcat will find that hash.

Code:

./hashcat --quiet -a 3 -m 900 --hex-charset 902BD6FDDF5248CE7902174E408F3F1F 4600720061006e0074006900?b?b65006b003100
902bd6fddf5248ce7902174e408f3f1f:$HEX[4600720061006e0074006900610165006b003100]

The only workaround I can think of is to do the UTF-16 encoding like this.

Code:

./hashcat --quiet --encoding-from=utf8 --encoding-to=utf16le -m 900 902BD6FDDF5248CE7902174E408F3F1F /tmp/dict
902bd6fddf5248ce7902174e408f3f1f:$HEX[4600720061006e0074006900610165006b003100]

But that means you can't use rules. Well you can but most of them will produce invalid UTF16 sequences.