New Training From SANS Institute: How To Discover If Malware Is Running In RAM Only On Your Systems

Linda Musthaler
By | March 18, 2013

Posted in: Network Security Trends

Brian and I recently had an opportunity to talk with Jesse Kornblum, an instructor for the SANS Institute. Jesse has developed and just started teaching an advanced course called Windows Memory Forensics In-depth. This course would be valuable for any IT security professional working in an industry or for an organization that has a constant target on its back. For example, financial services, critical infrastructure, military or government—the kinds of high-value organizations that attackers go after persistently. Jesse says that the students who have taken the course so far have found it very valuable, so I’d like to take this opportunity to have Jesse tell you more about it.

Linda:  Tell us what this course is about.

Jesse:  The course is on Windows memory forensics. The students learn techniques to find memory resident malware, which in terms of cyber attacks is at the top of the scale.

Traditional forensics looks at what is on the disk. When malware gets written to disk, it is stored on the server and run on the computer, and that’s how it maintains its persistence. In the past several years though, malware authors have realized that if they write their code to the disk, it can be discovered easily. It’s right out there for anyone to see. And so what they’ve started doing is making their malware memory resident only. In essence, the malware is loaded into RAM and it never touches the disk. Therefore it won’t be found using traditional forensic techniques.

This course that I’m teaching uses techniques to go through the RAM to find pieces of evidence that simply do not exist on the disk. Not only would that be malicious software, but it could also be other evidence that never gets written to the disk. An example of that would be encryption keys. When someone uses a full disk encryption product, this kind of tool stores the keys in RAM so the program can use them. But the keys never get written to disk, and they can be crucial for an investigation. In the class, we go through techniques to find that kind of data in RAM.

The course focuses on techniques and not how to use any one program. It’s almost a course on operating system internals. Students learn to detect what is going on in the operating system and then to use that knowledge of what should be in RAM and compare it to what is really in RAM. The ultimate goal is to have a sense of what is normal and what should be there, and what is not normal and what should not be there. We also want students to learn to use tools that will automatically highlight the things that are not supposed to be there.

Linda:  That sounds incredibly complex. Is there a great need for this kind of memory analysis and forensics? Are you seeing more instances of malware that are in memory only?

Jesse:  Absolutely, yes. It is where the professional attackers are going. You can certainly argue that every attacker starts with the lowest, easiest means possible and then moves up the scale, but when you get to the top of the scale, you reach malware that is memory resident only. This is something they might use after every other type of attack has not worked. It would absolutely be in the toolkit of an advanced attack.

Linda:  What kind of companies would be interested in having their IT security professionals take this course?

Jesse:  People representing a range of industries have taken this course and have provided good feedback to us. This includes people who work in a network operations center and they are watching over a large IT infrastructure. My students have included people from computer security companies, banks and consulting firms, and we even had a guy from a nuclear power plant who was absolutely thrilled with this course. Certainly anyone working in a critical infrastructure environment would be interested because their organization is an ideal target of these kinds of attacks.

Unfortunately, attackers are interested in a specific nuclear plant or a specific government contractor because of the kind of work they do. When you are that kind of target and somebody is going to try multiple kinds of attacks against you, eventually they are going to get to something that is memory resident that you can’t detect using traditional disk forensics. It’s great to see that a lot of these organizations are being proactive. They are coming to us for training before they even suspect one of these memory resident malware programs on their systems.

Linda:  When a security professional suspects that there is an attack going on in memory, what should they do about it?

Jesse:  The first step is to preserve the evidence. You have to acquire a memory image and that means sending the contents of RAM to a file. It’s not hard to do, but must be done first during incident response. If it’s not the first thing done, other steps could overwrite data which would be valuable to the investigation. Having the correct tool is important too. Mistakes in memory acquisition tools could crash the system and also destroy the evidence. So the first and most crucial step is evidence acquisition.

Once you acquire the memory image, you can start doing a basic analysis on it which really consists of two kinds of analysis. The first is treating memory as an unstructured resource and just going through and searching for strings and encryption keys—things that don’t depend on any operating system structures. There’s also a step of brute force examination which is necessary to go to the next step, which is a structured exam. We need some, essentially, “magic values” from the memory image. Those magic values determine how to do the next analysis.

A disk image has a header at the start which tells you the size of the disk and how many clusters there are—basic information about the layout of the disk. A memory image has no such header and we need to figure out some basic information for ourselves and we do that using a brute force search. With the information from that brute force search we can then go through and start doing a structured analysis. This involves pulling out a list of processes and a list of loaded kernel modules or drivers, and seeing what’s there. In that stage we can then compare a brute force search of processes to a walk of the operating system structures. In other words, we’ll do a brute force search looking for any processes we can find and then we’ll compare that to a list of processes that the operating system knows about. Anything that appears in one list but not the other is automatically suspicious. If we find information about a process using the brute force tools and the operating system didn’t know about it, this sticks out like a sore thumb.

My term for this is the rootkit paradox. The rootkit paradox states that the more a malware author tries to hide his actions, the more obvious his actions become. When a malware author is trying to hide a process, he makes it so that the operating system doesn’t see it. It doesn’t show up in task manager, it doesn’t show up in a list of processes. But the process is still there. It still needs to run. It needs operating system resources, it needs to reserve space in memory, it needs CPU cycles, it needs to talk to the network—it still needs to be there.

Because there is this mismatch between what we can find in a brute force search and what we can see with a walk of the operating system structures, it highlights the malware. If we find 21 processes using the brute force search but only 20 processes with a walk of the operating system structures, that one process that has been hidden really sticks out. And so we can automatically find the malware without necessarily knowing what the malware is, or how it works. We don’t need to know anything about it before we start. It’s just the thing that sticks out, and we uncover it using some pretty sophisticated techniques. These are the techniques that we cover in this course.

Linda:  Are there kinds of attacks limited to servers only?

Jesse:  No, they certainly aren’t limited to servers. The kinds of programs that live in RAM are great for stealing keystrokes on a personal device like a PC or smart phone. An attacker might target a high-value person such as a CEO or CFO and plant a keystroke logger or a program to capture screen content. Those programs can be memory resident only and it’s entirely possible to put one on an end-user system.

Conclusion

So there you have it, folks. Memory resident malware is a high level threat for many organizations, and special knowledge and skills are needed to detect the presence of this malware. If this kind of attack is a concern for your organization, check out the new training available from SANS Institute.

You May Also Be Interested In: