1

I'm trying to crack the password Ul1234 using hashcat. I created a user with that password in kali and copied the hash in the shadow folder:

nils:$6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNsI6u3TKEkKVXb3gNQKhcK/C6y1DW6q4ODNIJrjf1ondgZ7RHqD7kprI1:18296:0:99999:7:::

So the hash should be :

$6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNsI6u3TKEkKVXb3gNQKhcK/C6y1DW6q4ODNIJrjf1ondgZ7RHqD7kprI1

i copied the hash into file nils2.txt and typed the following command:

kali@kali:~/Documents$ hashcat -m 1800 -a 3 ?u?l?d?d?d?d -o ans.txt --force nils2.txt
hashcat (v5.1.0) starting...

OpenCL Platform #1: The pocl project
====================================
* Device #1: pthread-Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz, 1024/2955 MB allocatable, 2MCU

Hash '?u?l?d?d?d?d': Separator unmatched
No hashes loaded.

Started: Wed Feb  5 09:08:13 2020
Stopped: Wed Feb  5 09:08:14 2020

I don't understand why I'm getting an error

schroeder
  • 129,372
  • 55
  • 299
  • 340
Hans Martin
  • 13
  • 1
  • 1
  • 3

1 Answers1

2

$6$ is definitely part of the hash. It indicates the hash type (sha512crypt). The $ as field separator is a long-standing hash idiom and is part of many modern password hashes.

Instead, the issue here is that hashcat's parameters are positional in a way that may not be intuitive. Masks always appear after the target hash or hashfile:

$ hashcat -O  -m 1800 -a 3 -o ans.txt nils2.txt ?u?l1234
hashcat (v5.1.0-1651-g050f6b0e) starting...

[snip]    

Session..........: hashcat
Status...........: Cracked
Hash.Name........: sha512crypt $6$, SHA512 (Unix)
Hash.Target......: $6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNs...7kprI1
Time.Started.....: Wed Feb  5 06:11:40 2020 (1 sec)
Time.Estimated...: Wed Feb  5 06:11:41 2020 (0 secs)
Guess.Mask.......: ?u?l1234 [6]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:     1265 H/s (0.98ms) @ Accel:64 Loops:256 Thr:1 Vec:2
Recovered........: 1/1 (100.00%) Digests
Progress.........: 650/676 (96.15%)
Rejected.........: 0/650 (0.00%)
Restore.Point....: 0/26 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:24-25 Iteration:4864-5000
Candidates.#1....: Ua1234 -> Uq1234

Started: Wed Feb  5 06:11:36 2020
Stopped: Wed Feb  5 06:11:41 2020

$ cat ans.txt
$6$3q88Up7LX1RFIlRU$gVzo1NvtuV4SmJ2SNv6mcLLc9rWtzNsI6u3TKEkKVXb3gNQKhcK/C6y1DW6q4ODNIJrjf1ondgZ7RHqD7kprI1:Ul1234
Royce Williams
  • 9,573
  • 1
  • 33
  • 57
  • hashcat might need it, but it's not part of the hash. No? Isn't it metadata about the hash? – schroeder Feb 05 '20 at 15:15
  • Well, technically, you're correct; neither the type indicator - nor the salt, for that matter - are technically the hash. But idiomatically, if someone asked, "What's the hash of that password?" I would give the entire thing - type indicator, salt, and hash - without batting an eye. It would be weird to hand them just the hash. In other words, there's no word I'm aware of for "the entire thing - type indicator, the salt, and hash"; people just say "the hash" - and everyone knows what they mean. Like "ATM machine", it's wrong - but everyone knows what you mean and lots of people say it. – Royce Williams Feb 05 '20 at 15:21
  • In other words, "Are you aware that $6$ should probably not be part of the hash?" is incorrect. (Yes, technically, you could attack a hash without knowing what type it was; but it would be dramatically less efficient if there was more than one possible type using the same character set and had the same length, etc. But again, it's not the general case - the hash type should be part of the hash in most circumstances.) – Royce Williams Feb 05 '20 at 15:21
  • In even other other words ;), while it's technically metadata, hashcat isn't weird for wanting the type indicator; almost all cracking tools and almost all platforms that either natively use hashes (create, verify, or otherwise interpret) or attack hashes expect all three fields to be present. (Though interestingly, in full disclosure, tools like mdxfind do allow easy attacks with unknown salts, and hashcat can also do it with a specific cmdline idiom!) – Royce Williams Feb 05 '20 at 15:34
  • I'll bow to your experience on this, but if someone gave me the type+salt+hash string, when I asked for the hash, I'd wonder if they knew what they were doing. As for cracking tools, they can require whatever fields they want to as the developers desire, so I'm not bothered by that. – schroeder Feb 05 '20 at 15:36
  • Also technically true, but I want to be clear that hashcat isn't weird for wanting the type indicator; almost all cracking tools and almost all platforms that either natively use hashes (create, verify, or otherwise interpret) or attack hashes expect all three fields to be present. That being said, in full disclosure, tools like mdxfind do allow attacks with unknown salts by using a salt list in a separate file, and hashcat can also bruteforce salts using a specific cmdline idiom! - but these only work for bad/short salts. Good salts make "hashes" useless if they are missing. – Royce Williams Feb 05 '20 at 15:38
  • Thinking further, I think I see the difference. schroeder is (justifiably) using the word "hash" in the pure mathematical sense - the algorithms that directly perform hashing. By contrast, I (perhaps also justifiably ;) ) am using the word "hash" as shorthand for "password hash", which arguably encompasses all of the material necessary to store and easily verify the password. Sometimes, when passwords are stored as pure unsalted MD5, the two are equivalent. Other times, such as with sha512crypt and others, they are related, but somewhat different in scope. Thanks - this was enlightening! – Royce Williams Feb 06 '20 at 06:34
  • 1
    That's an interesting and useful distinction. I hadn't thought of it that way. – schroeder Feb 06 '20 at 07:35