Over the weekend, I, along with @TheMightShiv, had the opportunity to form up a team (Team Rage Quit) and compete in the Hack3rcon CTF.  It was a great time, provided some well thought out challenges and was a lot of fun to do.

The CTF was created and managed by @The_XRG crew. These guys definitely need a shout out:

• Debug – @johndegruyter
• Trey – @treyperrone
• Steve – @kill9core
• Ray – @zer01ne

The CTF consisted of 12 different challenges of various skill levels.  Four of the 12 challenges were released Friday evening, and the other eight were released the next day.

The first challenge consisted of a pcap file.   It required us to analyze the pcap file of a nmap scan.  We had to determine which ports were open and responding.  We opened the pcap file using tshark with the -r flag which dumped the file to standard out.  We then grepped for  SYN ACK responses.  This returned out the ports that were open, however it returned it in a format that resolved the service names to the ports rather than just the port numbers.  When we used the -n flag in tshark in conjunction with the rest of the scan, we received all port numbers and could use that to submit the flag.  We then used cut to pull out the port numbers and piped the output into tr and used it to replace the whitespace with colons.

The second challenge was a phone number that we needed to get.  We were provided with a md5 hash, told that the phone number followed the format of 304-XXX-XXXX, and told that we needed to find the flag.  This was done with hashcat.  We created a custom mask of -1 3 -2 0 -3 4 -4 – and then used a mask based attack with the following mask ?1?2?3?4?d?d?d?4?d?d?d?d.  Hashcat was quickly able to produce the correct phone number.  However, when submitting the phone number multiple different ways, we weren’t getting the flag.  Finally, we decided to call the phone number, and were greeted with a message congratulating us with finding the phone number and giving us the actual flag.

The third challenge was an .apk file.  We immediately downloaded the tool dex2jar.  This tool allowed us to decompile the .apk into a .jar file.  Once we had the .jar file, we used JD-GUI to view the source code of the .jar file.  Within the source code was the third flag.

The fourth challenge contained the flag under multiple separate smaller challenges and started off with a pcap file.  We determined that it was traffic from a wireless network encrypted with WEP.  Aircrack-ng was able to obtain the WEP key, and we then used airdecap with the wep key to obtain the cleartext packet capture file.  Once we started looking at the unencrypted pcap, we see multiple types of traffic on it, a significant amount of ARP traffic, some FTP traffic, and some e-mail traffic.  The FTP traffic was a file transfer of a zip file called “flag4.zip”.  We used the tool tcpxtract to extract the zip file out of the packet capture.  When attempting to open the zip file, we saw that it was password protected and nothing we currently had worked.  We started reviewing the pcap again and saw an e-mail that contained the phrase “This should work” and then an encoded string.  We identified the string as being base64 encoded, and then decoded it.  The decoded string contained the password to the zip file, which we then unzipped and obtained the flag file for the fourth challenge.

According to the website where we received our challenges, challenge 5 & 6 were exploitable via the same exploit.  The challenge was a web application that looked like a blog allowing comments.  We setup BURP to act as our proxy while analyzing the web application’s source code.  We noticed when requesting the web page, that there was an additional request made that included multiple css files stored on the web server.  We tried adding the index.php file to the list of files that are being requested by the web application, and the server responded with the source code of the index.php web page.  Within the source was the database connection information, along with the fifth flag.  Since we identified the fifth flag through LFI, we assumed the sixth flag was found via LFI.  We noticed that there is an admin login interface for the blog.  When we included the page (admin/index.php) to the list of files being requested, the source of the admin login page was returned and that included the 6th flag.

The 7th challenge was a machine that was only listening on ports 139 and 445.  There were absolutely no other services running on the box and everything appeared to be patched. This machine was not able to be compromised until we compromised the machine used for challenge 8 and 9.  This challenge will be addressed after challenge 8 and 9.

Challenge 8 and 9 were running on the same machine.  Challenge 8 was to crack joedirt’s password.  Since 8 and 9 were on the same machine, we assumed we had to compromise the machine, obtain the hashes, and then crack the hash.  Challenge 9 told us to find the flag on the machine.  When we port scanned the machine, we saw multiple ports running the same 1.65 version of WARFtp.  We were able to use the metasploit warftp 1.65 username overflow exploit to exploit the service and receive a meterpreter callback.  Once we elevated to system level privileges, we ran the hashdump module and obtained the hashes.  We used the online cracking website Objectif Securite to crack the LM hash and submit it for the challenge 8 flag.  We then searched the users box using meterpreter’s built in file searching functionality and found the the 9th flag.

With the hashes obtained from the machine, we performed a pass the hash attack against the box used for the 7th challenge.  We used the Administrator account, and its hash, from the challenge 8 box, and were successfully able to authenticate to the challenge 7 box.  It was intended to work this way.  However, our team were able to get into the box another method.  We loaded incognito on the box from challenge 8 & 9, and stole the token for the Administrator’s account.  While impersonating the Administrator, we mounted the c$ share of the challenge 7 box and then found the flag that way.

Challenge 10 said we needed to find a flag that was on the same web application used in challenge 5 & 6.  We went back and looked at the web application, and searched more for SQL injection oriented attacks.  We started looking at how comments were being displayed on the blog, and discovered the comments for a specific page were being displayed based off of an ID variable set in a GET request.  We used SQLMap to test for injection against the ID variable and found that it was vulnerable to the injection attack.  We dumped the database and discovered a flag table and found the flag within the table.

Challenge 11 pointed us to a web application hosted on a different website.  This appeared to be a wordpress blog.  Glancing over the blog didn’t reveal any major holes in the application.  We ran Nikto to test for any quick vulnerabilities, and it discovered the “test” directory available on the web site.  When we browsed to the directory with a web browser, it contained the flag.

Challenge 12 was a WEP encrypted network.  The challenge was to submit the WEP password as the key.  We used airodump, aireplay, and aircrack to run an attack against the wireless network and obtained the key.

After working our way through all of the flags, we were lucky enough to come in first place and received two Hak5 Wifi Pineapples as prizes from the 304Geeks who put on Hack3rcon.  Overall, it was a great con where we were able to interact with speakers quite easily, make new friends, and compete in the CTF.  We’ll definitely be headed back again next year and I’d like to recommend everyone should do the same.