Thursday, February 7, 2019

CloudShark Holiday PCAP Challenge: Grinchident 2018

This was a challenge I participated in around Christmas time. Below is a copy and paste of the write-up I supplied Cloudshark.

Today, myself and other participants along with the folks from Cloudshark did a webinar to discuss what there is to gain from doing challenges like this and how to build them.

If you would like to try the challenge use this link: https://enterprise.cloudshark.org/blog/holiday-capture-challenge-2018/

BELOW CONTAINS SPOILERS, ALOT OF THEM!!!!

After completing the Cloudshark Halloween challenge, which was a lot of fun (I blogged about it here: https://sealingtech.org/2018/11/14/trick-or-treat-halloween-pcap-challenge-from-cloudshark/ ), sparked my thirst for PCAP challenges, I started the Holiday PCAP challenge: https://enterprise.cloudshark.org/blog/holiday-capture-challenge-2018/ . I really loved how this one had a PCAP inside of a PCAP inside of a PCAP style. I worked through this one pretty quick but I did reach a hard stop. I’m stuck and can’t go any further. Below are my findings.


The challenge starts with 2 PCAP’s: (more will be found—We have 5 so far)
  • grinch_activity.pcapng
  • holiday_chunk_0.pcapng
Before I start any PCAP challenge or begin to look at any PCAP I always perform these few steps:
  • StatisticsàProtocol Hierarchy
  • StatisticsàConversations



This will give us a breakdown of the protocols and conversations we’re seeing before we even dive in to any of the packets. This allows us to treat the PCAP like an onion and slowly peeling off one layer at a time.

Going back to the packet list… as, soon as you open the “grinch_activity.pcapng” file you’re immediately presented with some UDP traffic and an obvious email.

The UDP traffic looks eerily similar to the RTP Stream that was embedded in the Halloween PCAP Challenge. Because the UDP Data made up about 18% of the overall traffic with in the PCAP I thought it would be a good idea to peel off that traffic and get it out of the way.


3 Songs


Using the same procedure for all, I was able to extract 3 songs:
I identified these conversations from the Conversations Statistics window from above.

Step 1:

Right click the first packet in the Packet List and navigate to “Decode As…”. Under the “Current” table heading double click to activate the drop down menu and choose “RTP”.

This instructs Wireshark to use its RTP protocol analyzer against this traffic.


Step 2:

Navigate to: TelephonyàRTPàRTP Streams


Step 3:

In the RTP Streams window click “Analyze”.


Step 4:

In the RTP Stream Anaylsis window click “Play Streams”.


Step 5:

Enjoy!

Export Objects

One of the next things I do almost every time is export all the objects Wireshark can identify.

Navigate to: FileàExport Objectsà HTTP

This will dump only a few files, but very important files.


I quickly grabbed the *.torrent file and threw it in a torrent program. This yielded another PCAP file: “btc.pcapng”.

Now, we have a total of 3 PCAP’s to work with.

I lightly investigated the “mad-holiday-antler.jpg” image but it hasn’t yet yielded me a flag.

Merge PCAPs

Since we now have 3 PCAPs to work with I took the strategy of removing the 3 song streams from the PCAP and merging all 3 into 1 PCAP file.

Export Objects: Part 2

Cloudshark also gave us the Pre-Master-Secret key file to be used with these PCAPs. I applied that file to the PCAP and did the export object procedure again, this time yielding many more objects.


There are some interesting finds to come out of this export:
  • Visits to Cloudshark’s website to specific blog posts(the may give clues to solving some of the challenges 😉)
    • Bittorrent 
    • Memcached 
    • VPN leaks 
  • IMDB for The Grinch Who Stole Christmas 
  • A few visits to Anti-Christmas websites 
  • Bing 
  • CyberChef on Github

Some of these items are clues to solving the Mystery…

Emails

 

Before doing any other deeper investigation lets finish looking at all of the clear text protocol: SMTP

You can navigate to: FileàExport ObjectsàIMF

This will export the *.eml files cleanly and then open them with notepad or notepad++.

Or because the protocols are plain text you can read them in line in the Packet Details in Wireshark.

DNS

Looking back at our protocol statistic we have many obvious DNS requests to lets take a look.

I often like to give special attention to DNS because it’s clear text and you can tell a lot about a network by observing DNS. Also, for the sake of PCAP challenges you can hide a lot in DNS if you wanted.

Out of all the packets there were only a few DNS requests and responses. They didn’t yield any flags but I feel it’s important to document the findings.

IRC (or GRC: Grinch Relay Chat)

Identified in the Protocol Hierarchy(our first step), we can see a small amount of IRC traffic.

IRC traffic typically uses TCP over port 6667 by default. We can identify this traffic using the filter: “irc

In the packet details pane I expand the protocol and right click on “Trailer” and choose “Apply as column”. This allows me to quickly see the text conversation.


It’s a small Christmas poem with the cadence of Dr. Suess How the Grinch Stole Christmas or ‘Twas the Night Before Christmas.

In this poem are a few clues:
  • “in an old protocol where short messages are cached.”
  • “peer-obsessed”, “seeds”, “abhorrent”(rhymes with torrent)
  • “VPN is configured”
  • “sound!”

Memcached (my favorite part)


(Feb 7, 2019 UPDATE: Sake from the Webinar showed a much cleaner and wuicker way to solve this all within Wireshark)

This is chaining together many items and was my favorite to find so far.

To quickly identify the Memcache protocol use the filter: “memcache

This will yield 2 packets. There are many many packets that make up this entire converstation but all your attention can be brought to one packet.

A single session that once reassembled equals 336848 bytes.

I expanded these details and right-clicked the “Value” and chose “Copy as Printable Text”.

I pasted it into a notepad and couldn’t figure out what to do with it.

I saw it had a trailing “==” sign which often indicated Base64 but I couldn’t figure out what I was supposed to do with it.

Keeping this in the back of my head as I browsed around trying to identify different parts of this story I remember seeing CyberChef, and also it seemed like this PCAP was leaving clues within itself. So, I followed the link to CyberChef (https://gchq.github.io/CyberChef).

NOTE: I recently used CyberChef in another CTF and was familiar with it’s capabilities.

I browsed to CyberChef and pasted in what I thought was Base64 and started to build a recipe. I added the “From Base64” ingredient and viola! I had something.



Right there in the first few lines of the Output I saw “mergecap” and also a string of repeating “HAPPYHOLIDAYS”. I knew mergecap was used to merge multiple PCAPs or also split them. So, I figured this must be another PCAP. I clicked the save icon and saved the file as a PCAP and opened it… it worked!!! I had my fourth PCAP!!!.

I merged this PCAP into my larger PCAP I was already working because it looked like it had part of an existing conversation.

UDP

Upon merging the newly found PCAP, from above, I now had 2 strange UDP packets at the top of my Packet List.


Changing the packet view to ASCII yielded the “HAPPYHOLIDAYS” phrase I saw earlier… but something wasn’t quite right. 


I copied the 2 phrases out of Wireshark and into Notepad for a closer look.



Looking through this we can extract something but what is it? If you subtract all the UpperCase letters and leave only the lowercase something emerges. (I feel like I’m using the decoder ring from ‘A Christmas Story’)
I don’t have the full URI so this makes me think this is incomplete. I’m hoping this points me to another PCAP to grab but at this time it is un-confirmed.

Ascii Art

I also found some ascii art which is similar to what was hidden in the Halloween PCAP Challenge, but with a Grinch/Christmas theme.


User Agent Strings

  • GrinchBrowse/1.0 
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:64.0) Gecko/20100101 Firefox/64.0 
  • curl/7.55.0

IP Address in HTTP Header?

I found an IP address in an HTTP header that I’m wondering is this something I should hunt or not. I did some preliminary investigation, and have it pinned to Comcast ISP in the North East. I’m betting this is something that didn’t get scrubbed when using trace wrangler to sanitize the PCAP. I assume this is a real IP address used by Cloudshark offices or one of their employees.



OpenVPN

This I have yet to solve.

NordVPN, seems fitting as "Nord" is French for North, as in the NorthPole, maybe it’s a stretch.

NordVPN CA20

us349.nordvpn.com

I changed the HMAC bytes length to 64 and the packets started lining up properly. You can use the filter “openvpn”, you’ll notice all the “[Malformed Packet]” message removed and expand the header find the “Packet-ID” value and scroll down through the packets you should see them all increment: 1, 1, 2, 2, 3, 3, 4, 4…..


FROM THIS...

...TO THIS

ROT13

Hints were being dropped throughout the PCAP. I found someone browsing to the wiki article for ROT13, which is a type of encoding.

I haven’t yet found a string that I can use this on so I’m still looking.

CyberChef supports ROT13 so I’m poised and ready.

The 5th PCAP: 

https://fs-hpcc.qaggle.net

A co-worker (Scott) pointed me to this site which I had previously seen and dismissed. He shared the screenshot which made me perk up:



I immediately did a view source and discovered a hidden message:
I completely ignored the username/password credential entry because of the source looks like no-matter what you enter it will always return: “Password incorrect. Please try again.”

Now, I have the 5th PCAP:

It, like the other PCAPs, has a UDP packet as the first packet, then my quick glance shows only one other conversation.

The single UDP packet had the same messaging as the other I’ve found adding to my collection: (The middle section)


I’m hoping that this leads me to another PCAP but I can’t seem to get there. I’m missing something.