Introduction:

It never surprises me the lengths some people will go to be lazy. Lately I’ve been doing password audits of networks with surprisingly decent password policies. Such as requiring a minimum length of 15 characters, and at least 2 of each upper, lower, special, and digits. Surely with such a stringent policy you wouldn’t expect to be able to crack any of the passwords. This however wasn’t the case thanks to two techniques that users have to promote their laziness, keyboard walking, and password doubling. In this two part article I’ll be covering how to attack those password and what methods can be used to prevent it..

Method: Keyboard walking

In part 1 I’ll be covering keyboard walking, this is the act of creating a password that is composed of a string of characters that move in a row or pattern on the keyboard. Common examples might be 1qaz, !@#$, ZAQ!, and 1234, I call these short strings “character sets”. It’s not certain if users think they are being smart, or they are just being lazy the fact remains that most patterns are pretty simple and are composed of only 3 or 4 characters. Using the four character sets above, and depending on the password policy a user may come up with something like ‘1qaz1234ZAQ!!@#$‘. This password meets all the complexity requirements, it’s greater than 15 characters, and has two of each character type. The problem is that if we knew the user used those 4 character sets we would only have to try at most 4^4(256) combintations to find the password (actually only 110 combinations contain an upper, lower, special, and digit).  In my testing I have found about 229 common length 4 character sets, if we wanted to build every combination of length 16 characters it would be 229^4 = 2,750,058,481 combinations. Given a standard desktop CPU could do 10M guesses a second it would take less than 5 minutes to compute every possible combination.

I see keyboard walking as being most prevalent in Active directory domains. In order to audit these the first step is to extract the hashes from the SAM database on the domain controller. I use a tool called fgdump, the output from this tool is saved as a pwdump file and it contains User name, User ID, LM hash, and NTLM hash, in a colon delimited format. Hopefully you will see “NO PASSWORD” in the LM field otherwise don’t bother with the NTLM as the LM’s can easily be cracked using rainbow tables. Depending what cracking tool your using you may have to extract the NTLM hashes from the pwdump file. Hashcat tools accept hashes only, so to extract the NTLM hashes do:

root@erebus:~# grep -v -h \$ 127.0.0.1.pwdump | sort -u | cut -d: -f4 > ntlm.hash

The command greps the file 127.0.0.1.pwdump for all hashes not containing $ (which are machine accounts), pipes it to sort using the unique switch, it is then piped to cut using a colon as a delimiter and selecting the 4th field, outputting to the file ntlm.hash. Conveniently JTR will accept the pwdump format directly. I will be using JTR to attack most of the keyboard walking accounts because JTR supports wordlist on stdin. I built a custom perl script that will allow you to pass keyboard combinations directly to JTR’s stdin, the script can be downloaded here. Here is an example of its usage:

root@erebus:~# perl keywalk-gen.pl 4 4
-pl,-pl,-pl,-pl,
-pl,-pl,-pl,-pL<
-pl,-pl,-pl,!@#$
-pl,-pl,-pl,!@34
-pl,-pl,-pl,!Q@W
..... <CTRL>+c to stop

The script will output every combination (1,387,488,001) of keyboard walks within the character set selected. In the example above character set 4 was selected, with a multiple of 4. This combination would give you 16 character password guesses. If the password policy you were auditing only required 12 character passwords you may try keywalk-gen.pl 4 3. You could also use the keywalk-gen script to build a dictionary by redirecting output into a file, but why waste hard drive space on a dictionary when words can be built on the fly and piped to stdin. Here is an example of the syntax used for JTR:
root@erebus:~# perl keywalk-gen.pl 4 4 | john.exe --stdin --format=nt 127.0.0.1.pwdump
Loaded 1264 password hashes with no different salts (NT MD4 [128/128 SSE2 + 32/32])
Remaining 1003 password hashes with no different salts
1qaz1qaz!QAZ!QAZ (user476)
1qaz1qaz@WSX@WSX (user808)
1qaz!QAZmko0MKO) (user1167)
1qazZAQ!2wsxXSW@ (user508)
1qaz2wsx@WSX1qaz (user950)

From the example above 1264 NT MD4(NTLM) hashes were loaded.  Using my laptop it took 22 minutes to generate all 1.38 billion combinations. This technique could also be applied to any algorithm that JTR supports. In addition this could be used to pipe plains into oclHashcat-plus and apply rules to the keywalk patterns, or attack harder algorithms such as md5(crypt). Just remember that oclHashcat-plus only supports up to 15 characters plains as an input so keywalk-gen.pl 4 4 would be to large. Run keywalk-gen.pl without any arguments to see all of the characters sets available to choose from. Protip: Use the gate tool from Hashcat-utilites, splitting the wordlist among mutliple cores or computers as was discribed in “Multicore dictionary support in JTR using Hashcat utilities.”

Conclusion:

Hopefully it’s easy to see how vulnerable those keyboard walk passwords are. Next I’ll be covering how to attack doubled passwords and what steps we can use to help prevent it.

Links: keywalk-gen.pl

Introduction:

As a change of pace from the usual articles on how to crack passwords, I thought I’d show a method for making them harder to crack. In last weeks article ‘does password padding make your password more secure‘ I showed that adding a simple repeating character or characters to a password doesn’t necessarily make it more secure. The problem wasn’t that someone was adding characters, it was that they might have used repeating or patterned characters as their padding. So the question is how do we add complexity without lowering entropy.

Method:

It occurred to me that people are generally able to memorize simple pins, or numbers like in a phone number. However one of the worst things someone could do is simply add numbers to a password. Adding numbers to a base password is nearly as bad as adding a repeating pattern. Using a dictionary hybrid attack an attacker could bruteforce appending and prepending digits while simultaneously using dictionaries as a base word. It also occurred to me that people tend to write long or complex passwords down, which is also a concern. So if adding numbers is bad, and writing them down is bad what if you combine the two? The result is something I call the password pad. Surely many variations of this idea already exists, but none that I’ve seen are so simplistic.

The idea is not to remember a long complex high entropy password, or to be so insecure as to write them down or use simple padding. Instead one would use a small “password pad” to increase the size of an already used password.

As an example lets say you use Pass123 as your login password for a web site. This is an obvious bad password as it contains a dictionary word, it’s short, and is followed by a very common series of numbers. So instead of using 123 directly we could use our password pad to extend the complexity of the password.

On our sample password pad 1 = CY?, 2 = =45, and 3 = :Vh. So rather than having Pass123 we have PassCY?=45:Vh.  This increases our password complexity substantially. Not only are we now using characters from all character sets but the length has increased from 7 to 13. Even using a hybrid attack where ‘Pass’ was the base word, ‘CY?=45:Vh’ would take a prohibitively long time to try to bruteforce. Sounds simple enough but you may be wondering what if someone else uses the pin 123? The uniqueness comes from the fact that no two people’s “password pad” is the same. The sample pad I used was generated from the key “password”. Ideally you wouldn’t use something as simple as that, likewise you could use a randomly generated key. Thus everyone that has a pad will have different randomized characters for each digit on the pad. To create your own password pad use the generator below.

Password Pad Generator:

Conclusion:

Once your password pad has been generated you can print it out and put it in your wallet, stick on your monitor, save it as an image on your desktop or in your email, you could even msg it to your phone. Or keep it safe so it’s an easy way to have 2-factor authentication -something you have, and something you know. The pad is unique to the key that generated it, and has adequate entropy. It also always you to chose digits that the password policy allows for, an example would be if a site only allows 10 digits then choose less padding digits that allow it to fit. Here are some do’s and do not’s.

Do -

• Choose a unique key to generate your pad
• Use a known password in addition to the pad
• Select at least 3 different digits from the pad that as a whole have at least one character from each character set
• Use a different pin for each web site login

Do not -

• Use only the pad to compose your entire password
• Write your base password on or near your pad
• Just add the padding to the end of your base word

Some other suggestions might be to use it as method for agreeing on a pre-shared key between two people without actually passing the plain text password. Use the 4 character pad option on the generator for better security. Mentally reverse some character sets from the pad to increase obfuscation. If you ever lose your pad you can generate the same one by using the same key. I’m sure there’s lot of other ideas you can come up with on your own just be creative.

(UPDATE!) Over the weekend I put together a windows executable version of the password pad. It can be downloaded here.The windows version allows you to generate a pad exactly like the php version. It also allows you to click the pad numbers and it will fill in the box below, click copy to clipboard and paste where ever you need it. Anyone interested in helping me develop a iphone/android app equivalent please contact me.

DG

Introduction:

I was listening to a recent security podcast in which this weeks episode included the topic of passwords, and a suggestion for increasing password strength while reducing its complexity. The method roughly involves appending or prepending various amounts of repeating characters or patterns to a sufficiently complex base password. For example using the base password:

W3akP@$$ —> W3akP@$$///////

This seems simple enough and from a strictly mathematical perspective the padded password is substantially more secure. Of course there are numerous methods for padding a password that can make it more complex yet still memorable such as using a series of “/\/\/\/\” rather than “///////“, but does doing this really add that much security? Today I’ll be covering how to attack those password, and find out if it really is more secure.

Method:

There are two common misconceptions I see that people often make regarding passwords and how they are cracked. One being they assume that there are only two methods of attacking a password, those being a bruteforce or a dictionary attack. The second misconception is that they don’t understand the difference between an online, and an offline attack. An online attack is when a program sends a username and password to a server checking the response each time for success. An example of this would be a routers admin interface, and the attack would ideally be done on a device which doesn’t have a lockout policy. This type of attack is usually very slow, and in this case generally the only options are dictionary and bruteforce.

However an offline attack is usually against a large database of password hashes such as a SAM(Security Account Manager) database from an active directory domain, or a SQL database from a forum. There can be hundreds or even millions of password hashes in this database. An offline attack can also be done against a single hash such as a WPA key. Unlike an online attack there are many different ways to attack the password hashes. The attack types includes but not limited to bruteforce (with or without positional mask), dictionary (with or without mutation rules), dictionary combination (with or without mutation rules), and finally hybrid ((dictionary and bruteforce), with or without mutation rules). In the case of password padding the important ones are those that allow us to use rules.
If you read my article “Rule-Fu: The art of word mangling” you may recall the “Z” and “z” rule. These rules basically append or prepend a character N amount of times to the base dictionary word.

Example: Using the rule – Z2 W3akP@$$ becomes W3akP@$$$$ and for z2 W3akP@$$ becomes WWW3akP@$$

It’s easy enough to create a rule set (a file containing one rule per line) that varies the number of appending or prepending characters, to do this I downloaded the latest version of the mask processor from here. Using that I ran the command (Ubuntu 64): (Mask processor uses the same syntax as oclhashcat)

root@erebus:~/maskprocessor-0.63# ./mp64.bin -1Zz -2123456789 ?1?2 > pad.rule


This output every combination of Z or z with 1-9 into a file called pad.rule. This simple rule file is only 18 lines and is probably not very effective. But what if the the last character of the dictionary word wasn’t the one the person padded it with, as in our first example W3akP@$$///////. For that we have to append and prepend every possible character to the original password using two separate commands like so:

root@erebus:~/maskprocessor-0.63# ./mp64.bin -1?l?u?s?d -2123456789 \$?1Z?2 > pad2.rule
root@erebus:~/maskprocessor-0.63# ./mp64.bin -1?l?u?s?d -2123456789 \^?1z?2 >> pad2.rule


In these commands we assign upper, lower, special, and digit to variable 1, variable 2 is assigned 1-9. In Linux \ escapes out the $ and ^ on the command line. Note that the second command has two > so as to append to the file rather than overwrite. The file pad2.rule should now contain 1710 rules to append and prepend every combination of upper, lower, special digit at lengths 1-9 to the base word in a dictionary. Running the rules with a decent dictionary should take a couple minutes if using hashcat or seconds if using oclhashcat-plus. You could even be creative and do a combination of both appending and pre-pending in a single rule.

Example: The rule ^/z4$\Z4 applied to W3akP@$$ becomes ////W3akP@$$\\\\

Now if you’ve been able to keep up with me so far you’ll quickly see that padding a password with a single repeating character doesn’t effectively increase it’s strength, especially if your using a base password found in a dictionary. It’s important to point out that a dictionary doesn’t mean a word you might find in the Oxford dictionary, instead it’s any word that closely matches a word from a list of already cracked passwords. The reason I say “closely matches” is because a dictionary word real or not can be easily modified using rules to covert something like monkey into M0nk3y!.

As a fix you may say instead of using a single repeating character use an alternating set such as ()()()() or 101010. Well there is still one more problem. After talking to Atom the creator of the hashcat suite of tools we came up with two new rules, the Y and y rules. Both are now in version 0.37 of hashcat and will be added to other versions shortly. The Y and y rule append and prepend N charcters from the base password.

Example: The rule $/$\Y2Y2 applied to W3akP@$$ would give us W3akP@$$/\/\/\

As before we can use the mask processor to generate every combination of alternating characters, example:

root@erebus:~/maskprocessor-0.63# ./mp64.bin -1?l?u?s?d \$?1\$?1Y2 > pad3.rule
root@erebus:~/maskprocessor-0.63# wc -l pad3.rule
   18050

Here the variable 1 is assigned all upper, lower, special, and digit, and the rule Y2 is statically assigned. The result is a rule file with 18,050 combinations of two characters that can be appending then doubled. Adding prepending rules would only bring pad3.rule up to 72.2k rules.  Anyone that’s ran my 30k list of rules on the GPU knows that it only takes a few minutes to run, even with a 5.6 million word dictionary. So having a 36k rule set that appends or prepends a repeating set of characters really wouldn’t take that long.

Conclusion:

So does password padding really increase the strength of a password? It really boils down to the method in which you do it. Simply adding repeating characters to it or alternating characters surly isn’t enough. What I’ve hopefully shown here is that there still need to be sufficient level of randomness to your password. The rules I generated were rather simplistic, and with a little thought they could be more effecent and encompassing. To top it off hashcat now supports the –stdout switch, rather than using the more complicated –debug mode. This means you can easily run a dictionary with tables through hashcat passing them through stdin to oclhashcat-plus, effectively having double mutations.

Example: password –> hashcat + tables –> p@$$w0rd –> oclhashcat-plus + padd3.rule –> p@$$w0rd/\/\/\/\

DG

Links: pad1.rule, pad2.rule, pad3.rule, oclhc+rules.rule(30k), hashcat-0.37, maskprocessor

Introduction:

Project Erebus has been in a constant state of change over the past several months. What initially started off as a system with 6 water cooled Nvidia GTX 480′s in a over the top gaming motherboard has morphed into a system with 8 ATI 6970 cards housed in a rack mounted server case. While I don’t think it’s safe to say the transformation is complete it has certainly reached a precipitous. In the ever changing world of computing the bar of performance, and speed are in a constant state of escalation. What one days is top of the line, the next is just old news. At least for a short while I have the honor of setting the bar in some respects, even if it is a losing battle.

The build, V 1.0

Erebus version 1, was composed of a EVGA SR-2 Classified motherboard and 6 water cooled GTX 480′s running at 1504Mhz. Water cooling was done so that all 6 cards could fit into the 7 available PCI express slots. The intention was to leave the center slot open for the Magma expansion bay.  The Magma PCI-E expansion chassis provided room for several more cards, however a limitation of the SR-2′s 32bit BIOS prevented more than 8 total cards. The chassis was fitted with two Galaxy O/C cards running at 1520Mhz, slightly faster then the EVGA cards, but not requiring water cooling. With regards to a full Nvidia system this was one of the fastest personally owned single systems at the time. Any application capable of accessing multiple cards was able to utilize all 3,840 stream processors available in all 8 cards.

Version 1.5

In an effort to increase the available bus speed and the hopes that all 10 slots of the TYAN FT72-B7015 motherboard could be used an order was put in with RenderStream a company based out of Austin TX. The board it’s self is much larger than even the already large SR-2. However the bare bones system consist of an entire chassis and power supply. Simply moving the memory, processors and hard drives over to the Tyan board I was up and running in Ubuntu in no time. At nearly the same time Nvida had released the GTX 580′s increasing clocks speeds and unlocking all 512 stream processors from the GF110 core. Immediately 4 EVGA GTX 580 hydro-coppers were ordered with the plans to order 4 more once they were in stock. It was at that time I discovered that in fact not all 10 slots could be used on the Tyan board, even using the Magma expansion bay.  

There was some issues initially with getting all 8 cards to work, but once the BIOS was configured correctly both Windows 7 and Ubuntu 64 were able to detect all 8 cards. The system consisted of 4 GTX 480′s and 4 GTX 580′s any attempt to add another card regardless of the type would cause the system not to post, it had seemed as if the BIOS was unable to address all cards. Once again I was limited to 8 cards, it was a rather big disappointment because I hoped to be able to use the expansion and have a system with potentially 10 or 11 cards. Then there were rumors that Nvidia was to release the GTX 590′s essentially 2 under clocked 580 cores housed on one double slot card. This would give me the potential to have 16 total cards. However shortly before the release of the GTX 590′s I had decided to make a some what dramatic decision.

Version 2.0

After a short discussion in my frequented IRC channel I immediately searched and found a good price on 8 ATI 6970′s. There was some initial concerns if the Tyan motherboard would support ATI cards at all. I only knew of a small handful of people that had ordered the RenderStream system and no one that I was aware of had even tried ATI cards in the system. All the Nvidia cards were removed and the 6970′s were installed. At first I thought that Ubuntu could only detect 6 cards, but as it turns out there was some issues with aticonfig correctly detecting everything.  Manually setting the necessary configs got everything working and the results have been nothing but positive.

Results:

My first test consisted of running a new oclHashcat Beta application called oclHashcat-lite. Oclhc-lite is targeted at new users of the oclhc series of tools. Without the need to learn all the details of regular oclHashcat. In addition oclhc-lite was optimized for single hash performance utilizing the benefits of round reversal and various other hashing algorithm short cuts and GPU techniques to achieve the highest overall possible speeds. First up was the MD5 hashing algorithm the bench-press of benchmarks immediately showed us results just shy of what was predicted.  Here are the results of the test.

To date these are some of the highest speeds achieved by a single personally owned machine.

Video of oclhc-lite record runs

Multi-hash performance obviously suffers and drops down to 14.8B/sec with 6500 hashes in MD5 using regular oclhc. The setup is relatively new and I plan to continue doing several benchmarks and post them here. For now I’m overall pretty pleased with the setup. For the test that I’ve ran ATI has surpassed Nvidia with ease. The only drawback I foresee is having to run a separate Nvidia system to support those CUDA only apps. Many thanks to those that have helped me iron out the kinks and to Atom for make such wonderful elegant tools

DG

Introduction:

As GPU horsepower continues to increase the time it takes to bruteforce a given keyspace continues to shrink. Cracking a seven character upper, lower, digit, special hash in bruteforce mode used to take as long as 6 months using JTR on a single core CPU. However times have changed and a sufficiently fast system with several GPU’s can bruteforce that same keyspace in as little as two hours or less today. Even with a fast system attacking those 9+ length password can still be a challenge, and can take longer than a security audit can allow for. This is where profiling your hashlist can help target a large majority of hashes, and it can also reveal a password policy trend. For example some password policies state the password must be at least 8 characters, contain at least one uppercase, special character, and digit. From this users typically will capitalize the first letter, and add a special character and number to the end. So today I’ll cover a simple utility that can help you target a smaller keyspace that should increase the likely hood of finding the most passwords.

Method:

The method I’ll be covering uses a Linux environment but most of it can be adapted to Windows. The first step is to download PACK(Password Analysis and Cracking Kit)  a set of python scripts developed by iphelix.  The next setup is to download the latest version of oclHashcat from Hashcat.net. A supported ATI or Nvidia card is required in order to use oclHashcat/cudaHashcat. If you don’t have a supported GPU, this can also be adapted to PasswordsPro  for the CPU but I won’t be covering that here.

In order to use PACK you will need a system that supports python of course, it also uses a python extensions called psyco. Psyco isn’t requried and line 8 and 9 in dictstat.py can be commented out or deleted if you don’t have it.

To get an idea of how it works here is the output after running dictstat.py on ‘rockyou‘ dictionary:

# python dictstat.py -f rockyou.txt

[*] Analyzing dictionary: rockyou.txt
[+] Analyzing 100% (14344391/14344391) passwords
NOTE: Statistics below is relative to the number of analyzed passwords, not total number of passwords

[*] Line Count Statistics...
[+] 8: 20% (2966004)
[+] 7: 17% (2506264)
[+] 9: 15% (2191000)
[+] 10: 14% (2013690)
[+] 6: 13% (1947858)

[*] Mask statistics...
[+] stringdigit: 37% (5339715)
[+] allstring: 28% (4115881)
[+] alldigit: 16% (2346842)
[+] othermask: 05% (731240)
[+] digitstring: 04% (663975)

[*] Charset statistics...
[+] loweralphanum: 42% (6075055)
[+] loweralpha: 25% (3726656)
[+] numeric: 16% (2346842)
[+] loweralphaspecialnum: 03% (472673)

[*] Advanced Mask statistics...
[+] ?l?l?l?l?l?l?l?l: 04% (688053)
[+] ?l?l?l?l?l?l: 04% (601257)
[+] ?l?l?l?l?l?l?l: 04% (585093)
[+] ?l?l?l?l?l?l?l?l?l: 03% (516862)
[+] ?d?d?d?d?d?d?d: 03% (487437)

The output has been trimmed a bit as the output can be rather long. Each [*] section shows the analyzed dictionary in different aspects separately. We can see based on the “Line Count Statistics” that 20% of words are 8 characters, “Charset statistics” show that 42% of all words are loweralpha numeric. Based off this information it would be safe to assume that if you were to bruteforce lowercase and digits up to length 8 you would find the majority of your passwords. The nice thing is that the “Advanced Mask statistics” directly correspond to the format used by oclHashcat’s predefined mask.

Of course it’s easy to analyze a dictionary of already cracked passwords. The hard part is starting with a uncracked hashlist. So the first step is to do an initial run on your hashlist using a standard dictionary. Using oclHashcat+ with a dictionary and a good rule list will likely get you to a good starting point. Depending on if you have a ATI or Nvidia card will determine if you use cudaHashcat+ or oclHashcat+. If you haven’t yet used ocl/cudaHashcat+ you may want to read this over. For example my command was:

./cudaHashcat+64.bin -r ocl+rules.rule -m1000 -n160 -o found.out hashlist.hash /dict/rockyou.txt

In a recent pentest this attack alone netted 26,336 out of 222271 NTLM hashes, or about 11%. From this we were able to determine that the password policy for the company required at least 8 character, with at least one upper, lower, special, digit. From there the password were moved into a dictionary like so:

# cut -b 34- found.out | sort -u > found.dic

From there we can use dictstat:

# python dictstat.py -f found.dic

[*] Analyzing dictionary: found.dic
[+] Analyzing 100% (26336/26336) passwords
NOTE: Statistics below is relative to the number of analyzed passwords, not total number of passwords

[*] Line Count Statistics...
[+] 8: 78% (20683)
[+] 9: 15% (4150)
[+] 10: 03% (1048)
[+] 11: 01% (355)

[*] Mask statistics...
[+] stringspecialdigit: 74% (19652)
[+] othermask: 23% (6287)
[+] stringdigit: 01% (353)
[+] stringdigitstring: 00% (22)

[*] Charset statistics...
[+] loweralphaspecialnum: 53% (14133)
[+] mixedalphaspecialnum: 44% (11708)
[+] mixedalphanum: 01% (377)
[+] upperalphaspecialnum: 00% (91)

[*] Advanced Mask statistics...
[+] ?l?l?l?l?l?l?s?d: 17% (4616)
[+] ?l?l?l?l?l?s?d?d: 13% (3622)
[+] ?u?l?l?l?l?l?s?d: 12% (3300)
[+] ?u?l?l?l?l?s?d?d: 08% (2247)

Using the (truncated) output from dictstat like before we can target those mask that would get us the most return. Keeping in mind that we can use custom mask to target more than just the preset mask.
 
# ./cudaHashcat64.bin --remove -o found.out -n160 -m 1000 hashlist.hash -1 ?l?u? -2 ?s?d -3 ?l?s -4 ?d?s ?1?2?2?2 ?2?3?4?4

Conclusion:

This is just an easy way to reduce the time taken to bruteforce a given keyspace. In the above example there are 19,393,941,834,332 combinations instead of 6,634,204,312,890,625. This of course means that it will drastically reduce the amount of time to run the attack. Of course it’s not likely to find all the hashes, it is however another technique that can be kept in the arsenal. The scripts in PACK can of course be used for several other things such as reports for managment. The README is helpful for the various other switches and options.

Links:

PACK – Password Analysis and Cracking Kit
oclHashcat+/cudaHashcat+
Regular oclHashcat/cudaHashcat
PasswordsPro

Introduction:

Lets face it, when it comes to passwords humans are predictable. Time and time again we see this when a site gets compromised. After the hashes have been sorted the top password are nearly always the same. It’s usually some variation of 1-9, password, iloveyou, princess, abc123, qwerty, 111111, secret, etc. Many of these passwords are unoriginal, and people use these same passwords across all of their accounts. Then their are the individuals that think they are being unique, and will change one of these common passwords to something slightly different for example [password --> Password123]. A dictionary tool with a rule engine can easily find these types of passwords. Up until now all these dictionary based/ rule engine tools have mostly been CPU based (hashcat & JTR for example). Using a dictionary with 14 million words and a rule file with only 3000 rules could take as long as 15 – 20 minutes with a CPU based tool. That same 14 million word list can take about 2 hours using my custom 23k rule set(preloaded in the /rules folder). This is where oclHashcat+/cudaHashcat+ come in.

Application:

oclHashcat+/cudaHashcat+ which I will call “oclHashcat+” for the sake of simplicity in this article is a completely new tool, separate from regular oclHashcat. oclHashcat+ is a dictionary based tool with a full featured rule engine that all run completely on the GPU. In our above example a 23k rule file combined with a 14 million word dictionary would take about 2 hours running on a modern CPU at about 50M password attempts /sec. With oclHashcat+ this same same rule set and dictionary file takes as little as 3.5 minutes using a dual GTX 480 system running at about 2B password attempts /sec. That’s right folks 50M for the CPU vs 2000M on the GPU. But that’s not all, oclHashcat+ offers us a couple of new features which I’ll be going over here.

The first thing to point out is that there are now four separate .bin/.exe files. This is to cover the various different system combinations that people may be running. The switches and syntax for all of these different versions are the same, however depending on your GPU, OS and OS architecture your running will depend on which one you’ll be using. For example someone with Ubuntu 64 running a Nvidia card would use cudaHashcat+64.bin while someone running a Windows 32 bit system with an ATI card would run oclHashcat+32.exe. I find the easiest way to get rid of the clutter in your folder is to delete those extra .bin/.exe files. Since I’m running Ubuntu with nvidia cards I delete all the exe files, and ocl prefixed bin files. Just in case your complete baffled by this here is a simple cross reference table:

The only exception being that 64bit OS’s can run the 32bit versions (oh though I don’t know why you’d want to). The reason for the forking of the project into separate CUDA and OCL variations comes from a programming standpoint, certain optimizations can only be done using vendor specific code. This gives us a nice performance increase because the code is better optimized to support that architecture.

Features:

oclHashcat+ uses a lot of similar switches and syntax as the other Hashcat tools. The attack mode numbers such as 0 for MD5, 1000 for NTLM, 1100 for DCC are all the same. If you run the –help switch it will list all the various switches.

• One thing you may notice is that a few more attack modes are supported now that have only been supported on the CPU version. The attack modes -m 400 covers MD5(wordpress and phpBB3) and -m 500 covers MD5(unix). These algorithms are generally difficult hash types to attack due to the high iteration counts that a plaintext goes through while getting hashed. High iteration algorithms may reduce the overall attacking speed of a hash but it doesn’t do anything to protect those passwords that users always tend to use, even if those passwords are only slightly different from the norm.

• Support for standard in – For those that have already built special scripts or have various other ways to mangle or generate wordlist this is a way to continue to use those. In addition since oclHashcat+ doesn’t support bruteforce style attacks directly you can use the maskprocessor from hashcat-utilities to generate a bruteforce character set and pipe it to stdin.

• GPU based rule engine – oclHashcat+ supports nearly all of the same rules that hashcat supports except for the @ modifier. That means any of the rule list you may have built before to use in Hashcat will also work. You can also generate random rules using the -g switch. -g 1000 would generate 1000 random rules.

Usage & Conclusion:

Here is an example usage and output:
./cudaHashcat+64.bin -r rules/d3ad0ne_23.8K.rule -n160 -o found.out example0.hash /root/dict/rockyou.txt
...
...
Rules: 22656
Platform: NVidia compatible platform found
Device #1: GeForce GTX 480, 1535MB, 1520Mhz, 15MCU
Device #2: GeForce GTX 480, 1535MB, 1520Mhz, 15MCU
Device #1: Kernel ./kernels/4318/m0000.sm_20.64.cubin
Device #2: Kernel ./kernels/4318/m0000.sm_20.64.cubin

Starting attack in wordlist_mode...

p: 553/6494, cs: 1, cr: 1920, cl: 8, rt: 1546.73ms, s:1627030.75k/s
p: 657/6494, cs: 1, cr: 3968, cl: 8, rt: 1200.40ms, s:2096458.25k/s
p: 708/6494, cs: 1, cr: 6016, cl: 8, rt: 1214.36ms, s:2072357.88k/s
p: 740/6494, cs: 1, cr: 8064, cl: 8, rt: 1224.98ms, s:2054383.12k/s

Here we can see that I used the -r switch to specify a rule file, I set the workload to 160 using -n, saved the found hashes in the found.out file using the -o, example0.hash is our hashlist and rockyou.txt is the dictionary file. One thing to note you may have seen a lot of “Skipping invalid or unsupported rule in line ###” This is typical, as oclHashcat+ does not support all of the same rules as regular hashcat. It simply skips the rules but will use all the ones that it does support.

The status output means the following – p:progress, cs:current salt, cr:current rule, cl:current (plain) length, rt:runtime, s:speed.

Something to keep in mind is that for non iterated hashes such as md5, ntlm, md4 you need to keep the GPU constantly busy. That is to say that if you were to try to crack MD5 with no rules using a standard dictionary oclHashcat+ speeds would be very low, this is because the GPU can calculate the MD5 sum of a dictionary word much faster than that word can be sent through the bus to the GPU to be processed. That’s why it’s suggested to use at least several hundred rules. The rules act like iterations, constatly keeping the GPU busy.

oclHashcat+ can be downloaded here
hashcat-utillites can be downloaded here

Check back soon as I’ll cover some helpful tips and techniques.