Passwords to secure access to resources have been around for longer than you might think. For us, what might come to mind is a login password for a computer or an encryption password to keep data confidential. But consider that the Romans also used “watchwords” for military purposes. In other words, secret phrases have been in use for a long time in security.
This article will discuss the use of cracking cloud computing resources to crack password hashes. As password cracking stations can be expensive to purchase, tend to age quickly, and run idle for long periods of time, the shared nature of cloud environments makes the cloud a great alternative to an on-premise cracking station.
Let’s start by ensuring that you have some important prerequisites in place:
- Understanding the basic principle of password hashing, including the why and how
- Understanding why hash cracking is resource-intensive
- Having basic Linux CLI proficiency
Password Hashes: Which Types, and How They Are Obtained
During a Red Team engagement or a penetration test, you might stumble on password hashes lying around in a file on a shared folder (e.g., in config files or /etc/shadow). Or perhaps you dumped them from LSASS memory on a Windows system.[1] Maybe you requested a Kerberos ticket for an account that has a Service Principle Name (SPN) set,[2] or DCSync-ed a user’s credentials,[3] and now want to get the plaintext password from the NThash.[4]
Once you obtain this hash, it could be reusable in a Pass-The-Hash attack (e.g., NThashes),[5] but oftentimes it will not be. A Kerberos ticket giving you access to a service will not allow you to impersonate that service account. An /etc/shadow hash will not be immediately reusable.
Cracking Password Hashes
For most password hash types, cracking will thus be needed to identify the plaintext password corresponding to the obtained hash. This generally means loading the hashes in a cracking program, which will generate password hashes for the corresponding type using plain-text inputs that we define. When the program generates a password hash that is identical to the one we stole, we know the corresponding plain-text password (or, in the case of hash collision, a different value that yields the same hash, but this will often not make a difference).[6]
A couple of tools are available toward this end. An older one is Cain, a Windows-based program. More recently, there’s John the Ripper and hashcat. We’ll be focusing on hashcat, as it has great support for GPU accelerated cracking.
Hashcat takes a number of options. We’ll be discussing the main ones here:[7]
-m : Hash mode, defines the type of hash we’ll be attacking. Some examples: 0 for md5, 1000 for NTLM, 13100 for Kerberos RC4, and 1800 for the $6 Unix hash
-a : Attack mode: 3 for brute-force, 0 for wordlist + mutation rules
-o : Output file
-r : File containing the mutation rules for the wordlist
hashesfile : File containing the hashes, 1 per line
wordlist : The wordlist to be used
A short word about mutation rules. Hashcat can generate multiple password guesses per word in your wordlist through the use of mutation rules. One such rule could be to add a 1 to all passwords tried, using the “$1” rule (without quotes). Hashcat will then take your original dictionary entry (say, “Summer”), and try “Summer1” as a password.[8] There are many resources online about which mutation rulesets are best.[9]
AWS and Password Cracking
Amazon Web Services (AWS) offers a great deal of setups that will allow you to do GPU accelerated password cracking. At the time of this writing, AWS’s EC2 instance p4d.24xlarge is the most powerful single machine you can set up for this purpose. It houses 8 NVIDIA A100 GPUs, giving you a lot of computing power to work with. If you’re curious as to the performance of other EC2 instances, consult the list on Github.[10] Be aware, however, that older or less powerful instances are not necessarily cheaper per computed hash. At the time of this writing, the p4d.24xlarge has an hourly rate of US$35.39 in the Europe (Ireland) Region, while p3.8xlarge (housing the less powerful NVIDIA Tesla V100 GPUs) is priced at US$13.22 per hour. However, though the p4d.24xlarge is about 2.7 times more expensive per hour, it generates NTLM hashes about 9.5 times as fast as the p3d.2xlarge. For Kerberos RC4 tickets, that factor increases to 14.5. Less runtime means less costs in EC2, which means that you can get a lot more bang for your buck by making a short calculation as to which instance type you choose.
Setting Up Your AWS Account
The first thing you’ll need is an AWS account to play with. Surf to https://aws.amazon.com. If you don’t have an account yet, follow the Amazon tutorial,[11] which explains in detail how to set up a new account. Don’t forget to add 2FA. It is also a good idea to create an IAM user that will have more limited access to your AWS account (for which there is another Amazon tutorial).[12] Finally, be aware of the costs you are incurring by running machines: leaving an instance running on idle can become expensive quite quickly. Consider setting budget limits (Googling that will get you there).
For this blog, we’ll be setting up a single instance of EC2 for password cracking. If you want to automate some of this, you can use NPK.[13] This framework will help you with AWS automation, and can be quite useful, although it may take some time to set up.
Once you’re logged in, check the region (on the left at the top of the window) where you want to create the new instance. For this example, we’ll be using “Europe (Ireland).” Beware that moving instances between regions can be a hassle, so it’s best to consider your choice well before deciding.
I’ll be assuming that you know how to set up an EC2 instance in AWS. If you’re not familiar with this process, I refer you to two different resources.[14] We’ll discuss the parts of the process where we need specific options set.
In the top search bar, type EC2 and click the “EC2 – Virtual Servers in the Cloud” link.
You may encounter a vCPU limit on your account, especially if you just created it. Open the Billing tab on the left and type vCPU in the search field. If you see any number below 96 for the P instances, you won’t be able to deploy a single instance of the p4d.24xlarge. In that case, select the “All P Spot Instance Requests” and click the top right button to request a limit increase. Note that it can take quite some time and even prove impossible to raise your vCPU limit, as Amazon attempts to protect you against unexpected billing. It is best to set this up well beforehand, and to discuss your case with Amazon Sales in order to expedite the process.
On the left, click “Instances,” and then on the top right, choose “Launch instances.”
The first step is to choose an Amazon Machine Image (AMI). AWS offers a lot of possibilities to customize your image, but for our purposes, the Deep Learning AMI Ubuntu will provide almost all the tools we need for password cracking. In the search bar, type “Deep Learning,” and select “Ubuntu.”
In Step 2, we’ll select an instance type. For this demo, let’s choose the p4d.24xlarge. You can filter the instances by family (p4). See your previous calculation to determine which instance type is the best fit for your application.
Once your instance is running, connect over SSH. Download (using wget, for example) the password file that you want to use as input for hashcat. Some great resources can be found on WeakPass.[15] Particularly effective is Rockyou2021.txt, a remake of the infamous rockyou.txt that was included in many offensive operations Linux distributions. This new iteration is about 92 GB large, a tad bigger than the old one (133 MB).
You may also want to use mutation rules for your wordlist attack. Some handy ones can be found on Github.[16] OneRuleToRuleThemAll will generate about 52,000 mutations for every single input password, so be mindful of the computing power this will require (and the cost it will generate). Luckily, hashcat will show a pretty precise estimate of its runtime once it gets started.
Now we’ll construct the command we’ll be using to run the cracking. First, start a new screen session by issuing screen –L (which will enable screen logging).
Inside that prompt, we’ll be issuing the following command:
-i : Keep stdin open when not attached
-t : Allocate a pseudo-tty
-v : Mount a resource from outside the container. This will be the folder containing the input files, wordlists etc. We’ll be using a folder called transferfolder for this. We’ll be putting our wordlist, mutation rules, session files, and output files in there. The mountpoint will be /transfer.
The command to be run is javydekoning/hashcat:latest. Javy De Koning was so kind to share a docker container optimized for hashcat password cracking with the community.[17] This greatly simplifies our work in getting hashcat to make optimal use of the computing power at our disposal.
Next, our hashcat command is composed as it would be on a local system:
-w 4 : Let hashcat use full system resources (workload = nightmare)
-O : Use kernel optimization
--restore-file-path : If hashcat interrupts, it can be restarted from this restore file
-m 1000 : The type of hash we’re cracking, in this case NThash
-o : Output file
-r : Mutation rules (see above)
/tf/input.txt : The text file containing the hashes
/tf/rockyou.txt : The password list.
If this is the first time you’re running this command, docker will download the latest image for this container. After this download, the docker container will initialize the GPUs and start distributing the work among them as it would with a local setup.
Cost Improvement: Scripting a Shutdown
With some simple bash scripting, we can easily have the EC2 instance shutdown after hashcat exhausts the password list. This, combined with a storing of input and output files on an S3 bucket, will allow you to have the EC2 instance running only when conducting actual password cracking.
With some skills in developing pipelines, you could set up a system that takes your hash as an input and will automatically spin up EC2 instances to start the cracking. However, if you only need such functionality from time to time, it may not be worth the effort to set up such a system.
S3 buckets, which have made the news in the past when they were left accessible to anyone, nowadays incorporate some default settings that make them easily secured from public access. Storing the output of your hashcat session in an S3 bucket will allow you access whenever your EC2 cracking instance is offline.
Summary : Cloud Computing for Password Cracking
Password hash cracking rigs can be expensive to buy, especially if they are going to be running idle most of the time. Cloud computing offers a great way to share such a resource on a metered connection, allowing you to easily scale the computing power at your disposal to crack password hashes. You can run multiple cracking efforts in parallel, only pay for the computing power when you actually need it, and have the most recent computing components at your disposal without having to purchase them. Furthermore, you will be able to show your client how much (or how little) the cracking effort for a particular password hash would cost. This can go a long way in demonstrating the danger of using passwords that are too simple.
[1] https://blog.gentilkiwi.com/mimikatz
[2] https://www.redsiege.com/wp-content/uploads/2020/08/Kerberoastv4.pdf
[4] There’s a lot of cross-use of the name NThash, NTLM hash, etc. For a disambiguation, see https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4
[5] https://dmcxblue.gitbook.io/red-team-notes/lateral-movement/pass-the-hash
[6] Actually we’re cutting a corner here (albeit a small one). If a system stores a password in two different hash formats, and we obtain a clear-text password for one of the formats due to a collision, it’s very unlikely that the second algorithm will suffer from the same collision, thus making the usability of the colliding plain-text dependent on which of the two hash formats is checked upon authentication.
[7] For a full reference, see https://hashcat.net/wiki/doku.php?id=hashcat
[8] For more information, see the ArmourInfoSec article at https://www.armourinfosec.com/performing-rule-based-attack-using-hashcat/
[9] For a comparison, see https://forum.hashkiller.io/index.php?threads/hashcat-rules-comparison.39721/
[10] https://github.com/javydekoning/aws-hashcat
[11] https://aws.amazon.com/premiumsupport/knowledge-center/create-and-activate-aws-account/
[12] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console
[13] https://github.com/c6fc/npk
[14] The two are https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html and https://www.guru99.com/creating-amazon-ec2-instance.html.
[15] https://weakpass.com/wordlist/1851
