During Halloween, a company called Cloudshark released a Packet Capture challenge that involved finding hidden “pumpkins” that were hidden in packets. Two SealingTech employees, Tony Efantis and Scott Lohin, participated in the challenge and found all five pumpkins. This challenge was a lot of fun, and we thank Cloudshark for creating it for the public. Below is a writeup of the solutions.
I (Tony) originally saw the post on Cloudsharks’s twitter account @cloudshark:
2 weeks prior I (Tony) participated in OpenSOC.io Blue Team CTF which had a PCAP element to it and the fire for my love of PCAP CTF’s was re-lit.
To start the challenge, you could use Cloudshark’s tool online, which is basically a browser based wireshark with additional analysis features. You could also download the PCAP to analyze it with other tools. Both approaches were used to solve this.
Once I had the PCAP stored locally, I opened it with Wireshark and began to dive in.
Pumpkin #1: Low Hanging Gourd
Tony: Starting at the top with Frame #1 I started scrolling down just trying to get a high-level understanding of what I was looking at. I saw your basic HTTP, DNS, SSL packets and sessions. Then starting with frame #44 I started to see a quick pattern of single packet HTTP sessions consecutively. This certainly seemed out of the ordinary, so I looked at each HTTP packet and noticed the `Host` portion seemed strange.
I knew once you took these host values and stacked them on top of each other they would make some sort of image. In Wireshark I right click the “Host” value in the details pane and choose “Add as Column”.
Now, if we build a filter for “HTTP” and only packets with the destination IP “18.104.22.168” you get:
Pumpkin #2: A Picture’s Worth a Thousand Words
Tony: While scrolling through the packet I saw a fair amount of images and files passed via HTTP. The un-elegant way to do this was clear your filter and navigate to: File à Export Objects à HTTP…
I normally choose “Save All” and sort through them using my native operating system file explorer. I combed through the save objects and found one of the images to contain a pumpkin:
Pumpkin #3: Pumpkin == The Devils Food
This is where having an offline copy gave me a different perspective. I fed the PCAP into NetworkMiner (https://www.netresec.com/?page=NetworkMiner) just to see what it finds throughout the PCAP. It automatically does things like breaking out DNS, sessions, files, images, and more. You can search for keywords using ascii strings or hex values.
I tried searching for most variations of the word ‘pumpkin’ in both ascii and hex but didn’t turn up anything.
Instead I used the “Hosts” tab to help understand all the conversations in the PCAP and this led me to pumpkin #3.
I started at the top and made it to the 3rd host where I saw tcp port “666”, with a short session (Very few packets), no DNS query, and a payload that seemed unusual. I didn’t really know what I was looking at, so I went back to Wireshark and pulled up that host.
In Wireshark I used `ip.addr == 22.214.171.124` and this brought me the whole conversation. It was a short conversation with only a single packet TCP segment. The payload of `frame.number == 5057` will bring you the answer. Right click the ascii payload and choose: `Copyà…as Printable Text`. Paste this into a notepad and dress it up a little and you get:
Pumpkin #4: We Don’t Need the Keys We’ll Break In
Tony: This was my favorite challenge of all.
Using NetworkMiner I found an email. This file could be found using the Export ObjectsàHTTP method or using NetworkMiner.
This message by itself didn’t mean much to me. So, I went to Wireshark and searched for `SMTP`. This showed the entire conversation.
Having recently (within 2 weeks) tested a communications channel to an SMTP server via telnet, I became very familiar with analyzing this. In the screenshot below starting from frame 2385 and thumbing down through each packet you can see the entire session unfold. You can see the email from:
The subject and body of which can be found in the file previously extracted.
I still wasn’t sure exactly where to go to solve this one. I started digging through the certificates that I exported earlier in the day. I didn’t find any pumpkins but did find a certificate for “themyershouse”
Using the Wireshark filter `ssl` you can see there are only 3 SSL sessions. One of them the server is presenting a certificate with the CommonName=themyershouse. Right click and Follow SSL Stream would single out the entire conversation. You can also use the filter `tcp.stream eq 285`.
At this point it started to come back to me, “What was I supposed to do with that seemingly random string from the email?”. I thought ‘I must have to use this to decrypt the SSL session’ but this wasn’t the correct information. These weren’t private keys it was just 2 strings. Also, you can’t decrypt ECDHE SSL. After pondering for a while, I finally googled: “CLIENT_RANDOM” and came to many resources showing how to decrypt SSL sessions using an environmental variable. That’s when it all clicked. I actually remembered doing this years prior for another PCAP challenge.
I took that string from the email, saved it into a text file on my desktop. Using Wireshark I right clicked on one of the TLS session packets and opened the “Protocol Preferences” and used the “(Pre)-Master Secret-log filename…”
I browsed to where the text file I created was and clicked “OK”.
This now exposed the encrypted packets as plain HTTP packets:
Looking at the payload of these now exposed packets revealed the 4th pumpkin:
Pumpkin #5: The Great Pumpkin
Scott: For the last one we knew that it had something to do with the UDP stream between 126.96.36.199 to 188.8.131.52 over port 1313. That port number was just way too convenient for a Halloween challenge. Looking at data from the UDP stream in ASCII or Hex format didn’t reveal anything of interest.
Earlier in the challenge, I had thanked Tom from Cloudshark for the CTF using their website’s built in chat support. I decided to reach out again and let him know our suspicions on the fifth and at that point he offered up a hint.
Basically, the hint was that I shouldn’t be trying to see the pumpkin and also that I should take advantage of one of the Cloudshark analysis tools.
Okay – I probably have to hear it, but how? At first, I thought that I might have to convert the hex into audio – before I went down that rabbit hole, I noticed that one of their tools did RTP stream playback. I opened this up but received an error because no RTP was identified in the capture. Makes sense – I just have this weird port 1313 traffic.
The other analysis tool that I took advantage of was “Decode As”. This allowed me to take all UDP 1313 traffic and have Cloudshark identify it as RTP.
I went back to the RTP stream playback tool with abated breath. It looked like it could be something…
I hit play and…It’s (audio from) the Great Pumpkin, Charlie Brown!
Later I asked Tom whether I should have noticed within the packet to suspect that it needed to become RTP. He mentioned that the fact that all of the packets were the same length might have been a good indicator.
This was a fun challenge and by going through the paces I’ve already made some improvements in efficiencies in navigating PCAP’s. There was another tool I used but didn’t yield anything additional was http://www.packettotal.com, I uploaded the PCAP there which runs it through BRO and Suricata and got a different perspective of which to present the data. This was fun we learned a lot and will probably hold an internal workshop to solve more challenges like this. Keep’em coming