Finding the Needle In The Haystack: MemLabs Lab-1

Recently I came across a newly released CTF based around memory forensics, called MemLabs, and as memory forensics is quite an important subtopic in malware analysis, I decided to brush off my Volatility Framework and give it a go!
So this is challenge 1 of 6, and I’ll be using Volatility, GHex, and GIMP to complete it – the challenge can be found here. Each challenge has 3 flags, so let’s begin!

Flag 1:

In this first challenge, we are given a large memory dump file. Unlike most CTF’s, there is no real description as to what we are supposed to be looking for, or any initial hints. While this may seem quite unhelpful, it replicates a real life situation pretty well – there are no hints when it comes to pinpointing the location of malware such as rootkits or evasive spyware. So, first things first, we need to get some info on the image such as what operating system it comes from. To do this, we can run the command:

volatility -f MemoryDump_Lab1.raw imageinfo

Looking at the output in the image above, we can see the first suggested profile is Win7SP1x64, so we will be adding this into each command we use; –profile=Win7SP1x64

Now we know this is from a Windows 7 machine, let’s go ahead and check the running processes to see if there is anything unusual running. In order to check this, we can use the module pslist, which lists all running processes at the time of the memory dump. In order to execute this module, we can use the following command:

volatility -f MemoryDump_Lab1.raw --profile=Win7SP1x64 pslist

Scanning through the process list, there are a few notable running processes; mspaint.exe, WINRAR.exe, DumpIt.exe and cmd.exe. At this point, I’m going to assume DumpIt.exe is just the tool used to create the memory dump, and so we will only look into it after the other 3. Let’s first take a look at cmd.exe, as it’s very simple to dump out the command line arguments. All we need to do (taking note of the PID: 1984) is execute the consoles module, and so the command ends up looking like the following:

volatility -f MemoryDump_Lab1.raw --profile=Win7SP1x64 consoles

Looking at the output of the command, we can see both cmd.exe and conhost.exe had some form of command line passed to it, but we are mainly interested in cmd.exe. All that happens in the command prompt is the command St4G3$1 is executed, which returns the value:

ZmxhZ3t0aDFzXzFzX3RoM18xc3Rfc3Q0ZzMhIX0=

This is immediately recognizable as being Base64 encoded, so let’s go ahead and decode it using CyberChef.

Sure enough, after decoding, we get our first flag! Now onto the next!

Flag 2:

So, when I was going through the challenge the first time, I ended up skipping this and going to Flag 3, as I noticed something after executing the wrong module, however I’ll keep it in order for the sake of readability!
We’ve now got a flag from cmd.exe, so now let’s take a look at mspaint.exe. This challenge was a bit more trickier than the other two, however still doable with some helpful posts! 
Before even attempting the challenge, I’m already guessing that the flag is probably an image open in mspaint, so I want to start by dumping the actual process into a smaller file we can work with. To do this, we can use the following command, where -D indicates the directory that we want to store the dump file, and -p is the PID of mspaint:

volatility -f MemoryDump_Lab1.raw --profile=Win7SP1x64 memdump -p 2424 -D Dump/

At this point I tried several different methods of dumping images from the dump, until I stumbled across this amazing post regarding extracting raw images from memory. It seems that magic bytes are not stored in memory when the files are opened in mspaint, and so trying to dump them with modules or carving them from memory is futile. Therefore, we have to rename our dump 2424.dmp to 2424.data and then open it with GIMP.

Upon opening it, we get this popup box – we need to firstly change the image type to RGB Alpha, and then we want to put the width up higher, as well as the height.

Increasing the offset slowly, we can start to see some data in the binary, although it’s too small to make out. Therefore, we need to slowly decrease or increase the width until it becomes clearer.

As you can see, we have almost a clear image here! After fine-tuning it, we can simply click OK, rotate the image 180 degrees (BMP’s are stored upside down), and then read what the text says!

Annoyingly, the text seems to be partially backwards, so it isn’t the easiest to make out, however after some staring, we finally get the following flag!

So, that’s number 2, now onto the final one!

Flag 3:

Remember how I said I completed this flag first by accident? Well, the main reason why was because instead of executing the module consoles, I executed cmdline. This displayed the command line for each process, and I as a result I noticed that WINRAR.exe had the following command line:

************************************************************************
WinRAR.exe pid:   1512
Command line : "C:\Program Files\WinRAR\WinRAR.exe" "C:\Users\Alissa Simpson\Documents\Important.rar"
************************************************************************

At this point, it’s pretty obvious that the flag is located inside Important.rar. As we know the file was passed into WinRAR, it’s most likely stored in memory, so what I did first was run memdump on the process, and searched for the .rar magic bytes: Rar!.

Sure enough, I was able to locate it in memory, plus view the content of the compressed file; a PNG called flag3.png. As carving it out of memory would take too long, we can use the module filescan which lists all files located by Volatility – and we can grep this output to only display strings with “Important” in them, in order to locate our RAR file. The resulting command looks like this:

volatility -f MemoryDump_Lab1.raw --profile=Win7SP1x64 filescan | grep “Important”

The far left values are the offsets of the files in memory, which we can use to actually extract the RAR file very simply. Luckily all the files are the same, so we don’t need to worry about which offset we choose. We can use the following command to dump it out:

volatility -f MemoryDump_Lab1.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fb48bc0 -D Dump/

With the file dumped out, we can now extract the flag3.png and view it!

But wait! It’s password protected! Going back to the original memdump I did, let’s run strings on the dump and grep it for the string “pass” to see if it is mentioned anywhere.

Once again, my assumption worked out, and it seems that the password for the RAR file is the NTLM hash of Allisa’s account password, which is very simple to locate – simply executing the module hashdump lets us view each user’s NTLM hash, including Allisa’s, which is:

f4ff64c8baac57d22f22edc681055ba6

Putting this in uppercase and entering it as the password to the RAR, we get the final flag!

Congratulations! You have successfully completed the first challenge of the MemLabs CTF! I plan to go through a few of these in the coming weeks, as I’ve had a few requests to do some forensics stuff and I’ve been planning on brushing up on my forensics skills, so this is a good excuse to do so! Got anything in particular you’d like me to look into or cover, such as a CTF challenge or a specific technique used by malware? Let me know in the comments, or DM me on Twitter (@0verfl0w_)! 

The post Finding the Needle In The Haystack: MemLabs Lab-1 appeared first on 0ffset.

Article Link: https://0ffset.net/reverse-engineering/mem-forensics-lab-1/