HOWTo: Crack Hashes Faster in the Cloud!

Hello Again My Friends,

In my last HowTo I explained the process for capturing a WPA2 hashed password and then cracking the hash with Hashcat. One thing I pointed out was that cracking the hash could take days or longer depending on a variety of factors such as:

• Computing power
• Word-list used
• Expanding word-list with Hashcat rules
• Complexity of password

If we address the issue of computing power then the other factors become less of an issue. How can we address this issue you ask? Well for a few bucks you can rent a cloud server to handle the task-at-hand much faster! Today I am going to show you how to achieve this using an EC2 instance from Amazon.

If you haven’t ever heard of an EC2 instance, don’t feel intimidated by the slang. EC2 is a service that runs on the Amazon Web Services (AWS) cloud platform. This service allows you to create “instances”. An instance is simply a virtual machine of some form. Amazon provides a variety of options for instances. We need to pick one that both fits the budget but also fits the task. To identify an appropriate instance in EC2 we want to first determine what we want to accomplish. In this case we want it to crack our WPA2 (or any other type of hash) faster!

Hashcat can use CPU(s) (central processing units) and/or GPU(s) (graphics processing units) to crunch and compare hashes. Typically GPU is favorable simply because it will work much faster. GPU’s are fantastic when it comes to handling tons of calculations quickly. After all, graphics are rendered with complex calculations, and the better the GPU the quicker these calculations can be handled. Hashing algorithms are also just a series of complex calculations, hence why GPU’s are perfect for our task.

We now know that we need an EC2 instance that has as much GPU power as we deem reasonable/necessary. In today’s example we are going to use a p2.8xlarge instance with Ubuntu Linux. This will give us the following setup…

*The p2.16xlarge would be cool too but it’s more pricey, feel free to go for it if it fits your budget!

Their prices are subject to change, but the current rate for this type of instance with Linux is $7.20 per hour. I specify “with Linux” because the price can change based on the OS. Current prices can always be found on their website. You will need to factor a little setup and configuration time into the server once you power it on. Also we are going to run a “benchmark” test in Hashcat from both our local PCs as well as the EC2 instance before we get too far so we know how much faster we are really going to move with the power of the cloud. This should help determine if going to the cloud for this task will be beneficial considering we are paying per hour.

Enough talk, lets begin!

I am assuming before you move on to step 1 you:

• Signed up for AWS and are now ready to create your EC2 instance! They do require a credit/bank card on file.
• Have an hccapx file ready to be cracked. If you need help with getting to that point first, check out my last article HOWTo: Crack WPA2 Passwords – Hashcat and follow steps 1 and 2. We will discuss how to move the hccapx from your local machine to your EC2 instance later on.
• Have a dictionary file either copied from a Kali machine or downloaded from anywhere on the web to your windows machine. A quick search for rockyou.txt is a good place to start for most people new to dictionary lists.
• Are on a Windows PC while following along OR know how to replace the PuTTY & WinSCP steps with Linux alternatives.

Step 1: Set up the EC2 Instance

***While creating this tutorial I realized by “default” I have an instance limit of “0” for this type of instance (p2.8xlarge) but was able to get the limit boosted to “1” by contacting their support through the support tab on the AWS console. (See Sneak Peak for Next HOWTo:) where I snipped a sample from my conversation with their support team. You may also need to do this if you intend to follow along. It took a few days before they granted the request. When submitting the request I just said I was doing research as an IT professional. When you have been approved, these are the next steps….***

Start by logging into your AWS console. Find the EC2 section, and click “launch instance” to create your virtual machine. There are a few steps involved in the creation process.

1. Select the AMI (Amazon Machine Image) – For this tutorial I am going to use Ubuntu Server 16.04 LTS (HVM), SSD Volume Type
2. Choose Instance Type – As mentioned earlier, we are going to go with p2.8xlarge
3. Configure Instance Details – I will leave everything as it’s default setting
4. Add storage – If you have very large word-lists you may want to modify the storage, be sure to read up on how this may effect your hourly cost. I am going to keep the default 8GB provided with this instance.
5. Add Tags – Skip
6. Configure Security Groups – You want to create a new security group with the following settings
   1. Security Group Name – A name of your choice. Let’s say you plan to access this system from home, you can name your security group “home”.
   2. Description – Anything you want to put in here you can.
   3. Type – SSH
   4. Protocol – TCP
   5. Port Range – 22
   6. Source – “My IP” (If you plan to connect to the instance from the network you’re currently on.) This will automatically enter your public IP into the final box.
   7. Click “Review and Launch“
7. You will now see the details of your machine before confirming its creation. Go back and double-check you have the settings you desire.
8. You will also be warned your instance is not free-tier eligible. That is because Amazon does have some EC2 instances that are free to use, but as mentioned earlier the power we want comes with a small price. The free-tier doesn’t have what we need today.
9. Click Launch
10. For security reason you will be asked to generate a key pair. I highly recommend not skipping this.
    1. Ensure “Create a new key pair” is selected
    2. Key pair name – Any name you can remember for the pair
    3. Click Download Key pair
    4. Listen to the little blue box and SAVE THIS WHERE IT IS SECURE AND ACCESSIBLE! It serves quite literally as a key to open a connection to your instance.
    5. Now click Launch instance
11. Your instance will start to be built at this point. While it is being built we will convert the .pem we just downloaded to a .ppk for use with PuTTY. Keep in mind when the instance is done “initializing” it will start automatically! If you intend on walking away from the PC for awhile before the next step I would wait until the instance was running, and then shut it down first (unless money is no obstacle for you)! You can do this by right clicking the instance and selecting “Stop” under “Instance State”. You will use “Start” in the same menu when you want to turn it back on. Also, you are charged for a full hour even if it is running for less time from my experience, so factor that in too (in other words they round up if you don’t use a full hour). Otherwise, lets continue =)

Step 2: Convert .pem to .ppk

We are going to use PuTTY to connect to our new EC2 instance using SSH and the key we downloaded during the setup of the instance. However in order to use the .pem key we downloaded and saved, we will need to convert it to a PuTTY-friendly format (.ppk). For that, we can use PuTTYgen.

1. 1. Download PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html.
   2. Download PuTTYgen also from the same link. You may have to scroll down a bit to find it.
   3. Open PuTTYgen and select “Load”. Find the .pem in the file explorer. You may need to change the file type drop-down (next to the “File name:” box) to “All Files”. By default you may only be shown .ppk files.
   4. PuTTYgen will display a message letting you know the key was imported. It will also tell you what the next step is.
   5. Before we click “Save private key” lets add a passphrase and confirm it in the “Key passphrase:” and “Confirm passphrase:” boxes. Create something you will remember but something secure. Take a mental note of this for when we connect to our new instance.
   6. Now lets click “Save private key” and save the file with a name and location you will remember. Also take mental note of this for when we connect to our new instance.
   7. Close PuTTYgen

Step 3: Connecting to the Instance

Ideally if you are following this tutorial you are familiar with PuTTY and its uses. If you are not familiar with it, just think of it as serving a similar purpose as your web browser. Your web browser connects to a web server or graphic user interface (GUI) of some sort and displays it’s contents on the screen. PuTTY does the same thing but it connects to a command line interface on the target server, router, switch etc. Another big difference is that web browsers rely primarily on HTTP/HTTPS as where PuTTY will leverage TELNET/SSH. This of course is a quick overview and does not by any means cover everything there is to say and know about PuTTY.

We basically want to create a template that PuTTY will use each time we want to connect to this instance to save ourselves some time when connecting in the future. Let’s get started!

1. Open PuTTY
2. We want to add the .ppk to the session/template so lets look at the left hand side of PuTTY and go to Connection>>SSH>>Auth. You should see a place where you can select a Private key file. Click “Browse…” and find the .ppk we created.
3. Next let’s go back up to “Session” on the left hand side at the top. We need to enter the IP address of our new EC2 Instance. As long as your instance is running you should see it’s IP listed under “IPv4 Public IP address” in your AWS console under “Instances”. Enter that into the “Host Name (or IP address)” box.
4. Make sure SSH is selected for connection type and port is set to 22.
5. Lastly lets name the session so we don’t have to do this all over again next time. I will name mine “GPUcracking”. Once you have named it hit “Save”. It will now be listed under Saved Sessions for future access. Keep in mind if your EC2 instance IP address changes after a reboot you will need to enter it’s new IP address, and save the new config.
6. We can finally connect! Hit the Open button. You may receive a PuTTY security alert, just hit yes, you are essentially creating a trust relationship between your machine and the EC2 instance. You only notice this again if the IP changes. We will now be prompted for an username, and the passphrase we setup when converting the .pem to .ppk.
   1. Username – ubuntu
   2. Passphrase for key – (you created this when converting the pem to ppk)

Step 3: Add Kali Repositories

To avoid having to manually compile hashcat from source… (I can maybe do a tutorial on compiling from source in the future, it is huge when dealing with Linux)… we are just going to add the same repository that Kali is using currently. This way we can simplify the install. We want to add the Kali repository to a file called sources.list.

sudo nano /etc/apt/sources.list

You will now be in the nano text editor and see the contents of the sources file. It will look something like this… (this is just a snip, you’ll have more than just this in the file)

You will need to add the following lines to the very bottom of this file

deb http://http.kali.org/kali kali-rolling main contrib non-free
deb-src http://http.kali.org/kali kali-rolling main contrib non-free

You can then hit “Ctrl” and “X” keys together to exit. You will be asked to save the modified version, hit the “Y” key, then hit “Enter” on the keyboard to save. If you are more comfortable in a different text editor such as VIM that would work too. I like nano personally.

You should now be back at the terminal.

sudo apt-get update

This will pull down updates from the preexisting repositories as well as the Kali ones we just added.

Step 4: Install Hashcat and Drivers

Since we have added the Kali repositories, we can now easily download and install Hashcat. Without these repositories, Ubuntu wouldn’t know where to look for the package installer of Hashcat.

sudo apt-get install hashcat

Hashcat required specific drivers in order to compute hashes with GPUs. Our EC2 Instance (at the time of this writing) is configured with eight nVidia Tesla K80 GPUs. Hashcats web-page states “NVIDIA GPUs require “NVIDIA Driver” (367.x or later)”. If we check nVidias website we can find what the newest driver version is for our GPUs. Right now it appears to exceed the Hashcat minimum requirement. In fact this version of the driver is only 2 days old as of this writing!

Before we install the new nVidia driver we need to blacklist (or disable) the default Nouveau open source driver. This is so we don’t have conflicting drivers.

To blacklist the Nouveau drivers we are going to create a configuration file with the options to make that happen.

cd /etc/modprobe.d/

The command above will get us into the proper directory. Next we need to create the file. We can do so in Nano.

sudo nano blacklist-nouveau.conf

We now have a blank file we can edit opened in Nano. Add the following text to the file:

blacklist nouveau
blacklist lbm-nouveau
options nouveau modeset=0
alias nouveau off
alias lbm-nouveau off

To save this file follow the same procedure as you did when editing and saving the sources.list file.

Next, the final steps to taking the Nouveau driver out of order.

echo options nouveau modeset=0 | sudo tee -a /etc/modprobe.d/nouveau-kms.conf
sudo update-initramfs -u

Now lets install our new driver.

sudo apt-get install nvidia-375

Once this is done installing lets reboot.

sudo reboot

Connect back to your EC2 instance after it shows up as running again in the AWS console and log in again. We now need to fine tune GPU’s.

sudo nvidia-smi -pm 1
sudo nvidia-smi -acp 0
sudo nvidia-smi ––auto-boost-permission=0
sudo nvidia-smi -ac 2505,875

nvidia-smi– SMI stands for System Management Interface, it is a set of options we can configure on our nVidia GPU’s, among other management and monitoring settings.

pm 1– Persistence mode = 1, Enables Persistence mode which minimizes driver load latency by keeping it loaded even when not in use. Resets to “0” or “off” when machine is rebooted

acp 0– Applications-Clocks-Permission = 0, Sets Applications Clocks Permission to “Unrestricted”

auto-boost-permission=0– Allows non-admin control over boost mode by setting permission to “0” or “Unrestricted”

ac 2505, 875– Specifies maximum memory and graphics clocks.

I want to give due credit to Iraklis Mathiopoulos for these suggested values above. This article was largely inspired by a similar article he did covering this topic exclusively from a quick config and benchmarking point of view. I wanted to break it down a little more and go in depth, but it all started with his Running hashcat in Amazon’s AWS new 16 GPU p2.16xlarge instance article.

Step 5 (Optional): Benchmark Comparison

Earlier I mentioned we can benchmark our local Linux machine running Hashcat, and benchmark the EC2 instance to make sure using the machine is worth our time moving forward. Being that this machine is equipped with eight nVidia Tesla K80 GPU’s which currently run about $4,000.00 each…..

…..we can almost assume we will be getting a huge jump in performance. That being said the benchmark will show us in actual numbers how much of a boost we will be getting!

From your local PC that you would normally run Hashcat on, open a terminal and type (note I skipped sudo here because I am root on my Kali machine)

hashcat ––benchmark

This will take a while as Hashcat can crack a wide variety of hash types. What benchmark does is it will simulate a quick session which each of the types of hash it can handle. After each session/hash type Hashcat will display the results in the terminal. Set your results aside for comparison when it’s done. In the meantime lets fire up the same thing on our EC2 instance.

sudo hashcat ––benchmark

Now we can side-by-side a few samples and see what these GPU’s really can do for us!

Keep in mind the following when comparing:

• H/s == Hashes per second
• KH/s == Kilohashes per second (Thousands of hashes per second)
• MH/s == Megahashes per second (Millions of hashes per second)

Since I am cracking a WPA2 hash lets point out the boost we can expect there…. My local PC can crunch and compare about 1,900 hashes per second. The cloud GPU’s working together can do about 716,500 per second!!

*I want to point out on my local machine I do not have the option of GPU currently so my results are from Intel i7 M640 CPU with OpenCL running. For this reason you will see a HUGE jump in performance from my local PC the the EC2 instance.*

Step 6: Move .hccapx and Dictionary to EC2 Instance

As mentioned earlier I’m assuming you already have an hccapx file ready to be ran through Hashcat. Same with a dictionary file or word-list (example: rockyou.txt). You most likely have these sitting on a Kali laptop or some other form of Linux. You will need to use some method of your choosing to get those files onto the Windows machine you currently are using PuTTY from. Some ideas are Google Drive, Dropbox, Email, external hard drive/usb drive, LAN file sharing, etc… Once they are on your Window machine we want to install WinSCP to transfer the files to our EC2 instance. At the time of this writing that can be downloaded from https://winscp.net/eng/download.php. The install is rather straightforward.

Once it is installed go ahead and open it….

1. Go to Advanced…
2. Under SSH on the left hand side you will see Authentication, go to that tab.
3. Click the “…” to the right of the “Private key file:” box to browse to the .ppk you are using for PuTTY, and then click Open, then OK.
4. Enter the IP address of your instance under Host name
5. Enter ubuntu under User name
6. Leave password blank – you will be prompted for the keys passphrase that you setup when converting it from pem to ppk next
7. Click Login and enter the key passphrase, that screen should look like this
8. You should now see two main sections on the screen. To your left you will notice your local files. To the right you will notice the files located on your EC2 instance. Find the hccapx file and the dictionary file in your local files and then with your mouse click and drag them over to the directory of your choosing in the EC2 instance. It is that simple. You can now close WinSCP. Be sure to note where you moved them to as you will need the file paths in the next and final step!

Step 7: Crack the Hash Fast!

Lets fire up Hashcat with our hccapx file and our dictionary file. Replace the last two paths and filenames in the string below with the paths and filenames for your files if they differ from mine.

hashcat -a 0 -m 2500 -r /usr/share/hashcat/best64.rule /home/ubuntu/cap-fid03.hccapx /home/ubuntu/rockyou.txt

***Note – I am running the same rules, against the same dictionary, against the same hccapx file as I did in my last tutorial for the purpose of being able to see in practice how much faster this would work. If you feel lost by anything going on here, be sure to check out HOWTo: Crack WPA2 Passwords – Hashcat.***

WHOA! So the first picture below is the results from my local PC when I did my last tutorial… Took about 1 hour and 15 minutes to crack. Not bad but also this particular SSID didn’t have a very difficult password.

Now lets check out the EC2 results….

…. It took 8 seconds…. to crack this WPA2 hash/password. I will avoid publishing the actual password. I will say it was a decent length (10 characters) BUT it was a just 1 word, capitalized, with no numbers or special characters. Wow!

Concluding Thoughts

This should strike you as super cool but also a little scary. As new GPU technologies and those alike advance, the power to crack passwords faster will become more readily available. I was able to get all of this power rented from Amazon for just a few bucks. For a few more bucks I could have DOUBLED this power with 8 more GPUs (going with the p2.16xlarge instance). GPU’s are set on a path to only continue to advance, especially as AI (artificial intelligence) becomes bigger and more prevalent in our day-to-day lives. An example of a technology that is up-and-coming that requires this sort of advancement to occur is self-driving vehicles. They need to not only make tons of complex decisions every second but also need to “learn” and “predict” on demand, very quickly, based on statistical data!

So what are we to do about this problem? Well there is a few options currently. The quickest and least technical is to simply have long passphrases that are more like a sentence than simple words and their variations. The better and more technical option is multi-factor authentication. This tends to include 2 or all of the following to authenticate your identity:

• Something you know (password or passphrase)
• Something you are (bio-metrics – iris scanner, finger print scanner)
• Something you have (FOB, access card, cell phone, etc)

In the past (and still today) many sites like have used something you know twice (a password along with a security question). The inherit problem with this is that people often use simple passwords and even simpler security questions to reset the password if needed. The security questions are often easily guessed, or have answers available publicly on the internet. You will now notice people like Google have moved to something you know (password) and something you have (cell phone where they send verification code) when you need to reset a password, or a login is detected from a strange place.

Given enough time and dedication, even these methods will only deter; not fully prevent a security breach. There are already POCs (proof of concepts) on the web where fingerprint scanners are being tricked, and where SIM cards inside cell phones are being cloned. Only time will tell what new and creative things we humans will think of next!

Thanks for reading!

-N0ur5

 

Save

Save

Save