# **Disclosure**

The purpose of this document is to provide a technical write up that will outline performing memory forensics to retrieve “evidence” out of a memory dump taken from the laptop of a “conspiracy nut.” This document is not an all-encompassing guide to performing memory forensics and is intended for educational purposes only. Additionally, I would like to thank the author of this challenge, ***condor0010*** and the “conspiracy theorist” ***monkey_noises*** from Florida Tech. The students of Florida Tech put on the Space Heroes CTF as part of their CSE4860 class which is the origin of the challenge which we are solving.

# **Briefing**


Per the briefing above we are going to be looking at a memory dump to identify and obtain some form of “evidence” that was on the laptop. Bear in mind is we are only looking at memory, or anything that was running in RAM, at the time that the capture was taken and not the contents of disk, meaning the hard drive. For this challenge I am using Kali Linux, various Linux commands, [Volatility (the standalone executable)](https://www.volatilityfoundation.org/releases), and [python-image-extractor](https://github.com/stevesbrain/python-image-extractor) written by ***stevesbrain*** and available on [GitHub](https://github.com/stevesbrain/python-image-extractor).

A few CTF specific tips I have picked up for this event are that all the flags are in the format of shctf{Sample_Flag_Looks_Like_This} and, for majority of the time, if the flag is inside of a file the file likely has “flag” in the name. These tips will come in handy as we perform our initial analysis!
 
# **Initial Analysis**

Once we extract the memory dump out of the provided archive we want to see if we can narrow down what we are going to be looking for. A memory dump contains a plethora of information, and it can be easy to get sidetracked and “go down the rabbit hole” on items that won’t help you achieve your objective. To attempt to avoid this, we are going to use some handy Linux tools. We are going to run ***strings*** on our dump file to extract literal strings from inside the dump file and then pipe that output into ***grep*** (***-i ***means case insensitive) to search for keywords that might help us narrow down what we are looking for and finally pipe that output into ***less*** so we can page through the results for ease of use. Knowing that “flag” is used frequently in this competition we will start with that as the base of our keyword. I originally used the following chain of commands to look through all output of strings to identify something of interest:

***strings conspiracynut.dump | grep -i “flag” | less***

Taking that approach still provides a large amount of output but it did pay off as I found output showing me flag.jpg! Here is a more refined search utilizing a updated keyword and piping output through ***uniq*** to reduce any duplicates in the output:


Considering the only literal string we have identified is flag.jpg and since it is at the end of a URI we can infer that some application is attempting to download that image. Let’s get started with Volatility and identify how to interact with this memory dump!
 
# **Volatility Prep: Profile Identification**

The first step in successfully using volatility is to determine what profile you need to use to analyze the dump file you have. Since we have no background information on the laptop that the dump came from, we can run the following command to have Volatility use the ***imageinfo*** plugin to attempt to identify a profile for us:

***./volatility2.6lin64standalone --imageinfo ../conspiracynut.dump***


***NOTE:***
Due to being against a time clock and running these tools in an ephemeral lab VM I gave the volatility stand alone executable full read, write, and executable permissions without due diligence of researching proper application permissions. This is not advisable behavior. If you are setting up your own instance of any application, you should do your due diligence to understand what permissions are required and the implications that could have on your system depending on the application.

Given there are multiple suggested profiles I ended up just attempting to use the first one ***Win7SP1x64*** and that worked out for me. It is possible you will have to try multiple profiles in a real-world environment. Best practice is identifying a profile by knowing the machine a dump came from, but you will not always have that information. Now we can move to analyzing the memory dump!
 
# **Volatility: Network Analysis**

We are now going to look at network connections via the ***netscan*** plugin for volatility. This plugin will show active network connections and listening sockets but can also find information about network sockets that have been closed. In the following screenshot you will see a modified output of ***netscan*** running, but to provide more meaningful results I have also included the full output of ***netscan*** piped into ***grep*** to only return “ESTABLISHED” connections.

***./volatility2.6lin64standalone --profile=Win7SP1x64 -f ../conspiracynut.dump netscan | grep "ESTABLISHED"***


I would have loved to have seen an established connection to ***57.135.219.202:9000*** as that would have been a dead given away that ***firefox.exe*** is the process we should be narrowing in on. That said, ***firefox.exe*** is still the obvious choice and if I had to choose a second based off the full output, I may investigate ***wmpnetwk.exe*** which is a service that supports ***wmplayer.exe*** aka Windows Media Player. I don’t think WMP supports streaming of .jpg files but you can’t be too careful when you don’t know what applications are capable of. We are going to proceed with investigating ***firefox.exe*** further.
 
# **Volatility: Process Analysis**

There are two useful plugins for Volatility to list running processes ***pslist*** and ***pstree***. Output from each plugin is similar but ***pslist*** offers a few extra columns and ***pstree*** will create a visual representation (in text) of the parent-child relationships for running processes. I am including a modified output of ***pslist*** for review, but we will be focusing on the full output of ***pstree***.

***./volatility2.6lin64standalone --profile=Win7SP1x64 -f ../conspiracynut.dump pstree***


Looking at the output of ***pstree*** for ***firefox.exe*** there are a handful of processes that flag.jpg could be inside of. At this point I decided to dump raw data of each running process to see if I can carve out flag.jpg!

# **Volatility: memdump**

I initially intended to dump each process using the ***memdump plugin***; however, I got lucky and on the second dump for PID 880 I ended up finding the flag! Here is what this process will look like:

***./volatility2.6lin64standalone --profile=Win7SP1x64 -f ../conspiracynut.dump memdump -p 880 --dump-dir=../***


At this point I have two .dmp files sitting on the desktop of my Kali VM that are waiting for some file carving!

# **Python-image-extractor: File Carving**

There are various ways to perform file carving. It is possible to open the .dmp files in a hex editor and manually carve out files using file headers aka “magic bytes.” This process is much easier if the file type has a file trailer or the header details the length of the file. Considering I was looking at multiple .dmp files for all the individual ***firefox.exe*** processes I decided to lean on the power of Python! After a Google search and looking at some different tools publicly available on GitHub, I decided to try the [python-image-extractor](https://github.com/stevesbrain/python-image-extractor) written by ***stevesbrain***. Let’s take a quick look at the tool’s code:


In a nutshell this program is going to open the file I point it at and read it as raw bytes (hexadecimal). Then it will attempt to extract everything between bytes ***FF D8 FF*** (jpg header) and ***FF D9*** (jpg trailer) and write those bytes to a new .jpg file in the current directory. In theory, if flag.jpg is in the .dmp file I should be able to find it among the newly created .jpg files created from the [python-image-extractor](https://github.com/stevesbrain/python-image-extractor) tool. Let’s give it a try on the ***880.dmp*** file I dumped using Volatility!

***python2 ./imageextractor.py --file ./880.dmp***


Now let’s look at the .jpg files on my VM’s Desktop and see if we have any viewable .jpg files.

# **Summary**

I have redacted the flag’s content and the conspiracy nut’s face, but we have successfully found the evidence that the earth is potentially flat, there is no way humanity made it to the moon, birds are spy drones, and Hitler has a secret base somewhere in Antarctica! Going into this challenge I knew some basics about memory forensics and had some of the fundamentals of using Volatility under my belt from taking [SANS SEC504](https://www.sans.org/cyber-security-courses/hacker-techniques-incident-handling/) (Go check that out!). However, this challenge pushed me to step into the mindset of a forensic investigator and challenged me to go find methodologies to answer the questions I came up with while hunting for the flag. If you take anything away from this write up, let it be that memory forensics is a wonderful skill that forensic investigators hone in order to find artifacts in memory that can lead to a better understanding of what happened during an incident!