Sunday, March 31, 2019

LNK Forensics: Cal Poly FAST CTF Challenge 8


Question: What is the MAC address of the computer these files originated from? (Hex in lower case)
Hint: One of these files is the missing lnk to your answer.
Answer: d0:50:99:82:33:6e

In this challenge you were given a folder with random files I grabbed from my computer. With these files, you should be able to deduce the MAC address of my computer.



Only one of these files is actually helpful to finding the answer. As the hint hints, “One of these files is the missing lnk”. In Windows, shortcut files contain a large amount of metadata of the original file these link from, as well as the host computer. Magnet Forensics has a short article explaining some information about LNK files here: https://www.magnetforensics.com/computer-forensics/forensic-analysis-of-lnk-files/. Exiftool is a great tool for find information and metadata about files. Using Exiftool on “Ljones – Close.mp4” gives the following results:




A lot of information came from such a small file! We can see interesting data such as Volume Label, Machine ID, Target File Size and more. Unfortunately Exiftool did not find the MAC address. Exiftool works best for finding Exif metadata. For the forensic analysis of LNK files, Eric Zimmerman’s Link Explorer works great. You download Link Explorer (LECmd) from https://ericzimmerman.github.io/.

To specify a file to examine, use the “f” flag:

LECmd.exe -f “Ljones – Close.mp4.lnk”






























This displays a lot of additional information compared to Exiftool. Scrolling down we can see in addition to the Machine ID that we found earlier, we have discovered the MAC address: d0:50:99:82:33:6e. Next time you do your forensic investigation, be sure to check out any link files on Windows machines.


Image Anti-Forensics: Cal Poly FAST CTF Challenge 7


Question: The flag is in this image. What is it? Format: fastctf{flag}
Hint: The magic is missing, don't believe the image now.
Answer: fastctf{PNGesus}

In this challenge, a given image file contains a flag and you must find it in there. This leads to many possibilities. Is it stego? Is it hiding in the strings? How is it in the image? These are good questions to ask. Trying to open the image should give you message from your image viewer saying it is unsupported.




So this file format is not supported. What kind of file is this exactly? This is where the “file” command comes to the rescue. You can use the file command in Linux of Cygwin (a Linux emulator for Windows).

file file7.jpeg




It appears “file” has failed us, since it only recognizes it as data. If this file is a JPEG, it should have some metadata that Exiftool can see.




Exiftool responds with very little useful information, other than stating there is a file format error, which would explain why our picture viewer failed to display the image. As with all CTF challenges, it is always good to run the strings and binwalk commands. Our hint tell us, “The magic is missing, don't believe the image now.”, and from strings we find the string “what’s the magic number?”.





A magic number is a binary sequence in the header of every file used to identify the file. All files should include a magic number, and the operating system examines this and the extension to determine the file type. All JPEG files should start with the binary sequence “FF D8 FF” since it is their magic number. Using a hex editor, we can examine the header of the file and change it if we need to. HxD is a free, simple, and easy to use Hex editor for Windows (https://mh-nexus.de/en/hxd/). Bless is an alternative hex editor for Linux. Opening file7.JPEG reveals our issue.




The magic number should be at the very start of the file, but instead all we see are zeros. Someone has removed the header from this file, which explains why the file command could not identify it. We can add “FF D8 FF” to the start of the file and it should display properly. After editing the file and opening it, we see this:




Now the image file will not open at all. Our extension and header both match, so why is this happening? Let’s look back at our hint: “The magic is missing, don't believe the image now.”. So the magic number was missing, but it turns out that this not actually a JPEG file at all. To determine the original format of the file can be tricky if both the header and extension have been edited. Usually checking strings is our best bet. However, it was stated both in the question and hint that this was an image file. In that case we can continue to try different headers and matched extensions until the file opens properly. Common image formats include:

Format
Magic Number
JPEG/JPG
FF D8 FF
PNG
89 50 4E 47 0D 0A 1A 0A
GIF
47 49 46 38 37 61 or 47 49 46 38 39 61
BMP
42 4D
TIFF
49 49 2A 00

For a list of magic numbers and associated file formats, check out: https://en.wikipedia.org/wiki/List_of_file_signatures.

File7.JPEG is actually a PNG image, and if we edit the header and extensions to reflect that, the image will properly open.



























Now we can see the flag is “fastctf{PNGesus}. In hindsight I may have made this challenge a little too tricky. Beyond the magic number there is still data chunks that you could have examined to determine that it was a PNG file (“IHDR” is a critical first chunk, file ends with “IEND” chunk). You can read more about the PNG file structure here: http://libpng.org/pub/png/spec/1.2/PNG-Structure.html


Detecting Timestomped Values: Cal Poly FAST CTF Challenge 6


Question: What is the original modification time by the kernel of the document "New Text Document.txt"? Format: YYYY-MM-DD HH:MM:SS.SSSSSS
Hint: It appears this file has been time-stomped. AnalyzeMFT may be able to help.
Answer: 2018-02-24 21:15:35:512585

Challenge 6 provided an E01 file to examine. You will need to download a forensic tool like FTK of Autospy to view the data. I will be using FTK for this demonstration. For this challenge, we want to know the original modification time by the Windows kernel for the file “New Text Document.txt”. Note the language used in this question. We want to know the modification timestamps provided to file by the kernel, not by the user. This challenge is more advanced, and expects some knowledge of Windows timestamps and NTFS forensics.

When we first open our E01 file we find that the text document is empty and its timestamps are from January 1st, 1601. Either the timestamps have been manipulated, or I am a time traveler. The timestamps have been set all the way back to the start of the Gregorian calendar, which is the point in time where Windows counts forward from.



This file was altered with a tool called timestomp, which exists as a metasploit module or as a standalone Windows executable. Timestomp can alter all 4 timestamps in user-space. These 4 different timestamps are collectively referred to as MACE - Modified, Accessed, Created, and Entry modified. Timestomp can not however edit timestamps given by the Windows kernel (which should be identical to their user-space counter parts). Ok, now that we know this, now what? Well we will only see userspace timestamps by examining the file in Explorer and even FTK is fooled. “I’m a Noob, I have no idea what I’m doing”. This is why the hint is more of an instruction than a hint.

All of the files starting with dollar signs are NTFS artifacts. The one we are interested in is $MFT, the NTFS Master File Table. As our hint stated, AnalyzeMFT may be able to help. AnalyzeMFT is a Python program for parsing the $MFT. You can download AnalyzeMFT from https://github.com/dkovar/analyzeMFT or install it using the pip package manager. Now the $MFT file must be exported from FTK. You can do this by right-clicking and selecting export.


Since $MFT is a hidden system file, you won’t be able to see it initially. From the directory you exported $MFT to, open a command prompt and use the command:

attrib -s -h $MFT

This alters the attributes of the file to make it visible to us. Now we will use AnalyzeMFT to export the data to a .csv file in an Excel-friendly format:

analyzeMFT.py -f $MFT -o MFT.csv -e





Once exported we will have a MFT.csv file that we can easily examine. Looking at “New Text Document.txt”, there are 8 timestamps associated with it. The first 4 are the $SI (Standard Information attribute) timestamps. These timestamps are modifiable in user-space. The following 4 timestamps are the $FN (File Name attribute) timestamps. These timestamps are given by the Windows Kernel and can not be edited by timestomp.



















The $SI MACE timestamps associated with “New Text Document.txt” display as an invalid timestamp. In blue I have highlighted the $FN modification timestamp, which is our answer, 2018-02-24 21:15:35:512585.


For someone who is unfamiliar with NTFS forensics, this can seem pretty overwhelming. These resources can help you learn more:
Windows MACB Timestamps (NTFS Forensics): https://www.youtube.com/watch?v=OTea54BelTg


Buffer Overflows: Cal Poly FAST CTF Challenge 5


Question: Here's a simple C program. What's the password? Format: "fastctf{flag}"
Hint: The C is so full, it's overflowing!
Answer: fastctf{badcodefails}

This challenge gives a simple C program and expects you to find that flag. Running file5.exe asks for a password, and if supplied the wrong the answer, quits.


Trying to brute-force what the password is not the desired method, but it can be done. Since the  format of the flag is in curly brackets, you can easily find the flag by searching through the strings of the file. Strings are literal strings of ASCII or Unicode characters inside files. There are many GUI and command line tools for finding strings. I like to use BinText on Windows (https://bintext.soft32.com/).



Not only can we see the flag “fastctf{badcodefails}”, but we can also see the correct password needed to display the flag was “thecorrectpassword”. If you did not use strings to solve this and instead looked at the hint “The C is so full, it's overflowing!”, then you may have deduced this can actually be solved via buffer-overflow. Below is what the C program looked like before I compiled it with GCC.



Note the buffer will read 64 characters. In this example the gets() function does not check the array bounds and can write a string with a length greater than the buffer itself. When more than 64 characters are entered into file5.exe, it overflows the buffer and overwrites the memory of the “pass” integer. So now that “pass” has been overwritten, it is no longer zero and the flag is printed since the if() function checks if “pass” is zero or not. Normally the if() function would only execute after “thecorrectpassword” is entered as it changes “pass” to 1.



In the picture above, 65 characters are inserted and the flag is printed. Now you learned a little something about buffer overflows! 

Sunday, March 10, 2019

Using Hashcat on 7zip Archives: Cal Poly FAST CTF Challenge 4

File: file4 https://raw.githubusercontent.com/mfput/CTF-Questions/master/ file4
Question: The flag is in there somewhere, I swear. Format: "fastctf{flag}"
Hint: This archive appears to be password protected. Maybe a certain Cat can lend a hand?
Answer: fastctf{the hashcat goes meow}

Interestingly this file contained no extension. Often CTFs will not include file extensions as an extra layer of difficulty. If you don’t know the extension to a file, the Linux “file” command is the go-to option. In this demonstration I used Cygwin, a Linux emulator for Windows.



File4 is a 7zip archive. Edit the file in Explorer and add the “.7z” extension, then right-click to extract it. If you do not have 7zip, you should, and you can download it from https://www.7-zip.org/.



 When trying to extract the file, you should be treated with this image above. A password on a 7zip archive? Who knew they had that functionality. This presents a problem. However they hint helps us out. “A certain Cat can lend a hand”. Hashcat is a popular GPU-based password cracker that supports many different encryption algorithms, including 7zip archives. You can download Hashcat from https://hashcat.net/hashcat/. While Hashcat can find a matching hash, first you need to acquire the hash from the archive.

7z2hashcat is a perl script that can determine the hash of the password used to encrypt a 7zip archive. You can download 7z2hashcat from https://github.com/philsmd/7z2hashcat. There is also a Windows executable available from the releases page. Once downloaded, the usage for 7z2hashcat is very straight-forward:

7z2hashcat.exe file4.7z


This will create a very, very large hash of the file. You will then need to insert this hash into Hashcat with a good password list. To specify the 7zip archive hash, use the “m” flag with the number 11600.

hashcat64.exe -m 11600 [hash] passwords.txt



Hashcat has successfully cracked the password:12345abc. This value is also added to a potfile in the Hashcat directory. File4.7z can now be unlocked since we know the password. Once extracted, there should be one file: “flag (81).txt”. Examining the text file gives us some more information.



In this file there is some metadata, and some HTML tags, and then a large section that is base64 encoded. From what we can tell that the content-type is an image. Putting the file through the file command gives a little more information on the file type as well.


MIME (Multipurpose Internet Mail Extensions) is an internet standard that extends the HTML format to support email, non-ASCII text, and attachments like images, audio, and videos. Changing the extension to HTML would not have helped. The file is actually an MHTML file, which is an archive format that combines HTML pages with metadata and any images or other attached documents. When changed to an MHTML file it can then be opened and the flag is displayed.


Friday, February 15, 2019

Image Steganography and Cryptography - Cal Poly FAST CTF Challenge 3

File: file3.png https://raw.githubusercontent.com/mfput/CTF-Questions/master/file3.png
Question: Nothing unusual about a FAST logo right! Format: "FASTCTF{FLAG}"
Hint: Ave, True to Ceaser. There also appears to be some low level genin jutsu at play…
Answer: FASTCTF{HIDDEN FLAG}

Challenge 3 sees the FAST logo being used unusually. Similar to the first challenge this challenge has some traces of steganography but it can be detected easily. Using strings shows nothing out of the ordinary. The Linux tool binwalk reveals there is an archive inside this image. Binwalk can be used to find files hidden within files.

binwalk file3.png


Binwalk finds that there is an archive and another PNG image in the image. In Windows you can even extract the file out of the image by using 7zip.



With binwalk you can then extract the files with “e” flag.

binwalk file3.png -e

This creates a “_file3.png.extracted” directory. The file of most importance is the additional FAST logo that was hidden in the first FAST logo.



Using strings on this image gives an interesting result. And the end of the file appears to be the encoded flag.




This is where the hint comes to help. “Ave, true to Ceaser” is a popular quote from the video game Fallout New Vegas. Ceaser also famously created a substitution cipher now known as the Ceaser Cipher or rot13, as it shifts the alphabet 13 characters. We can paste this encoded text into a rot13 decoder (www.rot13.com) and see the result.



The result is still a jumbled mess. If you continued to keep shifting the cipher to rot14, rot15, you would have gone down the wrong path. This is the correct output. Now the second part of the hint makes more sense - “There appears to be some genin level jutsu at play”. For anyone who watched Naruto, genin ninja are the lowest ranked ninjas and only know a couple of jutsus. If you guessed shadow clone jutsu you were wrong, as it is a reference to substitution jutsu. A substitution cipher substitutes one character for another, like Rot13. The output has been encoded with a mixed-alphabet substitution cipher. We will have to manually swap out each character for the correct one. There is an easy to use substitution cipher decoder at http://substitution.webmasters.sk/simplesubstitution-cipher.php. Using this, we can find out the flag.



First let’s look out our encoded message “BCY KYF IQ RIGCB ZOQBVBZ{CIDDYN ZTOG}”. As stated by the challenge, the flag should be in the format “FASCTF{FLAG}”. Given this we should try substituting “ZOQBVBZ” for “FASCTF”.



Once decoded the flag is becoming more legible. All we have to do know is keep swapping haracters until we have a correct sentence. This decoder also does a frequency analysis of the letters used. “Y” is the most frequent letter in the sentence. In the English alphabet, “E” is the most commonly used letter, so we should try swapping “Y” for “E”.

Eventually, you would have discovered all of the substitutions.

B = T
C = H
F = Y
O = A
Q =S
T = L
V = C
Y = E
Z = F



Now we can see our decoded text, and see that FASTCTF{HIDDEN FLAG} was the flag.
No steganography tools were used to create this challenge. Originally, a text document containing the cipher text was appended to a PNG image of the FAST logo with the command prompt. Then the PNG was zipped in a .zip archive, and this archive was combined with the another FAST PNG by using the command prompt. You can perform this action with the Windows command prompt with the following command:

copy /B picture.png + Archive.zip picture_with_Archive_inside.png

The same process was done to combine the text document with the picture.

Sunday, February 10, 2019

Viewing Exif Data - Cal Poly FAST CTF Challenge 2


Question: This is a generic picture. What is the exposure time of this photograph?
Hint: Exiftool may be of some use.
Answer: 1/200



To someone who knows nothing about Exif data, trying to infer an exposure time from a photograph sounds ridiculous. However, this very information is stored in Exif data. Exif data contains metadata about digital cameras, smartphones, and scanners used when creating a JPG, TIFF, or WAV file. This metadata can even sometimes include GPS coordinates. As the hint explains, Exiftool can be used to view this metadata (https://sno.phy.queensu.ca/~phil/exiftool/). Run Exiftool with no parameters and path to the file.





Among so much more information that was cut off from this screenshot, we can see the exposure time was 1/200.