Incident response is often a stressful, high-pressure situation. Responders are desperately trying to claw together information. All around them the world is collapsing. Furthermore, everything important seems to be deleted or obfuscated. Yet it is not all doom and gloom. They have memory analysis.
Life can be hard for the incident responder. You are faced with malware and/or attacker tools, often heavily disguised. Attackers pack & obfuscate malware to avoid AV. Memory resident attacks can execute without ever touching a disk. Even when you think you’ve won, you discover the attackers are back in again. It can be demoralising.
Memory analysis can help you escape this nightmare cycle.
What do we mean by memory analysis?
At a very high level, we mean collecting RAM from a machine in support of incident response. This can come in many forms.
Computer memory can be thought of as the space your computer uses to do things. This is where things like the screen you see on login reside. You open a new application, it is loaded into memory. For Windows users, if you open Task Manager, that list of running processes are all in memory. Also increasing memory is a fast way to really boost performance.
Memory is really important. This is just as true for the investigator. Because of what it holds, memory analysis can be very revealing.
The most striking demonstration is in hunting malware.
Crafty attackers change their code to avoid detection. They encrypt payloads to fool monitoring. They armour their attacks to make life harder for reverse engineers. All of this can be very effective and it makes life hard for responders.
However, in memory, things are very different. Malware in RAM is exposed. It has to run, so it has to be readable. As a result of this, memory analysis can give a clear insight into attacks. For most investigations, this makes a significant difference.
However, it isn’t simple perfection. As you might imagine, memory analysis has its own problems.
First of all, memory is volatile. This means it changes and when the system loses power, memory is often gone. Often but not always. In incident response, one of the first things you should do is capture the memory. Even if you later don’t need it. If you don’t grab it at the start, you may never get it.
Sometimes you don’t have any choices here. Often, troubleshooting involves a power cycle. People who panic may pull the power cord. All of this goes towards flushing volatile memory. Consequently, investigators get cold, dead, computers to analyse. Yet, despite this, there are still opportunities (hiberfil.sys/pagefile.sys). More on this in a future post.
Another issue is memory can be big. Modern computers often have at least 8GB of ram. If you are looking at servers then 32GB and upwards is normal. This is great for performance. Because of this size, however, memory capture can be slow. It can frequently take over an hour to capture RAM. This might sound trivial but during that time, the RAM will have changed a lot. The volatile nature can be a nightmare for unsuspecting investigators.
Memory analysis solutions
Above all, good incident response processes help. Have the right tools available to capture memory. Make sure captures start first. Make sure there are good records. All of this works towards mitigating problems.
There are lots of memory collection tools. Rather than think “TOOL X” is the best, try them all. Find the one which fits with your workflow the best. Then learn its strengths and weaknesses.
When it comes to analysis itself, there are two main tools to consider.
First of all, Volatility is one of the best-known tools. Every responder should have at least a basic understanding of how to use this. It is free, open source and cross-platform. Volatility is written in Python, making it easy to extend. One of the best things is the sheer range of community plugins available.
The second tool you should look at is Rekall. In some respects, this is more polished but right now it has fewer plugins. Rekall can be faster with new operating systems and integrates well with IR tools.
Finally, out of the main tools, is Redline. This is a free product provided by Mandiant. Unlike the other two, this is a fully GUI tool. Redline provides an easy to use interface at the cost of some flexibility.
Just like with collection, never feel you have to pick one tool over others. Practice them all. Then use them all. Learn how the results from one tool lead to the next. Most of all, become proficient at using the right tool for the right task.
A good example is to use Redline first – giving you high-level insights. Then use Volatility to drill into details.
Memory Analysis – Volatility Plugins
Finally, as mentioned, the strength of Volatility is the community plugins. To this end, on Taz Wake’s GitHub pages we will be releasing IR plugins for everyone to use/ adapt/develop. Feedback is always welcome.