Hash Cracking

Applications do not store passwords in clear, but their hash: the output of a one-way function (it cannot be reversed). When we obtain those hashes (from a database, from /etc/shadow, from a memory dump), we cannot "decrypt" them, but we can guess the original password by trying candidates: we hash each candidate and compare. That is called cracking.

The first step is to identify the algorithm, because it determines the speed and format of the attack. Common clues:

• 32 hex with no prefix: usually MD5. Very fast to test (billions per second on a GPU), which is why an unsalted MD5 of a dictionary password falls almost instantly.
• Prefix $2a$ / $2y$ / $2b$: bcrypt. Slow by design (cost factor), meant to resist brute force; even so, a weak password falls.
• Prefix $6$ (SHA-512 crypt), $1$ (MD5 crypt), $y$ (yescrypt): /etc/shadow formats.
• Prefix $P$: phpass, the format used by WordPress and other PHP CMSs.
• Prefixes $krb5tgs$ and $krb5asrep$: Kerberos tickets obtained through Kerberoasting or AS-REP Roasting.

The prefix is the reliable tell; when there is none (a bare hexadecimal string could be MD5, NTLM or a truncated SHA-1) you cross-check by length and context, or you ask a tool:

hashid '$P$BSNPjhY.6vQMhxsFxrbFdRAeDsAe.a0'   # proposes the candidate formats
john --list=formats | tr ',' '\n' | grep -i phpass   # exact name for --format=
hashcat --help | grep -i phpass                      # exact number for -m

The two standard tools are john (John the Ripper) and hashcat. Main mode: dictionary, trying a list of known passwords (the classic one is rockyou.txt):

john --wordlist=rockyou.txt --format=Raw-MD5 hashes.txt
john --show hashes.txt          # re-print what is already cracked (kept in ~/.john/john.pot)
hashcat -m 0 -a 0 hashes.txt rockyou.txt

The format parameter (--format= in john, -m in hashcat) must match the algorithm, and it is not cosmetic: with the wrong format the tool hashes the candidates with a different function and finds nothing even if the password is in the wordlist. john usually guesses it on its own, but when one file format allows several variants (an AS-REP in RC4 or in AES, for instance) you have to say so explicitly. When the dictionary is not enough, apply rules (mutations: append numbers, uppercase, symbols, via --rules / -r) or a mask attack (-a 3, brute force over a specific pattern), though the cost rises steeply with each character.

When what we have is a file, not a hash. An id_rsa private key with a passphrase, a .pfx certificate, a KeePass .kdbx database, a protected PDF or an encrypted ZIP do not contain a hash in any format john understands, but they do carry inside the material that verifies the password. The *2john family of converters extracts it and writes it in john's syntax, which can then be cracked like any other hash:

ssh2john id_rsa > hash.txt         # -> $sshng$...
pfx2john cert.pfx > hash.txt       # -> $pfxng$...
keepass2john base.kdbx > hash.txt  # -> $keepass$...
pdf2john doc.pdf > hash.txt        # -> $pdf$...
zip2john secret.zip > hash.txt     # -> $zip2$...

john --wordlist=rockyou.txt hash.txt

That is why the step always shows up in two beats: first convert the file into a hash, then crack it. None of it touches the victim machine.

Caveat. Success depends on the password quality and the algorithm: a bcrypt with a good cost will not break if the password is strong, and an MD5 will not protect a weak one. The salt (a unique value per hash) does not stop cracking a specific hash, but it defeats precomputed attacks (rainbow tables) and forces attacking each hash separately.

How to detect it. The cracking itself is offline and on the attacker's machine: it never touches the victim and therefore emits no telemetry of its own. Honest detection sits on either side. Before: the theft of the hashes that feeds the cracker is what leaves a trace (a DCSync 4662, an LSASS dump, a read of /etc/shadow, a SQLi exfiltrating a credentials table). After: the reuse of the recovered password, a valid login (4624) of an account from an unusual host or time. Stopping the crack means detecting those two phases, not the crack.

Defence. Use slow, salted algorithms designed for passwords (bcrypt, scrypt, argon2); enforce long, unique passwords; and protect the hash stores. Usually chained with credential reuse once the password is recovered.