GrrCon 2015 - Memory Forensics - Grabbing all the Flags...

Today we bring you a special guest posting by Tony "@captcook32" Cook. Late last year GrrCon hosted their anticipatory excellent set of challenges which included an in depth memory forensics challenge by Wyatt Roersma. Tony and myself took a few days on a down week to try our hand at the challenge. I lacked the answers to two questions while Tony knocked them all out quickly.

While the scoreboard was reset to before our scores were posted, I'd like to present Tony's write-up on the challenge. The challenge files are still available for download, so feel free to try the challenge on your own and return for hints. Next to each question is the file required to answer it and the password needed to open the archive.

And so follows Tony Cook:

In October 2015 Google put on the GrrCon 2015 CTF challenge which was open to all who wanted to attempt the challenge. My colleague "The Brian Baskin" @bbaskin let me know it was going on & I wanted to test out my memory forensics skills so I gave it a shot. This was one of the most fun & valuable CTFs that I've ever done. I want to give a huge shout out the the Volatility team for their awesome product & for the GrrCon 2015 CTF team for having a semi real world challenge that made you think outside of the box. The following blog post is my walkthrough of how I got through the challenge. There are most likely far better ways to go about doing most of these & I don't claim to be a memory forensic expert but I hope this helps out anyone who got stuck on any of the questions &/or anyone looking for an explanation. 

Question #1

We start out with a question letting us know that user opened a "strange" email that appeared to be a security update, kudos to the CTF creators because who hasn't seen that happen... All we need to provide is the sender's email address. As with all of these questions there are about a million different approaches that we could take to find the answer, however, the way my lazy mind works I wanted to start by finding all the email addresses within the memory dump, then use that list to grep through the memory dump for these email addresses to hope for an email that would resemble the user's . So to start with I utilized Garfunkel amazing tool, the Bulk Extractor. Among several other options this tool can provide you with a histogram of email addresses which will provide us a starting point to start looking through the memory dump.

Malware with No Strings Attached Part 1 - Dynamic Analysis

I had the honor of lecturing for Champlain College's graduate level Malware Analysis course this week. One of the aspects of the lecture was showing off dynamic analysis with my Noriben script and some of the indicators I would look for when running malware.

While every malware site under the sun can tell you how to do malware dynamic analysis, I wanted to write a post on how I, personally, perform dynamic analysis. Some of the things I look for, some things I've learned to ignore, and how to go a little bit above and beyond to answer unusual questions. And, if the questions can't be answered, how to obtain good clues that could help you or another analyst understand the data down the road.

Additionally. I've been meaning to write up a malware analysis post for awhile, but haven't really found any malware that's been really interesting enough. Most were overly complex, many overly simple, and most just too boring to write on. Going back through prior incidents, I remembered a large scale response we worked involving a CoreFlood compromise. While this post won't be on the same malware, it's from a similar variant:

MD5: 4f45df18209b840a2cf4de91501847d1
SSDEEP: 768:ofATWbDPImK/fJQTR5WSgRlo5naTKczgYtWc5bCQHg:uk6chnWESgRKcnWc5uF
Size: 48640 bytes

Note: I cannot host the file here, but it can be obtained through VirusTotal (for those with privileges) or directly from Malwr with a free registered account.

This is not a ground-breaking malware sample. The techniques here are not new. I want to simply show a typical workflow of analyzing malware and overcoming the challenges that appear in doing so.

There are multiple levels of complexity to this sample, too much for a single post, including ways in which it encrypts embedded data and strings. Therefore, this post will focus on the dynamic artifacts of running the malware and examining the files left behind. On the next post, we'll use IDA Pro to dig deeper into reversing the logic used by the malware.

Dumping Malware Configuration Data from Memory with Volatility

When I first start delving in memory forensics, years ago, we relied upon controlled operating system crashes (to create memory crash dumps) or the old FireWire exploit with a special laptop. Later, software-based tools like regular dd, and win32dd, made the job much easier (and more entertaining as we watched the feuds between mdd and win32dd).

In the early days, our analysis was basically performed with a hex editor. By collecting volatile data from an infected system, we'd attempt to map memory locations manually to known processes, an extremely frustrating and error-prone procedure. Even with the advent of graphical tools such as HBGary Responder Pro, which comes with a hefty price tag, I've found most of my time spent viewing raw memory dumps in WinHex.

The industry has slowly changed as tools like Volatility have gained maturity and become more feature-rich. Volatility is a free and open-source memory analysis tool that takes the hard work out of mapping and correlating raw data to actual processes. At first I shunned Volatility for it's sheer amount of command line memorization, where each query required memorizing a specialized command line. Over the years, I've come to appreciate this aspect and the flexibility it provides to an examiner.

It's with Volatility that I focus the content for this blog post, to dump malware configurations from memory.

For those unfamiliar with the concept, it's rare to find static malware. That is, malware that has a plain-text URL in its .rdata section mixed in with other strings, and other data laid bare in plain sight. Modern malware tends to be more dynamic, allowing for configurations to be downloaded upon infection, or be strategically injected into the executable by its author. Crimeware malware (Carberp, Zeus) tend to favor the former, connecting to a hardcoded IP address or domain to download a detailed configuration profile (often in XML) that is used to determine how the malware is to operate. What domains does it beacon to, on which ports, and with what campaign IDs - these are the items we determine from malware configurations.

Other malware rely upon a known block of configuration data within the executable, sometimes found within .rdata or simply in the overlay (the data after the end of the actual executable). Sometimes this data is in plain text, often it's encoded or encrypted. A notable example of this is in Mandiant's APT1 report on TARSIP-MOON, where a block of encrypted data is stored in the overlay. The point of this implementation is that an author can compile their malware, and then add in the appropriate configuration data after the fact.

As a method to improving the timeliness of malware analysis, I've been advocating for greater research and implementation of configuration dumpers. By identifying where data is stored within the file, and by knowing its encryption routine, one could simply write a script to extract the data, decrypt it, and print it out. Without even running the malware we know its intended C2 communications and have immediate signatures that we can then implement into our network defenses.

While this data may appear as a simple structure in plaintext in a sample, often it's encoded or encrypted via a myriad of techniques. Often this may be a form of encryption that we, or our team, deemed as too difficult to decrypt in a reasonable time. This is pretty common, advanced encryption or compression can often take weeks to completely unravel and is often left for when there's downtime in operations.

What do we do, then? Easy, go for the memory.

We know that the malware has a decryption routine that intakes this data and produces decrypted output. By simply running the malware and analyzing its memory footprint, we will often find the decrypted results in plaintext, as it has already been decrypted and in use by the malware.

Why break the encryption when we can let the malware just decrypt it for us?