When it comes to memory forensics, Rob Lee explained it best when he taught me that “malware can hide, but it cannot run.” He was referring to the fact that malware can hide on disk encrypted, compressed, armored and however else it wants to exist. But when it needs to run, it has to move into memory, which is where we, as DFIR professionals are able to catch it. This is where the malicious artifact has to expose itself to the system in order to gain the access it needs.
Most of us are familiar with the cheat sheets that exist for windows forensics, see the image below for a memory jogger, if you hold the GIAC Certified Forensic Analyst certification:
Most of us, even when dealing with Capture the Flag events have happened upon this cheat sheet, which is an amazing resource. But if you are trying to analyze a memory dump from a Linux machine, this isn’t going to help you very much. There are a multitude of resources available for Linux memory analysis, but they never seem to cover EVERYTHING.
I grabbed a Linux memory dump and started the steps that I was taught in reference to memory analysis (at home… these steps would be completely different in an environment where budget wasn’t an issue).
vol.py -f memory_dump.img imageinfo
This was the first thing that I got:
I could tell that the Linux memory structure was not the same as the Windows dumps that I had dealt with before. I was referred to this page from the Volatility official Github. This listed tons of commands that I had not seen in my dealings with Windows dumps.
So I followed the typical enumeration steps using the commands listed on the Github account.
This was frustrating, as many of the commands would not work with the profile I was using:
According to Wikipedia: SLUB (“the unqueued slab allocator“) is a memory management mechanism intended for the efficient memory allocation of kernel objects which displays the desirable property of eliminating fragmentation caused by allocations and deallocations. The technique is used to retain allocated memory that contains a data object of a certain type for reuse upon subsequent allocations of objects of the same type. It is used in Linux and became the default allocator since 2.6.23.
This must have something to do with trying to pull cached data from the dump. Assuming that there are certain areas of the memory that are retained for reuse, it would make sense that Volatility is unable to effectively parse it.
In trying to gather all of the information about the Linux dump that I was looking at, I resulted in looking at the naming convention of the commands and going beyond what the Volatility Foundation had listed on the Github. If you look at the “linux” commands, they are eerily familiar to the windows commands, with an appended “linux_” at the beginning. I decided to just try a different Windows forensics command, appending “linux_” to the front of it… and:
It worked. I am sure that there are other great write-ups out here that have identified this, but I intend to run an exhaustive list of the Windows commands with the “Linux_” appended to it and see if they work. That will be coming in a future post.