There is a time for subtly evaluating a target, spotting a potential vulnerability, and quietly exploiting it to accomplish a goal. There are also times when it is fun to swing the big meat axe to obliterate obstacles with overwhelming force. This is part 5 of my Journey of Learning, if you need to catch up, the last post can be found here. Today I am going to write about fun stuff like cracking passwords, brute forcing things, and playing with the tools that are likely to cause a lot of noise. I am always surprised at how rarely I get to crack passwords or brute force things during my pentesting training. Some days I get lucky. Maybe I get a challenge that drops a nice /etc/shadow file in my lap, or zip backup that has someone’s username and password in it. On those days, it is nice to know how the tools work.
Cracking Passwords is easy, right up until it isn’t.
When it comes to cracking hashes and passwords, there are two ruling tools, John the Ripper and HashCat. Both are included with Kali Linux, and I use them both. From what I can tell, John is best used for things like zip files, password protected private keys, and things like that. HashCat, as the name might lead one to think, is helpful when dealing with hashed values. Each have their strengths, and both are valuable tools in the toolbox.
Both tools are easy to get a hold of, they are free to download on the internet. These tools have legitimate purposes outside of CTFs and hacking. Maybe you found a zip file on a disk tucked away in a box in the back of the closet and you want to know what it is. John can help you with this. Feed it the zip file, and it will try to crack the password for you. If you were following good password recommendations, John will probably not crack that password any time soon unless you have a good word list to work with. To crack a zip file with John, I just need to run two commands. First, zip2john extracts a hash value from the archive, like this:
$ zip2john ./secrets.zip
ver 78.8 secrets.zip/secretpasswords.txt PKZIP Encr: cmplen=42, decmplen=30, crc=1C0291E
secrets.zip/secretpasswords.txt:$pkzip2$1*1*2*0*2a*1e*1c0291e*0*31*0*2a*01c0*66e9*eb0f5f30d3eccc5dfe752ec31ab0c8f421a3b79bb31ecab3f9f8a7919ddbf349c5c3047bba997a9c22c9*$/pkzip2$:secretpasswords.txt:secrets.zip::./secrets.zip
With that hash value extracted, the second command tells John to use the rockyou wordlist, to try to find the password for the zip file. Rockyou is a famous word list, it has 14 million passwords from previous data breaches.
$ john –format=PKZIP –wordlist=/usr/share/wordlists/rockyou.txt secrets_hash
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Will run 6 OpenMP threads
Press ‘q’ or Ctrl-C to abort, almost any other key for status
poohandpiglet8326 (secrets.zip/secretpasswords.txt)
1g 0:00:00:01 DONE (2021-06-25 13:06) 1.000g/s 4583Kp/s 4583Kc/s 4583KC/s pop1937..ponies26175
Use the “–show” option to display all of the cracked passwords reliably
Session completed
I would like to draw your attention to 3 things at this point. First, the password poohandpiglet8326 is long, but only lowercase with some numbers. Second, this took less than 1 second to complete. Third, this was done on a virtual machine. The cellphone that you are probably reading this on, has enough power to crack that password in a few seconds because it is on a popular wordlist. Changing the digits to something else, would have made this a very different process. If you are wondering, PoohAndPiglet appears in the rockyou word list with three different variants. Pooh appears more than 8000 times.
There is enough content out there to explain how and why passwords should be long and complex. But maybe a better exercise would be to try see what it takes to crack a password that is not on a word list. When I generate a password, I have two ways of handling doing it. Most of the time, the password is generated with a password generator, giving me 15-20 random symbols, which are put directly into my password manager. For some things I use a combination of multiple words that occur to me at that moment, and I mangle the characters a bit. I shift the case, swap letters for random symbols or numbers, combine words, etc. The result of that mangling goes into the password manager too, because I have a lot of passwords and I don’t want to try to remember them.
The first method is far better, but more important than complex passwords is to have unique passwords. Password reuse is a very successful attack scenario. Breached passwords get published, and if those passwords are leaked with the username, it leads directly to credential stuffing attacks. But this post isn’t about brute forcing stuff, so let’s try and crack some more complex passwords, shall we?
Suppose I stumble across a couple of weird looking strings. Maybe they were in a database, maybe there were lying around on a post-it notes, maybe they are the text of a CTF challenge. You know, common things that happen all the time to people, right? These came from a web server for a blog dedicated to that little fluffy blue mischief-maker Stitch.
gregporterfield:$6$TpnfrZcijbDTIBbp$HgpNoowsMbYdvDHhI4rFBjYXEKlSYhPCiAYF6JJdsfPblf7XH1hr58UOWWk4vmv4VnttJ/L7im5bnkVWBkJ4y/:18804:0:99999:7:::
lxd:!:18804::::::
marysmith:$6$Gfwt7h3xU7KSHi.v$rQ89w.amEEwl.lJbBb9oK2BaFboeE1P5kCBNyPzo6grBeXzRdaB2NVRw/JcqZFHKk8IuSFR5cniULsHDRXnor0:18804:0:99999:7:::
Perhaps you, like me, cannot tell the difference between sha512crypt, and blowfish or any of the hundreds of hash types without looking them up. It is ok, there is a tool for that. I personally like Name-That-Hash.
Name-That-Hash tells me that this is a SHA-512 Crypt hash, and it also gives the HashCat mode or John the Ripper type to be used to crack it. If this were a CTF, I would throw this into HashCat with the rockyou wordlist and before too long I would be submitting a flag. The thing about sha-512 crypt hashes is that breaking them takes time. It is an intentionally slow algorithm. That slowness is caused by the application of thousands of rounds of the hashing algorithm on the password.
While I wait for HashCat to do its thing, maybe I find a note laying around about a new password policy and recommendations. The new password policy talks about complex passwords and provides a helpful suggestion for how to build strong passwords based on your favorite cartoon character. In this case, the suggestion is to combine the names of two characters to give the password some length, and to mangle some characters to make it more complicated. Good advice, but probably don’t leave this kind of thing laying around.
The timing is good because I just saw the bad news on my HashCat run Status: Exhausted. *sad trombone sound*. The exhausted status means that HashCat has reached the end of the wordlist and failed to find a matching hash.
The password policy note gives me a new idea to play with. Instead of using a list of 1.4 million old passwords, what if I make up my own word list. I know these folks are obsessed with Stitch, so I’ll start with a list of the characters in from the Stitch movies and shows, maybe narrow things down to the main characters and important key words. Using a quick Python script I do a little bit of mangling, to get a lot of permutations of the various words with one character swapped out for a number or a symbol. Then, I am going to throw that into HashCat and use a combinator attack.
A combinator attack uses two lists to guess the password. Each word in the first list, will be combined with each word from the second list. If each list has 200 words in it, HashCat will make up to 40,000 guesses. These attacks start to demonstrate the power of tools like HashCat.
The Python script took 15-character names and created 600 variations of those names. Now I am going to tell HashCat to run through all the combinations of those words, 360,000 combinations in total and try the combined value, adding an exclamation point to the end. It sounds complicated, but HashCat is doing all the work for me. I imagine there is data out there about character frequencies in passwords, but it seems like “!” is probably going to be a safe bet.
Eureka! I got a hit. Turns out the hash that starts with “$6$Tpnf” is matched to St1tch&Jumb@!. I did not get the other password. There are a few things that I could also try to get the other password. When combining the two values, what if a person used the word “and” instead of “&”. Another thing is the last character could be something other than an exclamation point, there are lots of symbols on the keyboard. I could also use my script to combine the values myself, or I could pull out another tool called Mentalist, which can do this for me.
With a few button-pushes, I can take the 600 mutated words, and further mutate them with special characters on the end and adding different of joining strings like “&” or “and” to the beginning. When I put this into HashCat as part of the combinator attack, I should get both passwords in one go.
In two mutation rounds, I took 15 words, and created 14.4 million variations. 14 million variations of the combination of 15 words. A while back I was trying to get a word list created for a challenge based on town names. With only a few mutations the list ended up being 4 TB in size. I was not paying attention and almost crashed the machine while waiting for it to write the file out on a VM with 40 GB of disk space. These lists can get big quickly, and the larger the list is, the longer it takes for the tool to do the work.
Tools like HashCat and John the Ripper can use rules to create variations of wordlist entries. Just like I did manually, there are dozens of rules in both tools that are going to increase the number of guesses and reduce the amount of active “hands-on-keyboard” work needed to crack hashed passwords.
If good password complexity is being used. When an attacker gets a hold of a database of hundreds or thousands of hashes it is likely that some of them will be on common word lists with simple mutation rules. An attacker does not need to crack all the hashed passwords. In some cases, they only need to crack one. It is surprisingly easy to defeat most of the rules out there and turn even the most expensive cracking rig into a very expensive space heater. Be creative, unique, and unpredictable, and/or use a password manager with a strong passphrase. Also, if you have an obsession about a certain fluffy blue mischief maker, and you post about it a lot on social media, and it shows up in the background of your Zoom meetings, or is on the t-shirt you are wearing, maybe don’t use that as your password, or any part of it.
As a bit of a follow up, that HashCat run with the 14 million combinations of Stitch character names finished successfully. It took a little over an hour, but it recovered both hashed values, St1tch&Jumb@! as well as L4royAndReub7n*. Fun!
But what if I don’t have a hashed value?
Sometimes I need to try different passwords on things directly. For example, a server that allows SSH logins, or a login page for the administrative console for a blog. For this kind of thing, THC-Hydra is the tool that I find the most helpful. Hydra is the Swiss Army Knife of brute-forcing tools, I have only ever used it for SSH and web application login pages, but it can do a lot more. Hydra is an older tool, but some things do not really need to be rebooted, they just work as they are. Nearly any kind of network login you can think of is supported by Hydra, HTTP, FTP, various mail protocols, RDP, SSH, etc. Hydra has configuration options that allow me to throttle the speed and frequency of the requests, and it can run multiple requests at the same time. Hydra is a battering ram, it is noisy, but it works.
Instead of playing an attacker on this one, I am going use Hydra for a personal password recovery for a box that I forgot the password for. I kind of remember how the password was put together so I will just try things and see what happens. If I can’t get into the box there are other things that I could try, or I could just throw the VM away and start over. With all the VMs and crazy projects that I spin up for blogs and whatnot this is a scenario I have run into before.
Like most brute forcing tools, the magic is in the wordlist. I know that this password started with a weak common password, and then I did a few character replacements, and then out of laziness I added either the season and year and a special symbol at the end. My pal Mentalist lets me build out a wordlist to get started with.
A quick look at the help text for Hyrda shows the arguments that are needed to start the attack. I re-learn how to use this tool each time I use it because I just do not use it very often. It is not important to know each argument by memory. It is important to remember how to look up the details when I need them. If the help text for the program does not answer my question, man pages and Google are always around to help. For an SSH attack I only need to specify the username (-l), a password list (-P) and the service://IpAddress like so:
$ hydra -l brucekent -P ./blogtemp/SecLists_Top200_Mutated.txt ssh://192.168.1.28
I enter the command and walk away to go get some coffee. After about 20-30 minutes, Hydra finds the “B@tmanSpring2021$” password for my user brucekent. If I were to do this to a real host on a network the volume of SSH connections, and the repeated failures should have tripped a few different alarms. There are also going to be about 3000 failed authentication logs on the box as well. But hey, I got my password back, and it is my box so no worries!
Detecting and defending against brute force attacks
Defense starts with the ability to see what is going on. Log collection and analytics is a good place to start. Once the logs are being collected, the first order of business is to figure out what normal looks like. Numbers and math are our friend here, counts, averages, and trendlines are what we want.
If your average site traffic on Monday morning 9a-10a is 2,000 requests per minute, and you see 5,000 requests per minute at 9:15 AM, it is time to round up the team and get to work sorting things out. It might be a new marketing campaign struck gold, but it might be something not-so-nice.
Log analytics platforms like Elastic and Splunk let us dig into data and start asking questions. Which URL is getting the most requests? What is the pass/fail rate for login requests? Did an attack succeed? Is it one server, or all of them? Where are the requests coming from? The answers to these questions are in the logs.
After visibility is established, weaknesses in the defenses can be addressed with code changes, patches, or new tools and appliances. Intrusion detection systems, advanced firewalls, and network monitoring can increase detection and response times. Use the logs and table-top exercises to identify gaps in the defenses, then target those gaps with the appropriate solutions. Integrate those solutions, so that the data that they generate can be used in the next gap analysis, and then keep iterating.
Earlier I talked about cracking password hashes from the /etc/shadow file. Auditing logs on the machine can reveal if anyone tries to access the /etc/shadow file. Using the audit logging, I can send notifications if anyone tries to read the shadow file – whether they are authorized to do so or not. Understanding what normal access patterns look like, is the key to finding abnormal activity.
Complex password policies, host hardening and locking down remote access to sensitive services like SSH, or RDP are all good defenses when layered together. Breaches usually start with valid credentials. Whether those credentials are phished, stuffed, sprayed, or cracked, an attacker is after valid credentials more than anything else. The most complex password of 30 characters of random gibberish is useless if an attacker can trick a user into giving up their password in an online survey that is really a phishing email. Once an attacker has valid credentials, they are going to try to escalate privileges and start looking around for other things that they can do.
Modern attack tools and framework allow scripted or automated attacks to be conducted. If attackers are using automated tools, it seems that defenders should be doing the same thing. Automate data collection, analytics, and response whenever possible.
As the defense matures, take advantage of red and purple team tactics. Understand what the tools look like by conducting test scenarios and table-top exercises. Get permission first, this is not one of those situations where it better to ask forgiveness than permission. Internal red teams should be working with the blue teams, each pushing each other to evolve. This journey of mine started because I wanted to know what comes up in the logs when Mimikatz was run on a server. I could not find an example data set, so I decided to learn how to do it myself.
This was a fun topic. I hope that you enjoyed, and maybe learned something new too. Up next will be SQL injection, specifically blind SQL injection. SQL injection is probable one of the oldest web application attacks out there. There are lots of neat tricks to explore. I wonder if I can make a blind timing-based SQL injection funny and interesting. Check back in a few weeks and find out!
***
This blog was written by Greg Porterfield, Senior Security Consultant at Set Solutions.