Down Under CTF memory Forensics Solve9 min read

I was working on the Memory Forensics Challenge for the Down Under 2021 CTF today and had a lot of fun so I wanted to take a moment to write up my solution for it. The challenge, one of several challenges was a three part answer.

• What is the name of the malware that infected my PC?
• What is the name of the persistence mechanism?
• What folder did the infection originate from?

In order to solve the challenge I needed all three answers in one go. This requirement added an extra challenge as now I couldn’t test answers and there were multiple possible variants for the question.

I’ve already covered Volatility in a different CTF post so I won’t be covering all of my thought process and I won’t be covering some of the intro to Volatility things. I will be using the same alias for this post.

After finding the profile for the image I immediately hit the “easy button” with a malfind.

v malfind | tee malfind

Malfind is a great tool for finding process hallowing and executables loaded into process memory. Whenever I’m starting a case with no information I’ll almost always run malfind right off the bat to see what it finds. Unfortunately malfind isn’t always the most accurate and will sometimes hit on NOP sleds. NOP sleds, or large amounts of No Operations instructions can sometimes be an indicator of malware attempting to evade detection by changing its MD5 hash or bypassing AV that doesn’t look at files over a certain size.

In this case malfind did actually detect the malicious program (more on that later) but I didn’t notice because it also hit on some clean processes. It’s not uncommon for malfind to hit on legitimate processes so I had to move on. Time to see what processes were running at the time.

v pslist | tee pslist

There was a lot on this list, very similar to a normal computer, and nothing immediately stood out as malicious. I knew after not seeing anything immediately obvious that this was going to be more challenging than my last CTF.

While pslist is good its not always the best way to visualize the information. One setback with pslist is that it orders all of the processes by start time. A different option we can use to visualize this differently is pstree which will order the processes based on their parent PID.

v pstree | tee pstree

The first and last lines of this image stood out to me almost immediately. Anytime you have uncommon programs spawning without a parent PID its something you should look into. I carved out both of these files for later analysis.

v procdump -p 3628 --dump-dir . && v procdump -p 2080 --dump-dir . 

At this point I was still looking for any clear indications of “badness” so next up on my standard list of things to check is connections. By looking at connections we can look for programs that shouldn’t be making network connections.

v netscan | tee netscan

Unfortunately this also didn’t return any definitive proof of malware. I was about an hour into this challenge and had made almost no progress on even finding the malware, this was going well. I caught my lucky break with the next command by checking the command line history on the system.

v cmdline | tee cmdline 

Well well well, would you look at that. I’m sure that notsuspicious.exe definitely isn’t suspicious. I think I’ve found our malware, and what do you know, it was one of the files I carved out earlier.

Now this next bit is part of the reason I’m not super happy with this CTF. We now have three possible answers for the first part of the question. Since the question was asking for the name of the malware it could mean

• drpbx.exe, since this was the original name
• notsuspicious.exe, since this was the name of the file when it ran
• Jigsaw, since this the family of malware

The actual answer was Jigsaw but it took a bit of trial and error before I could discover that. I had a suspicion that this file was malicious but I wanted to prove it so I took the file over to VirusTotal and uploaded it.

Thanks to the cmdline command I was now able answer the first and last parts of the question. The file name was jigsaw and it launched out of folder PJxhJQ9yUDoBF1188y.

This was another point of confusion for the CTF. Was the folder just the immediate folder up or was it the present working directory in full?

Now that I had the first and last answer I still needed to figure out the persistence mechanism.

When hunting for malware one of the first places you should check is the Registry Run key. Thankfully volatility has an easy way to check everything set to autorun with the computer with the autorun command.

v autoruns

Unfortunately for some reason volatility chokes on this image and autoruns errors out. Thankfully volatility has a way to query individual hives and keys directly.

v printkey -K "Software\Microsoft\Windows\CurrentVersion\Run" | tee runkety

This is interesting. Discord starting on login is fairly normal, but why would firefox be starting? Also why is Firefox not capitalized and why is it booting out of \appdata\roaming? Furthermore why is firefox running out of the parent directory of Frfx instead of Mozilla? These are strange but think back to earlier, remember we had firefox spawning from nothing? All of this should cause your invisitagtive senses to start tingling. It’s time to dump some files.

First I need to find the location of the files memory address as Volatility has no real concept of file paths. Thankfully Volatility has a helpful plugin to print the memory address of every loaded file on the system. This command can print out a very large amount of data so to avoid scrolling through everything we’ll filter down to what we know is probably bad.

v filescan | tee filescan | grep -i "frfx"

We now know two memory addresses so the next step is to retrieve the file. This process is frequently referred to as “carving” because we’re carving a small piece out of a large chunk of memory.

v dumpfiles -Q 0x000000007f8dd3d0 -n --dump-dir .

The -Q tells Volatility to look for the memory address and the -n is to keep the name of the file.

With the file successfully extracted we can now take it over to VirusTotal and upload it to confirm our previous suspicions.

I think we’ve found our persistence malware.

Now I have a bit of consternation about this part of the question as well. The questions specifically asks for the persistence mechanism, which would be Registry Run Keys (T1547.001) but what it really wanted was the name of the persistence file, firefox.exe.

At the end of the day the flag turned into: DUCTF{jigsaw_firefox.exe_ pjxhjq9yudobf1188y}.

Notes:

Incase you were curious the malware was a ransomware.

Conclusion:

Thie CTF was pretty fun and a bit challenging. With no blatantly obvious information, since we were working with a legitimate ransomware program, it was a true hunt for the malware. The question could have been worded a bit more clearly but the challenge was overall pretty good. Thanks Down Under CTF!