"It is never too late to be who you might have been."

- George Elliot

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.

Important Links, Tools, and References for this Post:

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

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 [link]. 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:

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:

Question: Is there a way to convert hashes back and froth from Hashcat formats to JtR formats?

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.

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:

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"). 

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",