{"id":18169,"date":"2016-09-01T17:37:34","date_gmt":"2016-09-02T00:37:34","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=18169"},"modified":"2016-09-01T17:57:30","modified_gmt":"2016-09-02T00:57:30","slug":"labyrenth-capture-the-flag-ctf-threat-track-solutions","status":"publish","type":"post","link":"https:\/\/www2.paloaltonetworks.com\/blog\/2016\/09\/labyrenth-capture-the-flag-ctf-threat-track-solutions\/","title":{"rendered":"LabyREnth Capture the Flag (CTF): Threat Track Solutions"},"content":{"rendered":"

Welcome back to our blog series where we reveal the\u00a0solutions\u00a0to LabyREnth, the Unit 42 Capture the Flag (CTF)<\/a>\u00a0challenge. We\u2019ll be revealing the solutions<\/a> to one challenge track per week. Next up, the Threat track.<\/p>\n

Threat 1 Challenge: Welcome to the well of wishes!<\/h3>\n

Challenge Created By: Jeff White <\/em>@noottrak<\/em><\/a><\/p>\n

For this challenge you\u2019re provided a PCAP that has 30 HTTP GET Requests to www.dopefish.com<\/a>. Inside each request is the same URL to the below image and a base64, reversed, string that decodes to \u201cNot everything is as it seems...\u201d.<\/p>\n

\"CTF_Threat_1\"<\/span><\/div><\/a><\/p>\n

Looking at the actual GET requests, the URL structure is interesting as there are a few sections in the URL that remain static between the URLs so we\u2019ll go ahead and extract them all for further analysis.<\/p>\n

\"CTF_Threat_2\"<\/span><\/div><\/a><\/p>\n

Using the below command extracts each URL.<\/p>\n

tcpdump -r dopefish_labyrinth.pcap -A |grep \"GET \/\" |grep -o \"\/.*\" |sort \u2013u<\/p>\n

The general breakdown of the URL is as follows:<\/p>\n

\/M[a-zA-Z]{3}.php?=owVXdTMzc[a-zA-Z0-9]{109}&L4bry1nth_[0-9]{3,5}?NxM[a-zA-Z0-9]{134}-[0-9]{4,5}%26%71%77port%3D27500<\/p>\n

Dropping the URL into an online URL parser shows that the query string being supplied to the file is the entire string after the initial \u201c?\u201d, which seems odd since there appears to be other variables in the URL.<\/p>\n

\"CTF_Threat_3\"<\/span><\/div><\/a><\/p>\n

Further analysis shows that the URL is not correctly formatted as \u201c?\u201d and \u201c=\u201d are reserved characters. When they are placed next to each other, without variables in-between, the rest of the URL becomes invalid.<\/p>\n

Looking at the query string starting with \u201c=\u201d and the above hint with a reverse base64 string beginning with the same symbol, I try to base64 decode the reversed string\u2026which works, but the output is of no use.<\/p>\n

\"CTF_Threat_4\"<\/span><\/div><\/a><\/p>\n

After taking a closer look at the URLs, I noticed there are definite patterns that stand out in the characters, but \u201cNxM\u201d continues to repeat itself roughly every 18 characters. More importantly, the NxM pattern that is seen in the first long string and the long string directly following the \u201c&L4bry1nth_[0-9]{3,5}?\u201d section of the URL. By removing this and putting the two long strings together, reversing it, and base64 decoding it, we get much more usable results.<\/p>\n

\"CTF_Threat_5\"<\/span><\/div><\/a><\/p>\n

\u201c317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317
\nW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317
\nW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317WW317
\nW317WW317WW\u201d<\/p>\n

Continuing to build on our previous line, we wrap it in a for loop and parse out only the two halves, reverse them, and print the result.<\/p>\n

for i in $(tcpdump -r dopefish_labyrinth.pcap -A |grep \"GET \/\" |grep -o \"\/.*\" |sort -u |cut -d\"=\" -f2 |cut -d\"-\" -f1 |sed -e 's\/&L4bry1nth_.*?\/\/g'); do echo \"=$i\" |rev |base64 -D ; done<\/p>\n

\"CTF_Threat_6\"<\/span><\/div><\/a><\/p>\n

There is a very apparent pattern in the output. The last step we take is to add one more command to our line and strip out the \u201c317\u201d, which turns out was the \u201cNxM\u201d from the URL.<\/p>\n

for i in $(tcpdump -r dopefish_labyrinth.pcap -A |grep \"GET \/\" |grep -o \"\/.*\" |sort -u |cut -d\"=\" -f2 |cut -d\"-\" -f1 |sed -e 's\/&L4bry1nth_.*?\/\/g'); do echo \"=$i\" |rev |base64 -D ; done |sed -e 's\/317\/\/g'<\/p>\n

\"CTF_Threat_7\"<\/span><\/div><\/a><\/p>\n

The key is PAN{th3D0p3fshl1v3s}.<\/p>\n

Threat 2 Challenge: The rest of us, we died with our honor.<\/h3>\n

Challenge Created By: <\/em>Micah Yates @m1kachu_<\/a><\/p>\n

The hint is referring to this awesome <\/em>web-comic<\/em><\/a>.<\/em><\/p>\n

To begin the challenge, we are given a file named jareth1.gif<\/p>\n

\"CTF_Threat_8\"<\/span><\/div><\/a><\/p>\n

The thumbnail makes it look like a valid gif, but is it?<\/p>\n

\"jareth1\"<\/span><\/div><\/a><\/p>\n

The file opens and animates fine.<\/p>\n

Opening the gif with a hex editor, the header looks like a regular gif header.<\/p>\n

\"CTF_Threat_10\"<\/span><\/div><\/a><\/p>\n

Scroll to the bottom, and this file is missing the standard gif trailer of 0x3B. (Read more about what\u2019s in a valid gif<\/a>.)<\/p>\n

The hex values at the end are not the standard gif trailer.<\/p>\n

\"CTF_Threat_11\"<\/span><\/div><\/a><\/p>\n

There is data appended to this gif.<\/p>\n

So what do we do with this information? One trick I like to employ with tampered image files is to do a reverse image lookup via Google. I upload the jareth1.gif file to google image search and get this back:<\/p>\n

\"CTF_Threat_12\"<\/span><\/div><\/a><\/p>\n

Clicking through a few of the visually similar images we find this gif<\/a>. It animates the same and has the same dimensions as our jareth1.gif but a different size.<\/p>\n

When diffing the two gifs, we can see that the original gif ended at offset 0x3436D with a valid trailer of 0x3B. Some shellcode and malware authors like to hide data by XOR-ing it with single or multi-byte hex values. Since it appears that the 0xAA bytes are repeating at the end of the file, and some data typically contains nulls, lets XOR the entire file by 0xAA.<\/p>\n

Now let\u2019s look at the leftover data\u2019s header:<\/p>\n

\"CTF_Threat_13\"<\/span><\/div><\/a><\/p>\n

Based off of the header, it appears that the hidden data is a 7zip archive. Let\u2019s save off this XOR\u2019d data to another file.<\/p>\n

One trick I like to use is 7zip\u2019s ability to unzip files when the header is in the incorrect place. Simply use the command line or right click and select 7zip -> Extract here.<\/p>\n

Decompressing that file gives us another file simply named \u201cfile\u201d.<\/p>\n

Taking a quick look at the header we see that this is an html file.<\/p>\n

Renaming it to file.html and opening it with a browser yields this glorious ASCII art of David Bowie:<\/p>\n

\"CTF_Threat_14\"<\/span><\/div><\/a><\/p>\n

So what now? There\u2019s no obfuscated javascript, just a seemingly incomprehensible mess of html. It also looks as if there is a repeating pattern of A7 A0 bookending some other data.<\/p>\n

Let\u2019s drop a section of that hex looking data into a hex editor:<\/p>\n

\"CTF_Threat_15\"<\/span><\/div><\/a><\/p>\n

None of it renders into ASCII, let\u2019s try XORing it with 2 byte 0xA7A0 to see if there\u2019s data underneath:<\/p>\n

\"CTF_Threat_16\"<\/span><\/div><\/a><\/p>\n

Still nothing to work with, but it does look like it could possibly be ASCII text.<\/p>\n

Let\u2019s undo that and try again with the original single byte 0xAA:<\/p>\n

\"CTF_Threat_17\"<\/span><\/div><\/a><\/p>\n

Much better. The text renders as:<\/p>\n

Write a YARA rule to find normal valid GIF files.<\/p>\n

Using the template below:<\/p>\n

    \n
  1. replace each \"**\" pair in $header with the appropriate 6 bytes.<\/li>\n
  2. replace each \"*\" in $trailer with the appropriate regex.<\/li>\n
  3. replace the \"*\" in condition with the appropriate digit.<\/li>\n<\/ol>\n
    rule valid_gif : valid_gif\r\n{\r\n        strings:\r\n\r\n\t\t\t$header = { ** ** ** ** ** ** }\r\n\t\t\t$trailer = *******\r\n\t\t\t\t\r\n        condition:\r\n\t\t\t$header at * and $trailer\r\n}\r\n\r\nUsing the information about proper gif structure we write the following correct rule:\r\n\r\nrule valid_gif : valid_gif\r\n{\r\n        strings:\r\n\r\n\t\t\t$header = { 47 49 46 38 39 61 }\r\n\t\t\t$trailer = \/\\x3B$\/\r\n\t\t\t\t\r\n        condition:\r\n\t\t\t$header at 0 and $trailer\r\n}\r\n<\/pre>\n
    After reading this article about what\u2019s in a gif<\/a>:<\/p>\n
      \n
    1. The header is self-explanatory.<\/li>\n
    2. The regex format is required here to make sure there is no following data after the 3B<\/li>\n
    3. And of course the header has to be at the beginning of the file at position 0<\/li>\n<\/ol>\n
      Submitting the rule above will result in the key: PAN{848Y_wIsh3D_4w4y}<\/p>\n
      Threat 3 Challenge: Matryoshkas got nothing on me.<\/h3>\n
      Challenge Created By: Josh Grunzweig <\/em>@jgrunzweig<\/em><\/a><\/p>\n
      For this challenge, we\u2019re presented with a Python script. When you run the script, the only output you receive is this:<\/p>\n
      python h0ggle.py
      \nYou fell into a pit and died... of dysentery.<\/p>\n
      Looking at the script, it appears to base64 decode the data and decrypt it before passing it to exec() function. The data is rather large, with over one million characters. It\u2019s using AES for the encryption from the Crypto.Cipher suite and stepping through it with a debugger shows that it continues this iteration process where each blob of data executed contains the same code with a new blob of data.<\/p>\n
      \"CTF_Threat_18\"<\/span><\/div><\/a><\/p>\n
      Following this line of logic, we can quickly script out this process. We\u2019ll write each decrypted section to a new file and include the headers necessary to run it again, so on and so forth, until we reach the end.<\/p>\n
      First, we\u2019ll create header.txt with the following data:<\/p>\n
      #!\/usr\/bin\/env python<\/p>\n
      from <\/strong>Crypto.Cipher import <\/strong>AES as <\/strong>tiywynstbg
      \nimport <\/strong>base64 as <\/strong>ufjliotyds
      \nimport <\/strong>itertools as <\/strong>abtwsjxzys
      \nfrom <\/strong>itertools import <\/strong>cycle, izip
      \ndef <\/strong>gasfewfesafds(message, key):
      \nreturn ''<\/strong>.join(chr(ord(c)^ord(k)) for <\/strong>c,k in <\/strong>abtwsjxzys.izip(message, abtwsjxzys.cycle(key)))<\/p>\n
      Next, we\u2019ll put together a one-liner to traverse the dark depths of Python and see where it leads.<\/p>\n
      cp h0ggle.py h0ggle_1.py; for i in $(seq 1 50); do sed -e 's\/exec(\/print(\/g' h0ggle_$i.py > temp; mv temp h0ggle_$i.py; python h0ggle_$i.py > temp; cat header.txt temp > h0ggle_$((i+1)).py; done<\/p>\n
      We run into a syntax error on file h0ggle_28.py, which shows our dysentery error message.<\/p>\n
      File \"h0ggle_28.py\", line 8
      \nYou fell into a pit and died... of dysentery.
      \n^<\/p>\n
      Looking at h0ggle_27.py we can see how to safely cross the river!<\/p>\n
      \"CTF_Threat_19\"<\/span><\/div><\/a><\/p>\n
      Key = PAN{all_dir3ctionz_l3ad_n0wh3r3}<\/p>\n
      Threat 4 Challenge: The same, but different.<\/h3>\n
      Challenge Created By: <\/em>Micah Yates @m1kachu_<\/a><\/p>\n
      The hint is referring to the previous yara challenge, Threat 2 Challenge: The rest of us, we died with our honor.<\/em><\/p>\n
      To begin the challenge, we are given 6 word docs.<\/p>\n
      \"CTF_Threat_20\"<\/span><\/div><\/a><\/p>\n
      Let\u2019s open them all up<\/p>\n
      \"CTF_Threat_21\"<\/span><\/div><\/a><\/p>\n
      The files open and display the somewhat same word doc.<\/p>\n
      Running the file command on all of these files results in:<\/p>\n
      3673c9d7a5b2f978d3a34001d360ac485f22ed6fa868c8304eb99273a6efb268.doc: Microsoft Word 2007+
      \n668bed5ed5d5effb3be659e8dab55c63369985064f7ee80f9365e75b34f6283d.doc: Microsoft Word 2007+
      \n7717bd124dd0c0881afd6b327ff41b420bff77d3c5ae338a31cce5cfdcb3b5d0.doc: data
      \n87f146c41082d7ba885f9433e0223b346f3032f7364bf18675b924a017994779.doc: Microsoft Word 2007+
      \nafc502de73482404cc344301c207f27c7da7b31641cd2192b3bba40f3ab6964e.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.1, Code page: 1252, Author: Micah Yates, Template: Normal.dotm, Last Saved By: Micah Yates, Revision Number: 2, Name of Creating Application: Microsoft Office Word, Create Time\/Date: Wed Jul 13 17:19:00 2016, Last Saved Time\/Date: Wed Jul 13 17:19:00 2016, Number of Pages: 1, Number of Words: 146, Number of Characters: 837, Security: 0
      \nd48a2f4922bca81ce8fff8c18d788f41d2034c7999ca1ed03965d914dc06a9df.doc: Rich Text Format data, version 1, unknown character set<\/p>\n
      They\u2019re not all the same file format, but all contain the same basic content. There\u2019s a .doc, .docx, .rtf, .mhtm, .dot, and .docm file with the same plaintext inside. Simply changing their extensions to .doc allows for Word to try and open them as a standard Word .doc<\/p>\n
      Let\u2019s open up the RTF (d48a2f4922bca81ce8fff8c18d788f41d2034c7999ca1ed03965d914dc06a9df.doc) in a hex editor. They\u2019re typically fairly simple to follow. The header looks fine so lets scroll down to the bottom of the file.<\/p>\n
      \"CTF_Threat_22\"<\/span><\/div><\/a><\/p>\n
      Looks weird right? Let\u2019s take a look at the RTF file format on Wikipedia, specifically the Code Syntax<\/a>:<\/p>\n
      Get all that?<\/p>\n
      So the TL;DR of that section states that RTF data must be within curly braces \u201c{}\u201d. This RTF file clearly has data appended to it.<\/p>\n
      Remember the hint? \u201cThe same, but different.\u201dWell it seems this challenge is similar to the Threat 2 challenge. There is unknown data appended to a legitimate looking file.<\/p>\n
      Let\u2019s attack the data that seems to be repeating. The appended data looks similar to base64 encoding, but somewhat obscured. Within this appended data we have 3 sequences of data that are 48 bytes long that are repeating.<\/p>\n
      \"CTF_Threat_23\"<\/span><\/div><\/a><\/p>\n
      \"CTF_Threat_24\"<\/span><\/div><\/a><\/p>\n
      Two of them are different, and of those, one is clearly not a valid Base64. (See Wikipedia\u2019s definition of Base64<\/a>.)<\/p>\n
      When there are sequences of four repeating characters in Base64 encoded data, the underlying data typically repeats in some sort of pattern. For example: AAAAAAAAA Base64 encoded is QUFBQUFBQUFB<\/p>\n
      Let\u2019s assume these two different sequences are hiding the same data, but have encoded it differently due to data position. If that\u2019s true, it looks like both sequences have also been obscured by a single byte operation. So what do we do to figure out that operation? Brute Force!<\/p>\n
      Let\u2019s write a small script that performs single byte operations on the two sequences and then test it to see if they\u2019re valid Base64 characters. In short, this runs a simple one byte XOR over each byte in the sequence and checks to see if they are ASCII compatible with Base64 characters.<\/p>\n
      import sys, re\r\ndata_sequence = bytearray(open(sys.argv[1], 'rb').read())\r\n\r\ntest_output = \"\"\r\n\r\nkey = range(0,255)\r\nfor i in range(len(key)):\r\n    for j in data_sequence:\r\n        test_output+=(chr(i^j))\r\n    base64_test = test_output\r\n    test_output = \"\"\r\n    if re.match(\"(?:[A-Za-z0-9+\\\/]{8})\", base64_test):\r\n        print hex(i), base64_test\r\n<\/pre>\n
      I truncated the two sequences above into an 8-byte sequence of data:<\/p>\n
      \"CTF_Threat_25\"<\/span><\/div><\/a><\/p>\n
      Running the script over these shortened sequences, it returns 4 XOR candidates:<\/p>\n
      \"CTF_Threat_26\"<\/span><\/div><\/a><\/p>\n
      So we have four potential XOR values that decode valid Base64 characters.<\/p>\n
      Starting with XOR-ing the appended data with 0x26 we get this:<\/p>\n
      \"CTF_Threat_27\"<\/span><\/div><\/a><\/p>\n
      Looks pretty promising, and almost all characters are Base64 standard except there are no \u201c+\u201d characters, only \u201c-\u201c.<\/p>\n
      This looks like it may be using an alternate encoding string with \u201c-\u201c in place of \u201c+\u201d. If we try and decode with this alphabet: \u201cABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-\/\u201d, there is no data that looks promising.<\/p>\n
      Some malicious Base64 encodings use alternate alphabets. Sometimes they\u2019re simple and just change up the position of the alphabet. Let\u2019s write another brute force script to rotate the position of the alphabet above, decode, and test to see if it has valid ASCII text.<\/p>\n
      import string, base64, re\r\n\r\nSTANDARD_ALPHABET = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+\/'\r\nCUSTOM_ALPHABET = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-\/'\r\nROTATED_ALPHABET = CUSTOM_ALPHABET\r\ndef is_ascii(s):\r\n    return all(ord(c) < 128 for c in s)\r\ninput_str = \"vRjD3gu6ysbzqvjbihjP1gu63gW6zgvOzwnOigfG1cbQyxjDyxrD1QTNigXAihrC0xm6zwT91Qr\/zcb-\r\nyxr7l6OkvxnD1A263g7\/ihr\/1xbGyxr\/igj\/1gXRihj\/2gL7yQu6zwf90ca8k8C8ihb70xi63Q\/O0cbO0gu\r\n6zA\/M2Rq6mti6yB\/OzxmUdqCncBjP1gu6zwT9xQrJyMaUigvIyPX-\r\n1QmncBGnc8a6ica6ica62RrM0wTB2NCnc6-jdqCjcq--\r\nzA\/M2Rq6psbVicCEicCEicCEicCEicCEicCEicCEicCEicCEicCEicCEicCEihOnc6-\r\njcsrNzwnJ1Aq6psbVicCEicCEicCEicCEicCEicCEicCEicCEicCEicCEicCEicCEihOnc6-\r\njcsrO0g\/MzcaXihG6k8C6k8C6k8C6k8C6k8C6k8C6k8C6k8C6k8C6k8C6k8C6k8C65qOkcq\r\n-jcqOkica6ica6icb91QT-0xrD1QSUdqCjcq-LigXAihrCzwOncBOa\"\r\n\r\ndef alt_decode(input):\r\n  return base64.b64decode(input.translate(DECODE_TRANS))\r\n\r\nfor rotate in range(len(CUSTOM_ALPHABET)):\r\n    ROTATED_ALPHABET = CUSTOM_ALPHABET[rotate:]+CUSTOM_ALPHABET[:rotate]\r\n    DECODE_TRANS = string.maketrans(ROTATED_ALPHABET, STANDARD_ALPHABET)\r\n    if is_ascii(alt_decode(input_str)):\r\n        print rotate, ROTATED_ALPHABET\r\n        print \"***************\"\r\n        print alt_decode(input_str) \r\n<\/pre>\n
      So what we did in the script was enter our data that had been XOR-ed with 0x26. We defined an alternative Base64 alphabet and then looped through all variations of that alphabet by rotating the entire alphabet by one character per loop. We then checked each output to see if it was valid ASCII, and then printed it. Running the above code returns:<\/p>\n
      \"CTF_Threat_28\"<\/span><\/div><\/a><\/p>\n
      Here\u2019s the encoded data and clue. It appears that the decoding alphabet has been rotated by 26 characters.<\/p>\n
      Would you look at that, three lines of repeating characters, all the same length: \u201c{ ** ** ** ** ** ** ** ** ** ** ** ** }\u201d<\/p>\n
      So to recap, we brute-forced a single byte XOR, then brute forced an alternate base64 alphabet that had been rotated left by 26 characters.<\/p>\n
      Going back through the other documents we find the two variations to this encoded data, and fill out the YARA rule like this:<\/p>\n
      rule enc_doc : enc_doc\r\n{\r\n        strings:\r\n\t\t\r\n\t\t\t$first = { 50 74 4C 62 15 41 53 10 5F 55 44 5C }\r\n\t\t\t$second = { 4F 40 15 6B 16 5E 54 09 4F 41 43 10 }\r\n\t\t\t$third = { 4F 45 44 5E 14 67 09 69 5C 55 44 11 }\r\n\t\t\t\t\r\n        condition:\r\n\t\t\t1 of them\r\n}\r\n<\/pre>\n
      Submitting the rule above will result in the key: PAN{7H1r7EEn-hOuR_71me_l1M17}<\/p>\n
      Threat 5 Challenge: Hello Confetti!<\/h3>\n
      Challenge Created By: Anthony Kasza <\/em>@anthonykasza<\/em><\/a><\/p>\n
      Opening the provided \u201chello.pcap\u201d file with Wireshark and examining the protocol hierarchy within the pcap shows only UDP traffic. Wireshark believes a few of the packets are malformed real-time transport control packets while the majority of the packets are data.<\/p>\n
      \"CTF_Threat_29\"<\/span><\/div><\/a><\/p>\n
      Observing the UDP conversations within Wireshark, only a single \u201cconnection\u201d occurred within the pcap. The connection is between port 9090 and 53321 on 127.0.0.1. The inconsistency of protocols above combined with a single connection within the trace file leads to the conclusion the protocol being used is non-standard.<\/p>\n
      \"CTF_Threat_30\"<\/span><\/div><\/a><\/p>\n
      The first packet in the trace contains the data \u201chello :)\u201d followed by an 0x0a. This is the only packet with a length that\u2019s not 8234 and sent from port 53321 to port 9090. The second packet contains data which starts with \u201cBZh\u201d which is the magic file header for a bzip file. Ignoring the first \u201chello\u201d packet, a bzip archive can be extracted from the trace file. Decompressing the bzip archive reveals a second pcap trace.<\/p>\n
      Using similar techniques as before, multiple FTP over IPv6 connections can be observed within the pcap. Following one of the FTP connections reveals a series of requests and responses, which all streams mimic:<\/p>\n