Cracking Password
Here I will not include hashcat as it's never worked for me or maybe I don't know how to use it properly, sorry for inconvenient :(
Identify hash
In kali,
hash-identifier <<HASH>>hashid <<HASH>>Note: also try putting hash in single quotes
Online,
Online tools
findmyhash
findmyhash LM -h 6c3d4c343f999422aad3b435b51404ee:bcd477bfdb45435a34c6a38403ca4364Cracking
Crackstation https://crackstation.net/
Hashkiller https://hashkiller.co.uk/
Hashes, WPA2 captures, and archives MSOffice, ZIP, PDF <https://www.onlinehashcrack.com/>
Google hashes Search pastebin.
MD5 Hash
/etc/shadow root hashes
Linux shadow passwd
id_rsa
Window SAM file
Others file format
zip
Use zip2john and crack the pasword
7z
PDF
JWT
NTLM cracking
We can use various commands to extract passwords from the system. One of the most common Mimikatz commands is sekurlsa::logonpasswords, which attempts to extract plaintext passwords and password hashes from all available sources. Since this generates a huge amount of output, we'll instead use lsadump::sam, which will extract the NTLM hashes from the SAM. For this command, we must first enter token::elevate to elevate to SYSTEM user privileges.
We must have the SeDebugPrivilege access right enabled for sekurlsa::logonpasswords and lsadump::sam. We'll enable this with privilege::debug.
For this example we'll use the rockyou.txt wordlist with the best64.rule rule file, which contains 64 effective rules.
Let's provide all arguments and values to the hashcat command to start the cracking process.
NTLM Simple Cracking:
user.hash content:
Keepass
Hashcat more info:
Since many users simply append a "1" to a password that requires a numerical value, let's create a rule file containing $1 to append a "1" to all passwords in our wordlist. We'll create a demo.rule with this rule function. We need to escape the special character "$" to echo it into the file correctly.
Now, we can use hashcat with our wordlist mutation, providing the rule file with -r, and --stdout, which starts Hashcat in debugging mode. In this mode, Hashcat will not attempt to crack any hashes, but merely display the mutated passwords.
The listing shows that a "1" was appended to each password according to the rule function $1.
In demo1.rule, the rule functions are on the same line separated by a space. In this case, Hashcat will use them consecutively on each password of the wordlist. The result is that the first character of each password is capitalized AND a "1" is appended to each password.
In demo2.rule the rule functions are on separate lines. Hashcat interprets the second rule function, on the second line, as new rule. In this case, each rule is used separately, resulting in two mutated passwords for every password from the wordlist.
Good! We have adapted the demo1.rule rule file to two of the three password policies. Let's work on the third and add a special character. We'll start with "!", which is a very common special character.
Based on this assumption, we'll add $! to our rule file. Since we want all rule functions applied to every password, we need to specify the functions on the same line. Again, we will demonstrate this with two different rule files to stress the concept of combining rule functions. In the first rule file we'll add $! to the end of the first rule. In the second rule file we'll add it at the beginning of the rule.
The output shows that demo1.rule mutates passwords by appending first the "1" and then "!". The other rule file, demo2.rule, appends "!" first and then the "1". This shows us that the rule functions are applied from left to right in a rule.
The rule contained in demo1.rule mutates the passwords of our wordlist to fulfill the requirements of the password policy.
Now that we have a basic understanding of rules and how to create them, let's crack a hash with a rule-based attack. In this demonstration, let's assume that we retrieved the MD5 hash "f621b6c9eab51a3e2f4e167f2dasd6860" from a target system. We'll use the rockyou.txt wordlist, and modify it for a password policy requiring an upper case letter, a numerical value, and a special character.
Let's create a rule file to address this password policy. As before, we'll use the c rule function for the capitalization of the first letter. Furthermore, we also use "!" again as special character. For the numerical values we'll append the (ever-popular) "1", "2", and "123" followed by the special character.
Next, we can run Hashcat. We will disable debugging by removing the --stdout argument. Instead, we'll specify -m, which sets the hash type. In this demonstration, we want to crack MD5, which is hash type 0, which we retrieved from the Hashcat hash example page. After the hash type, we'll provide the target MD5 hash file (crackme.txt) and the rockyou.txt wordlist. Then, we'll specify -r to provide our demo3.rule. Since our Kali VM does not have access to a GPU, we'll also enter --force to ignore related warnings from Hashcat.
Instead of manually creating rules, we can also use rules provided by Hashcat or other sources. Hashcat includes a variety of effective rules in /usr/share/hashcat/rules:
Based on the analysis, we'll create our rules. We'll use c for the capitalization of the first letter and $1 $3 $7 for the numerical values. To address the special characters, we'll create rules to append the different special characters $!, $@, and $#.
John the Ripper:
To be able to use the previously created rules in JtR, we need to add a name for the rules and append them to the /etc/john/john.conf configuration file. For this demonstration, we'll name the rule sshRules with a "List.Rules" rule naming syntax (as shown in Listing 34). We'll use sudo and sh -c to append the contents of our rule file into /etc/john/john.conf.
Now that we've successfully added our sshRules to the JtR configuration file, we can use john to crack the passphrase in the final step of our methodology. We'll define our wordlist with --wordlist=ssh.passwords, select the previously created rule with --rules=sshRules, and provide the hash of the private key as the final argument, ssh.hash.
We successfully cracked the private key passphrase! Excellent!
As expected, the "Nutrella137!" password satisfied the password policy requirements and also matched brave personal preferences and habits. This is no surprise, since users rarely change their password patterns.
Now, let's use the passphrase to SSH into the target system.
We successfully connected to the target system by providing the correct passphrase to the private key.
Last updated