This is a continuation of my write-up about this year’s Crack Me If You Can challenges. You can view my previous two write-ups using the following links. Each one covered a specific challenge of the CMIYC contest: [Striphash] and [Radmin3 hashes].
I’ll admit, in my previous posts I was focusing on the plumbing of the challenges. Aka how to extract the hashes and get them in a format that you can run password cracking attacks against. But I danced around how to run successful cracking sessions against those hashes. There’s a lot of reasons for that, but the biggest one is that I wasn’t very successful during the contest itself. I needed time to step back, and start investigating all the challenges and hints that Korelogic gave out during the contest but I didn’t have time to really dig into. Then with sleep and no pressing deadlines I could start to solve, understand, and then incorporate these challenges into my cracking session. That’s a lot of words to say that I didn’t solve the wifi cracking challenge during the contest, but I felt it would be worthwhile to look into it afterwards and document how I went about working through it. This will hopefully be one of the more day-to-day practical write-ups as well since cracking wifi passwords is something that can be pretty common during pen-test engagements if you can line up the appropriate permissions.
As a bit of backstory for myself, I got my start in computer security being a wireless penetration tester/red-teamer. I had perfect timing since new tools to crack WEP sessions had just been released and a Symantec Antivirus remote exploit had become available. So by pressing a few buttons I could look like a super L33t hacker without really knowing anything.
Ever since then, I’ve had a soft spot in my heart for wireless hacking. The challenge though is I rarely do any wireless hacking in my day job. Yes, I do vulnerability impact analysis research, but I usually start with a white card that assumes I already have access to the wireless network. How do I justify that? Well let me refer you to my talk at BSidesLV2023: Passwords911 Authentication Adventures in Healthcare. To be more specific, I end up buying a lot of used medical equipment off of eBay (my job is so weird but awesome). Often these medical devices still have hospital credentials such as wireless passwords, and Active Directory tokens, as well as patient records still on them.
Don’t just take my word for it. The security company Rapid7 did a similar analysis and found over half of all wireless infusion pumps that they purchased on the secondary market had sensitive data still on them [Link]. As a disclaimer, I haven’t seen any reporting of threat actors doing this in the wild. This particular attack requires a lot of luck and physical proximity to the institution that sold the medical equipment. Basically it would be a huge pain to try and pull off in real life. But it does work pretty well when I’m requesting a white-card so that way I can focus on the part of the assessment that I really want to dig into.
Now that the “cooking recipe back-story” of this post out of the way, let’s look at the challenge itself. In the first hint file released after the contest started “cmiyc-2024_street_files_2” it included a “street.pcap” file along with the following note:
—–
From: Jarlaxle
To: Tiamat
Subject: We located the journalist
We found the journalist and sent a drone to do some recon at his house. We cracked his home wifi and have been monitoring all of Julian’s communications. We’ll soon learn which staff he’s been communicating with and whose accounts he’s been using. We’ll put a stop to his investigation.
Jarlaxle
—–
Figuring out accounts sounds promising when it comes to cracking the challenge passwords. So let’s open up the pcap in Wireshark.
Ok, so this pcap looks like something we can use to crack the WPA1 pre-shared key. The next question is, how do we get the WPA1 hash?
One option is to use the excellent and easy to use cap2pcap site run by Hashcat https://news.google.com/rss/articles/CBMifEFVX3lxTE9jUE5ZVnVQYVJGdUQ2NlZ1dEpwR28tUFVZRURXYklPQkw5azhodGRuN191cEozalNuSU5fcUFzTDNYYjYybzEyQTBONktBVWJoeEJWVmZZS2pnLUhXc0hOeUJMM0tJSEhJdG5Kb1h5NTJELVNIZG05Y2xqa0fSAYIBQVVfeXFMUHpTeTF6VFFONlRiX2lRcWxvUjExZ3JQS01MNmFibzlleEpPNmY5dzJScHBhYnRpdmJOcm1DVkVSbU5hTzY5U0hnNGNQVHdnN2xCZ184TU84WUYxZm1tNjZqOFRwSFFyakoxbTV5alVHYlctSkhFby1oak4xQlA3M3N6Zw?oc=5. You just need to upload the packet capture and a couple of seconds later it returns to you a download of the hash to crack. For a contest like this, it is super easy and absolutely the way to go so you can focus your time and effort on other tasks.
The problem is you can get in big trouble if you use this site for real world penetration testing engagements. You are uploading sponsor data to a cloud based hacking site probably being monitored by who knows what threat actors. I’m not throwing shade at the Hashcat team for offering this service. It’s a great service and I really appreciate they provide it. But you don’t want to be uploading client data to other reputable cyber security sites such as Virus Totals either. Basically if you are getting paid to do this type of analysis, you are also getting paid to learn to dump the hashes from a packet capture file using your own systems.
“Quick” HcxTools Install Guide for WSL2:
- Install prerequisite libraries
- sudo apt-get install pkg-config libpcap-dev libcurl4-openssl-dev
- Remove the old version of libssl-dev if you have it already
- sudo apt remove libssl-dev
- Manually install libssl-dev to be a more modern version (the Ubuntu WSL version is way out of date and the toolset requires a version of libssl > 3.0)
- Note: I’m using the instructions from the following webpage: [Link]
- cd /usr/local/src/
- wget https://www.openssl.org/source/openssl-3.0.8.tar.gz
- tar xzvf openssl-3.0.8.tar.gz
- cd openssl-3.0.8
- ./config shared zlib
- make
- make test (only do this if you have 2 hours to let it run instead of just YOLOing it and doing the next step)
- sudo make install
- Modify your system PKG_CONFIG_PATH and LD_LIBRARY_PATH to include the link to your new libsssl-dev
- export PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig
- export LD_LIBRARY_PATH=/usr/local/lib64
- Get the newest version of HexTools
- cd [MAIN INSTALL DIR]
- git clone https://github.com/ZerBea/hcxtools.git
- Go into the hcxtools directory
- Build and install hcxtools
- make -j $(nproc)
- sudo make install
Ignoring all the Googling and troubleshooting, the process to get HcxTools installed and working was a breezy two hours or so. I don’t know why people don’t do this instead of using Hashcat’s easy to use online service…
I will say, these write-ups are mostly for myself. I guarantee sometime in the future I’ll need to install HcxTools, so it is nice to have someplace I can refer back to vs. having to do all that Googling and troubleshooting again. So now that we have HcxTools installed, let’s use it to extract the WPA hash from the packet capture.
Using HcxTools to Manually Dump the WPA1 Hash:
Once you have HcxTools installed and working, it’s a pretty straightforward process to dump the password hash. Before that though, I should take a moment and highlight that HcxTools is a very powerful toolsuite and has a number of advanced options to deal with large packet captures containing hundreds of wireless networks. You know those people walking around the Defcon security conference with a “wifi cactus”? Or in a more general case, old school wardrivers sniffing traffic from all over a city. Well they are probably making use of HcxTools advanced features to sort through the outputs and create custom hash lists. For this contest though, the pcap is small and there’s only one network, so we can use the basic options:
- hcxpcaptool -o [FILE TO SAVE THE HASH] [HASHFILE]
- e.g.: hcxpcapngtool -o ./challenge_files/CMIYC2024_Street/hashes/pcap.hash ./challenge_files/CMIYC2024_Street/hashes/cmiyc-2024_street_files_2/street.pcap
I’d include a screenshot of this, but it looks almost exactly like the online service that Hashcat provides in the picture included above.
Using John the Ripper’s wpapcap2john to Manually Dump the WPA1 Hash:
If you are going to use John the Ripper to crack the WPA1 hash, there is an easier option available to you. Included in the Jumbo version of JtR is a tool called wpapcap2john that is super easy to use and will save the resulting hash in a format that John the Ripper can use.
Example:
- /mnt/c/github/JohnTheRipper/run/wpapcap2john ./hashes/cmiyc-2024_street_files_2/street.pcap
Question: Is there a way to convert hashes back and froth from Hashcat formats to JtR formats?
- Reason: The formats that JtR and Hashcat use to crack WPA1-PSK hashes are very different. Therefore I need to use HcxTools for Hashcat and wpapcap2john for JtR. I suspect there is some flag in HcxTools that will do the conversion but I don’t know what it is. It’s not a big deal, but it would be a nice quality of life improvement for when I need to crack more complex Wifi passwords.
The WPA1-PSK hash file formats for both John the Ripper and Hashcat are different but once you have the hashes you can pick which tool you want to crack them with. I personally like using John the Ripper since I don’t have a lot of GPU power to throw at the problem and I like JtR’s rule logic better. But Hashcat is much preferable if you do have the compute power to really throw at the problem. I’m going to show examples of using both tools, since luckily the street password that Korelogic provided for this file was fairly simple to crack.
Cracking with John the Ripper:
The hash format for John the ripper is “wpapsk” so I used the following command to run my initial attack in Batch mode.
- john –format=wpapsk ./hashes/pcap2.hash
Cracking with Hashcat:
The first step with cracking the WPA1-PSK hash in hashcat is figuring out what format to target. There’s a lot of different wifi cracking modes! Now if you are lazy you can simply skip the ‘-m‘ option and let Hashcat autodetect the password hash which works pretty well for well defined hash types. The other option is you can refer to the list of Hashcat hash mode examples. The hash dumped from HcxTools starts with “WPA*02*” and when looking through the example hashes that matches up to “-m 22000“
Now it’s just up to us to run a cracking session. To keep things simple, I used the standard JtR passwords.lst wordlist since that’s a pretty good small one, and I picked the d3ad0ne.rule included in Hashcat as that tends to be my default go-to ruleset to use. In retrospect I should have kept it smaller with something like best64.rule (you can tell the reason when you look at my anemic password cracking setting in the screenshot below), but it was a very weak password so it didn’t make much of a difference this time.
Example Hashcat Command:
- hashcat -m 22000 -a 0 ./hashes/pcap.hash ~/repos/john/run/password.lst -r ~/tools/hashcat/rules/d3ad0ne.rule
The easiest way to decrypt the encrypted session in the packet capture is to use Wireshark. I included a link to the official tutorial on how to do that at the top of this blog entry since I always have to look it up every time I do this. But here is a quick list of the steps:
- Open the packet capture in Wireshark
- In Wireshark go to Edit->Preferences
- Next go to Protocols and expand it out. Select “IEEE 802.11”. Note: I always forget it starts with IEEE.
- Next to “Decryption Keys” click “Edit”
- Press the “+” button to add a new key and pick “WPA-pwd”. Then enter in the PASSWORD:SSID and click “save”
- Trust me on taking the time to enter in the PASSWORD:SSID vs. just the password. It’ll usually work with just the password, but I’ve wasted time troubleshooting when problems popped up due to me being lazy and just YOLOing in the password by itself.
Quick Disclaimer: I don’t know if Wireshark is smart enough to realize the last “:” is the delimitator or not so it might not actually mess up your decryption if a “:” is in the password. Setting up a wifi network and testing that out will need to be a rabbit hole for a different day.
Once you do this, Wireshark will automatically decrypt the traffic making it really easy to start digging into it and looking for fun conversations and artifacts.
I’m sure there is some toolset or script out there that will parse through this decrypted traffic and pull out interesting passwords and information from it. My first instinct would be to go with DSniff, but looking at the repo it hasn’t been updated in the last 14 years. (Side note: This also gave me the realization “OMG I’m old”).
Question: What tools do you recommend to parse through packet captures and extract passwords and keys?
- Reason: This manual process works for grabbing a couple of passwords from the packet capture but it really doesn’t scale and I could easily be missing things.
Since I was curious and didn’t want to spend six hours digging into another side-quest of investigating packet capture analysis tools, I’ll admit for this first pass I just started scrolling through the decrypted traffic to see if there was anything interesting. And the TLDR was, yes, there was a lot of interesting traffic.
FTP Credential Analysis: I need to dig into this more, but at least in the initial street file hashes, there does not appear to be a user with the name “yashica”. I might need to throw their password, (along with others extracted from this packet capture) into a general wordlist and run it against all the uncracked hashes I have. That is, unless there is another hint file that provides further context. So the next question, is “what about that passwords-street” file they are downloading?
Yup, that could be useful as well! Now, I want to preface this next point by once again saying that there must be a better way to analyze these packet captures, and doing it by hand is tedious and error prone. But if you are going to parse it hand like I am doing, you can look at the filter that gets applied in Wireshark when you follow a TCP stream and manually increment it by one to view the next TCP session. It’s not a pretty way to do things, but it’s much better than hunting and pecking and scrolling through the full packet capture.
Other interesting side quests: There is one session where the user grabs the following webpage: “/obscure/path/for/extra/security/passwords-street.html”,
I know I started this post by saying that I needed to get away from all the plumbing of extracting/formatting hashes and start actually cracking the challenge passwords. Unfortunately, it looks like I totally failed in that task again. Now that we have some hint files and sample passwords though, making use of this data will hopefully be the subject of a follow up blog post. For now though I really enjoyed writing this blog post and getting back into practicing my wifi hacking skills. So thanks again to Korelogic for including this challenge in this year’s contest.
*** This is a Security Bloggers Network syndicated blog from Reusable Security authored by Matt Weir. Read the original post at: https://reusablesec.blogspot.com/2024/08/cmiyc2024-wifi-cracking-challenge.html
