Password cracking might be my favorite attack vector in the modern IoT landscape. There’s just something magical about firing up hashcat or John the Ripper and pitting your hardware against the product of questionable, human password choices.
Let’s begin with a brief walkthrough of hashcat. For those unfamiliar, a hash is an encrypted string of text, usually password text in the context of Information Security. Supporting a lot of different hashing algorithms, hashcat has an option for cracking almost any kind of hash.
Hashcat also supports several different attack modes:
Dictionary – Works through a list of potential passwords, trying them until one works.
Combinator – Concatenates words from multiple wordlists in attempts to guess right.
Brute force – Trying all combinations of characters in a given charset.
Hybrid – Combining wordlists with masks, using the added specificity to increase efficiency. No disadvantage compared to brute-forcing.
I’d like to continue with a brief demonstration, to give any readers unfamiliar with the tech some better context for it.
Usage is more straightforward than the startup text would have you believe.
-m specifies the hash type.
– a defines the attack mode.
Hashcat uses rules to add further variation in hopes of guessing right.
Transmutation (aka randomness) can be applied using hashcat’s “rules.” For instance, if a wordlist file had input like “dog” to try as a password, transmutation can be applied to turn “dog” into d0g, DOG, doG, etc. Using the command -r will let you specify a rule file.
If we’re running hashcat in Kali Linux, we can use any of the pre-packaged wordlists in Kali by typing “locate wordlist” in the terminal, but if not – don’t fret. There are thousands and thousands of wordlists available online, ranging from the massive (https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm) to the minute (https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm). Crafting a good, useful wordlist is an art in and of itself, but that’s a topic for another day.
Now, that’s pretty cool on its own, but let’s say we’re a threat actor, and we want to achieve more processing power than a gaming desktop someone might have on-hand.
To that, I say, cloud computing.
Making an account on most cloud computing sites is easy as pie. DigitalOcean, my favorite VPS provider, just requires a simple email address & password, then later a payment method.
Alright, so we have a cloud computing account, and we haven’t disclosed any personal information like legal name, street address, or anything identifiable. The exception would be the credit card I charged my rented server too, but I could have easily used a prepaid card or an unverified PayPal account.
So now let’s see what kind of firepower we can muster for a more aggressive hash cracking approach.
DigitalOcean offers 32 core CPU virtual machines, which is about four times as many cores as my gaming desktop has. DigitalOcean’s VPS seems like an excellent choice; so I’m going to spin up the premium VM they offer at the cost of $.952/hr. You’ll note that the total cost would work out to about $640/month, which is considerably costly — but for our purposes, we’ll likely only be running our VM for a handful of hours, then destroying it; which means it will stop accruing costs.
I’ve just done so, and logged in, changed the default password. Now it’s time to run a series of commands to install Hashcat.
sudo apt update
sudo apt install cmake build-essential
sudo apt install checkinstall git
git clone https://github.com/hashcat/hashcat.git
git submodule update –init
I love the smell of SSH in the morning.
When you’re done, the last command has you check your Hashcat version. If everything was completed properly, you should get a reply that looks something like this:
Excellent! Now we’re going to need some OpenCL software which hashcat requires to utilize the CPUs for cracking. To this end, follow the commands below:
tar zxvf opencl_runtime_16.1.2_x64_rh_220.127.116.11.tgz
sudo hashcat -b to verify
It’s worth noting that if you’re running hashcat on a different OS than Ubuntu 16.04, your wget link will differ.
Okay, so let’s run hashcat on our local gaming desktop, and also on a cloud server with 32 CPUs, and compare the difference.
Alright, so we’re just about ready to run the hashcat benchmark. For this, we’ll use the following command:
For my first benchmark, I utilized a 4 GB memory, 2 CPU server with 80 GB of storage.
Not too shabby. To reiterate, 94431 kH/s means we’re attempting to guess the hash correctly 94,431,000 times per second. Of course, this is pulling the MD5 hash, which isn’t as secure as the standard SHA-512, which we’re guessing 9,846,000 times per second. Even more difficult, WPA/WPA2, the latter of which is an industry standard level of secure, we’re only guessing about 3,536,000 times a second. That may seem like a lot, but without an original wordlist and an accurate set of rules; it’s not stellar.
Alright, so it looks like DigitalOcean had temporarily restricted access to 32 CPU servers right when I was writing this, which means I won’t be able to demonstrate with the highest, ideal amount of hardware. That being said, I think the high demand alone proves people are utilizing these high CPU servers for something, and something powerful at that.
I’ve just resized my original hashcat server to a 24 CPU size, and I’m going to run the same benchmark now.
Wow! We’re now guessing at the rate of about 83,842,000 hashes per second for SHA-512, a very secure standard. That’s nearly 10x as much hash power as our cheaper server was providing us. SHA-256, which is still used in some contexts, is pulling about 466 million hash guesses per second. That’s just incredible.
So it’s pretty clear that we can rent out a powerful 24 or 32 CPU server and drastically improve our efficiency — but can we take it to an even higher level? Is there some way to get more processing power to leverage, despite DigitalOcean capping server size at 32 CPUs?
Yes – Part 1
Okay, so let me try to introduce briefly a mathematical concept we could use to better our hash cracking efficiency. A Markov chain is a statistical analysis of some dataset. Markov chains are called “chains” because each condition change is dependant on the current condition state. We can look at factors which have historically (or analytically) influenced the condition change, and use analytic or historical measures to assume the most likely next state.
In our specific context, it means we’re going to feed our software a massive list of real human passwords and command it to analyze the structure of each password, which will inform it’s step by step, character by character progression when creating or preparing hash guess attempts.
Hashcat supports a command called “hcstatgen” which can be pointed at a list of plaintext passwords, or strings of any kind to analyze. You’ll point towards an output file which the stats will be stored.
Next, you’d need to download the “statsprocessor” tool (https://github.com/hashcat/statsprocessor), which “is a word-generator based on per-position Markov-chains packed into a single stand-alone binary” according to the developer’s GitHub page. In simple terms, it’s going to do what you’d assume and process our stats file into a good logic flow to guess the next letter in a password, based on the previous letter.
You can pipe those files into Hashcat-plus and use them to run a highly efficient hash cracking effort. It’s also worth noting that John the Ripper (a highly popular password cracking tool) also supports Markov Chains, but not on a per-position basis — meaning they don’t take into account which # letter in the password we’re currently guessing, which can increase accuracy/success.)
For more information on Markov Chains as they relate to hash cracking and hashcat, Daniel Turner has written an excellent guide here (https://www.trustwave.com/Resources/SpiderLabs-Blog/Hashcat-Per-Position-Markov-Chains/)
Yes – Part 2
Hashcat is open source, so anyone with the mind to can develop tools to work with. In fact, there are several tools developed for the extension of Hashcat into multiple instances, sharing the workload across as many devices as you can set up (or at least until the strain becomes too much). The original software, Hashtopus is available here (https://github.com/curlyboi/hashtopus) but abandoned by the developer. Another better-forked version is available from Sein Coray’s GitHub page here (https://github.com/s3inlc).
Time to crunch some more numbers.
If we can achieve a hash power of X with Hashcat running on a single 24 CPU DigitalOcean server, then let’s say we spread it across six rented servers of the same size, giving us a total hash power of 6*X. We’re still only looking at a price of about $1.43 / hour, which is incredibly cheap for that kind of has power.
Let’s say we’re a real scary threat actor, and we’re trying to push our efficiency to the limits. Assuming the best-distributed wrapper for Hashcat probably supports a maximum of 20 machines (just guessing, but it has to cap somewhere, and I’m thinking the returns are exponentially diminishing at some point).
We’re now looking at 20*X hash power, at the modest cost of $4.76 / hour. And keep in mind as a threat actor we’re probably only running our hash cracking for a few hours, maybe six or eight at the most, and calling it a day (that should be plenty of time to crack any passwords that aren’t exceedingly complex, especially with that kind of hash power).
I realize this has been a lengthy article, but I’m finally coming to my conclusion. It’s a little absurd to me that you can rent out this amount of hardware with so little identification or authentication, to circle back to the earlier screenshot of DigitalOcean’s signup page.
If I was a malicious actor and I wanted to spin up X hash power of servers to crack passwords, it’s exceedingly easy to do so, and leave little to no trace of yourself doing so. I think that represents a massive issue for cybersecurity.
It’s not a perfect metaphor, but guns require legal identification, and a registry in some cases, due to their potential for destructive misuse. In the era of technology and the Internet of Things, computer systems of any kind have massive potential for abuse, and I’m not just talking about hash cracking.
You can host malware on servers like these for deployment upon unauthorized access; you can run password cracking farms, you could probably create pretty impressive DDOS effort if you invested in huge quantities of low-quality servers, and so on. I’m sure there are more ideas more experienced information security specialists could point out, but you get the idea.
I think from a practical standpoint, the field of cybersecurity would benefit by pushing industry-wide standards for identification in any digital or online server or cloud rental business.
So why doesn’t the industry adopt stricter standards for account registration? I asked an anonymous JD candidate friend of mine, and this was his response,
“In my opinion, the Internet is very much about looking the other way with anything fraudulent or malicious. There’s no common law duty to report suspected malicious activity on the internet, and there’s no statutory requirement either.
Many sites are well-aware how their platforms are being used – but they don’t want to open themselves to any criminal or civil liability unless the government compels them to. For example, Comcast and other service providers were likely very aware that users were utilizing TOR and other instruments that are, in all likelihood, used for unlawful purposes, but they did nothing until rumors began that Congress or affected classes might hold them accountable for damage done while users were in TOR.
Only then did Comcast (to my knowledge) begin advising users of alleged terms of service breach. Nothing will change unless Congress takes action, and even if they do, corporations are notoriously good at perfecting the art of feigning ignorance.
Exposure to liability makes the world turn. Until these sites get a juicy lawsuit or criminal sanction, I don’t think they’ll have the incentive to care.”
An excellent point, and I think it highlights the beauty of our chosen field. At the risk of waxing poetic, the landscape of the Internet will probably never be a perfect haven for what’s legal, what’s practical, or what’s necessary. It’s a fascinating hodgepodge of different parties’ interests, different technologies coming to life, and the people who now live in a world shaped by that technology — and I think that’s what we all love about it.