« Posts tagged hashcat

Multicore dictionary support in JTR using Hashcat utilities.

Introduction:

John the ripper first saw the light of the digital word back in 1996. The common CPUs at the time ranged from 486′s to Pentium’s, not a dual core, quad core, or hex core was in sight. Over the past decade and a half JTR has had plenty of patches and updates, but it’s never been rebuilt from the ground up to work in a multicore architecture.  There however has been some creative methods for getting it to work in a multicore environment. Which brings me to what this article is about. Today I’m going to cover how to use the “Gate” tool from the Hashcat utilites suite to put all those cores to work. The gate tool logically splits a dictionary file into equal sections based on the amount you specify. Gate works in both linux and windows, but for the purpose of this article I’ll be covering how to use it in linux.

Method:

Before we get started you’ll need a couple things. First you’ll want the latest version of Hashcat utilities you can download it here. Once you have them unrared in your working directory copy gate.bin to your john directory.  If you don’t have a dictionary to use a good example is the “rockyou.txt” list that can be downloaded from here. You’ll need  a hash list, here is the example DES list I’ll be using in my example.

The syntax for gate is: ./gate.bin mod offset < infile > outfile   Gate will also work on stdin and stdout. The two important switches are the ‘mod’ and ‘offset’. Mod is the number of times you want to split your dictionary. For example if you have an i7 then you would want to use a mod of 8 so that all your cores are fully utilized. The offset value is which section of the split is getting that feed. Lets look at an example.

john# cat rockyou.txt | ./gate.bin 8 0 > example0.txt

After this finishes excuting you should now have a file called example0.txt that is 1/8th the size of rockyou.txt. This is because gate splits the output from cating rockyou.txt evenly and only puts every 8th line into example0.txt You could do this for 0-7 and each one will have a different section of the original file. Now that you can see how gate works we’ll see how to use this with JTR.

john# ./gate.bin 8 0 < rockyou.txt | ./john --stdin --session=0 des.hash
<Ctrl>+c to kill

If you’ve run the above command correctly you should see John running as it normally does. However if you only have one terminal shell open your screen is being taken up by just one instance of John. You can put this process in the background by doing:

<Ctrl>+z
# bg

The ctrl+z will put the current running process in the background, bg will make that process running again. At this put you can continue kick off subsequent instances of John using a different offset and session number.
One thing to note is that John will print guesses to stdout, so it can be hard to start other instances if John keeps printing to the screen. You can send the output to /dev/null so that it won’t interfere. By running the command with ‘&’ on the end the process will start in the background. You could put your entire list of commands in a text file and copy & paste them to the screen such as this:


./gate.bin 8 1 < rockyou.txt | ./john --stdin --session=1 des.hash > /dev/null &
./gate.bin 8 2 < rockyou.txt | ./john --stdin --session=2 des.hash > /dev/null &
./gate.bin 8 3 < rockyou.txt | ./john --stdin --session=3 des.hash > /dev/null &
./gate.bin 8 4 < rockyou.txt | ./john --stdin --session=4 des.hash > /dev/null &
./gate.bin 8 5 < rockyou.txt | ./john --stdin --session=5 des.hash > /dev/null &
./gate.bin 8 6 < rockyou.txt | ./john --stdin --session=6 des.hash > /dev/null &
./gate.bin 8 7 < rockyou.txt | ./john --stdin --session=7 des.hash > /dev/null &

You can type ‘jobs’ on the command line to see all of the instances of John running, and if any of them are stopped. If everything was done right you’ll hopefully be running through those wordlist 8 times as fast. The above example could work similarly in a windows environment however each instance of John would have to run in a separate command windows because the background command isn’t supported.

oclHashcat 102

In part two of learning oclHashcat(oclhc) I’ll cover rules, creating custom character sets, and the increment option. If you haven’t had a chance to read part one you may want to stop now, and read that first.

Rules:

To date oclhc support 25 rules, the list can be reviewed here. Rules are quite useful at tailoring your wordlist to suit the characteristics of the hash or hashlist you are trying to audit. For example many companies incorporate password complexity requirements that may not necessarily match your dictionary file. Another example is web applications usually have no requirement for complexity. Therefore most of the passwords will be between 8-10 characters long, lowercase, and two trailing digits, with that in mind you might consider using the ‘l’ rule to lowercase your dictionary. As was explained in the ‘oclHashcat 101 article’ plaintext are generated from a base word(left) and a modifier word(right) and it is for that reason that there is a rule switch for each side the –j(left) and –k(right). I use the mnemonic ‘Just Kidding’ or ‘J/K’ to help me remember the switches. Also remember that rules only affect dictionaries, not mask. Here are a couple examples:

# ./oclhashcat32.bin -m 0 hashlist.txt -j l dict1.dic ?d?d
This example simply lowercases the uppercase characters in our dict1.dic, then bruteforces 00-99

# ./oclhashcat32.bin -m 0 hashlist.txt -j lc -k l] dict1.dic dict2.dic
Some people are unaware that you can use more than one rule at once. In the above example -j lc would first lowercase the dictionary word, then capitlize the first character in dict1.dic. The rule -k l] would lowercase and truncate one character from the end of dict2.dic. It’s important to point out that rules process from left to right, so -j cl would first uppercase the first character, then lowercase it making the ‘c’ pointless in this case.

# ./oclhashcat32.bin -m 0 hashlist.txt -j ]]]] dict1.dic ?d?d?d?d
In this example the last 4 characters in dict1.dic are being truncated, and digits from 0000-9999 are being bruteforced on the end.

Custom Character Sets:

Cutsom character sets are more suited to bruteforce style attacks. They provide a way of assigning characters to 1 of 4 mask variables. The switch for assigning characters to a variable is simply -1, -2, -3, and -4 followed by a group of single characters and/or preset mask. The list of preset mask are:

?l = abcdefghijklmnopqrstuvwxyz
?u = ABCDEFGHIJKLMNOPQRSTUVWXYZ
?d = 0123456789
?s =  !”#$%&’()*+,-./:;<=>?@[\]^_`{|}~
?h = ISO-8859 characters from (0xc0 – 0xff)

oclhc was not orginally designed as a bruteforce tool, however nature of how the mask, and character sets work it certainly can be used as one.

# ./oclhashcat32.bin -m 0 hashlist.txt -1 ?u?d -2 ?l?d ?1?2?2?2?2 ?2?d?d
As we can see this is strictly a bruteforce style attack. The -1 switch is being assigned with all uppercase characters, and all digits, while -2 is being assigned all lowercase characters and digits, the last two are preset digit ranges. Here is what our positional mask range would look like, along with some passwords it would find:

-1 ?u?d-2 ?l?d-2 ?l?d-2 ?l?d-2 ?l?d-2 ?l?d?d?d
A-Z,0-9a-z,0-9a-z,0-9a-z,0-9a-z,0-9a-z,0-90-90-9
Pa55m399
Tru5tn01
1cans331

# ./oclhashcat32.bin -m 0 hashlist.txt -j ]] -1 ?l?u?s?d?h dict1.dic ?1?1
This is actually one of my favorite attacks. It uses a combination of rules and custom character sets. This attack is especially usefully when the dictionary used is built from the already found passwords from a large hash list. Since there is a tendency to have a lot of the same or similar passwords when a group of hashes are from the same source. This attack simply truncates the last two characters of the dictionary word and brute forces the last two with all upper, lower, special, digit, and hex. It is effective to try different levels of truncation, and mask lengths.

# ./oclhashcat32.bin -m 0 hashlist.txt -1 ?daeiou ?1?1?1 ?1?1?1
This example shows that a custom character set can be composed of both individual characters and/or a preset mask.

Increment:

The increment switch is a way of auto increasing the length of the character set that your bruteforcing. The idea seems simple but can be a bit confusing for those that don’t understand the left/right method of operation. The character set range is set by the mask characters in both the left and right side. Lets say we have the following example:

# ./oclhashcat32.bin -m 0 --increment hashlist.txt ?u?l?l ?l?l?l?l?l
We see the –increment switch is used, with the base(left) mask of ?u?l?l and the modifier(right) as ?l?l?l?l?l. As a result we can see below that the range for our example is length 4-8.

1?u?l?l?llen = 4
2?u?l?l?l?llen = 5
3?u?l?l?l?l?llen = 6
4?u?l?l?l?l?l?llen = 7
5?u?l?l?l?l?l?l?llen = 8

The way that it works is that once the keyspace for row 1 is complete it advances to row 2, and so on until it completes row 5. Because of the way that the base/modifier system works it is not possible to brute force less than two character.

We’ve covered several useful aspects of oclhc, and I’ve hopefully made things a bit more clear for some. This is not the end of my tutorials on oclhc. So check back as I’ll hopefully have some more to cover shortly.

Rule-Fu: The art of word mangling.

Einstein once said – “You have to learn the rules of the game. And then you have to play better than anyone else” and I agree. Rules are the foundation for many different forms of word mangling techniques, as well as some advanced techniques. I’ll briefly cover each rule and give an example of what each rule would do to an input word. I’ll refer to the below tables in other articles, so you may want to learn what each rule does, or at least review each one.
* Indicates that N starts at 0

Hashcat + oclHashcat Rules

NameRuleDescriptionExample RuleInput WordOutput WordNote
LowercaselLowercase all letterslp@ssW0rdp@ssw0rd
UppercaseuUppercase all lettersup@ssW0rdP@SSW0RD
CapitalizecCapitalize the first lettercp@ssW0rdP@ssW0rd
Invert CapitalizeCLowercase first found character, uppercase the restCp@ssW0rdp@SSW0RD
Toggle CasetToggle the case of all characters in word.tp@ssW0rdP@SSw0RD
Toggle @TNToggle the case of characters at position NT3p@ssW0rdp@sSW0rd
ReverserReverse the entire wordrp@ssW0rddr0Wss@p
DuplicatedDuplicate entire worddp@ssW0rdp@ssW0rdp@ssW0rd
ReflectfDuplicate word reversedfp@ssW0rdp@ssW0rddr0Wss@p
Rotate Left{Rotates the word left.{p@ssW0rd@ssW0rdp
Rotate Right}Rotates the word right}p@ssW0rddp@ssW0r
Append Character$Append character to end$1p@ssW0rdp@ssW0rd1
Prepend Character^Prepend character to front^1p@ssW0rd1p@ssW0rd
Truncate left[Deletes first character[p@ssW0rd@ssW0rd
Trucate right]Deletes last character]p@ssW0rdp@assW0r
Delete @ NDNDeletes character at position ND3p@ssW0rdp@sW0rd
Delete rangexNMDeletes characters from N-Mx02p@ssW0rdssW0rd*
Insert @ NiNMInserts character at position Ni4!p@ssW0rdp@ss!W0rd*
Overwrite @ NoNMOverwrites character at postion N with Mo3$p@ssW0rdp@s$W0rd*
Truncate @ N'NTruncate word at position N'6p@ssW0rdp@ssW0
ReplacesNMReplace all instances of N with Mss$p@ssW0rdp@$$W0rd
Purge@NPurge all instances of N@sp@ssW0rdp@W0rd
Duplicate first NzDuplicates first character N timesz2p@ssW0rdppp@ssW0rd
Duplicate last NZDuplicates last character N timesZ2p@ssW0rdp@ssW0rddd
Duplicate allqDuplicate every characterqp@ssW0rdpp@@ssssWW00rrdd

Hashcat only rules

NameRuleDescriptionExample RuleInput WordOutput Word
Note
Swap frontkSwaps first two characterskp@ssW0rd@pssW0rd
Swap backKSwaps last two charactersKp@ssW0rdp@ssW0dr
Swap @ N*NMSwaps character N with M*34p@ssW0rdp@sWs0rd*
Bitwise shift leftLNBitwise shift left character @ NL2p@ssW0rdp@æsW0rd*
Bitwise shift rightRNBitwise shift right character @ NR2p@ssW0rdp@9sW0rd*
Ascii increment+NIncrement character @ N by 1 ascii value+2p@ssW0rdp@tsW0rd*
Ascii decrement-NDecrement character @ N 1 ascii value-2p@ssW0rdp?ssW0rd*

The best thing to do is try out each of these and get a feel for how each one works.  A static rule can be used in oclHashcat by using the -j switch for the left dictionary and the -k for the right dictionary. Here are some examples:

# ./oclHashcat32.bin hashlist.txt -j ] -k [ dic1.dic dic2.dic

This would truncate the last character on the word in dic1 and truncate the first in dic2.

# ./oclHashcat32.bin hashlist.txt -j l] dic1.dic ?d?d?d?d

This one would lowercase and then truncate the last character while bruteforcing 4 digits on the end.

A better method to really see what the rule is doing is to use the –debug-mode=3 in Hashcat to see what is actually happening. Here is how you would do it:
#1 create a file with your rules, add one rule per line do as many as you like then save it as test.rule Then create a test dictionary, and a file with a fake hash and call it nofind.hash (UPDATE: hashcat 0.37 now supports –stdout switch, this allows you to show mangled words without creating a fake hash)

# echo p@ssW0rd > test.word
# echo ffffffffffffffff > nofind.hash

Then run Hashcat:

# ./hashcat-cli32.bin -m200 --debug-mode=3 -r test.rule nofind.hash test.word

You should get an output that shows all your mangled words.

Using dictionary rules with Pyrit & Hashcat

Pyrit is one of the fastest WPA crackers available. The nice thing about it is that it supports opencl, cuda, and has support for CPU’s with SSE2 acceleration. Unfortunately even an extremely fast system can only achieve about 100k keys/sec which makes brute forcing a WPA key pretty pointless for full character set passwords with lengths above five characters. This means the only effective method is to use a dictionary based attack. Personally I’m all for having a lot of dictionary files but there comes a point when even a massive dictionary collection can’t crack those hard to recover WPA keys. This is where Hashcat comes in, with release 0.35 there now includes an option to output mangled words to standard out. Since Pyrit supports wordlist on stdin we can simply pipe hashcat output into Pyrit. To get started we need to create an uncrackable hash file with only a single hash, this is so Hashcat constantly outputs the plaintext.

# echo ffffffffffffffff > nofind.hash

We set the Hashcat mode to –m 200 (mysql) because it is one of the fastest modes and can use a smaller number of threads. As an example you can see what happens when you don’t pipe Hashcat’s output into Pyrit.

# ./hashcat-cli64.bin -m 200 -r rules/best64.rule --debug-mode=3 nofind.hash dictionary.dic
Ctrl+C to stop

Something to consider is for every 1 rule that you use with Hashcat it will increase your dictionary by 1 times. So given a dictionary that is 1000 words and using 64 rules will expand your dictionary to 64,000 words. So if you calculate that it takes 20 minutes for your dictionary to complete normally then with 64 rules it would take nearly 21 hours. Hashcat 0.35 includes a rule file called best64.rule located in the rules folder. Since best64.rule is sorted by the top finding rules you could make a new rule file with less rules.

# head –n 10 best64.rule > best10.rule

Now to add it all together..

# ./hashcat-cli64.bin -m 200 –n 2 -r rules/best10.rule --debug-mode=3 nofind.hash dictionary.dic | pyrit –r wpa_test.cap –i – attack_passthrough

If you’ve done everything correctly you should see something like…

Pyrit 0.3.1-dev (svn r283) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Parsing file ‘ /wpa_test.cap’ (1/1)…
Parsed 5 packets (5 802.11-packets), got 1 AP(s)

Picked AccessPoint 00:0d:ea:d0:01:00 (‘test’) automatically.
Tried 3840192 PMKs so far; 106871 PMKs per second.

Hopefully if all goes well you will see this -

The password is 'Passw0rd'.

For the switches used in Hashcat v0.35 -m 200 sets it to mode mysql, -n 2 sets it to use only 2 threads instead of 8 which is the default. This way there are more threads devoted to cracking wpa keys. -r sets the rule file, and finally –debug-mode=3 is what actually outputs the mangled words to stdout.

Hashcat can be downloaded at hashcat.net

Converting LM to NTLM with Hashcat

When doing a security audit getting a pwdump of both LM and NTLM hashes can be a gold mine. Finding the plain text of a list of LM’s is trivial using rainbow tables. In most cases however it’s better to have the case sensitive NTLM plain text. There are several scripts available that convert the LM plains into the equivalent NTLM case sensitive value, but my preferred method is to use Hashcat.  To start simply create a dictionary file using the found LM hashes:

# cut -b 34- LM.out > LM.dic

Now create a hash list with only your NTLM’s hashes. My example hash dump was a pwdump that is in format:

username:userid:<LM HASH>:<NTLM HASH>:::

# cut -d: -f4 pwdump.txt > ntlm.txt

Now we use Hashcat to find our NTLM hahes using the LM.dic

#./hashcat-cli64.bin -m 1000 -o ntlm.out -a 2 ntlm.txt LM.dic

Added hashes from file ntlm.txt: 100 (1 salts)
Wordlist..: LM.dic
Index…..: 1/1 (segment), 100 (words), 883 (bytes)
Recovered.: 100/100 hashes, 0/1 salts
Speed/sec.: – plains, – words
Progress..: 100/100 (100.00%)
Running…: –:–:–:–
Estimated.: –:–:–:–
Started: Sun Dec 5 11:06:12 2010
Stopped: Sun Dec 5 11:06:12 2010

Here is what the switches mean -m sets the mode to NTLM, -o sets your output file to ntlm.out, -a 2 set the attack mode to toggle case. If your doing more than just a few hashes you may need to merge the plain text back with the original pwdump file. Here is a simple perl script that can be used to append the plain text to the end of the pwdump file. – hash2plain.pl

# ./hash2plain.pl ntlm.out pwdump.txt