Not All Is Lost When You Lose Your Memory
Some time ago I wrote a blog, Memory: It’s What’s for Dinner, about the importance of capturing volatile data and memory analysis. I also provided an intro for memory analysis in Hunting Malware with Memory Analysis and More Memory Fun. What happens if you are not able to grab memory? Obviously, a full memory capture of the suspect system will give you the best chance at recovering volatile information from the system but if you can’t, not all is lost.
Hibernation and page files contain data that can help put the pieces of the puzzle back together. The hibernation file, hiberfil.sys, is a compressed copy of the memory when the system last went into hibernation. When entering hibernation mode, the system saves the contents of its random access memory (RAM) to a hard disk. When the system resumes or “wakes up,” the system is exactly as it was before entering hibernation mode. The page file, pagefile.sys, is used to store page-size blocks of memory that do not currently fit into physical memory known as swapped pages. Although Windows® supports up to 16 page files, normally only one is used.
Page files cannot be processed with Volatility so I will discuss them briefly before I continue with the hibernation file analysis. While the page file is just the “holes” in memory where blocks are stored to disk, it will often contain information that can be relevant to the case you are trying to solve. To start your analysis on the page file you could use the strings command, but this could take a long time to step through the file. The options you have is to pipe your strings command through grep to look for specific strings like so:
Or you can use the page_brute tool to make quicker work of it. Page_brute breaks the page file into page-sized blocks and scans it with Yara signatures. The nice thing here is you can create a Yara rule with strings that you are interested in to apply to the page file. This will pull the entire block where there is a positive hit from the yara signature so there will still be a lot of strings to go through, but it’s useful for identifying relevant information in the page file.
Now let’s get back to the hibernation file. Since the hibernation file is just a compressed copy of the memory, we can use Volatility the same way we would with any other memory sample. But, we will need to first decompress it by converting it to a raw memory dump. This too can be done using Volatility. Volatility will actually work with the hiberfil.sys file, but it is extremely slow because it will have to decompress it every time a different plugin is used. Just decompress it once using the imagecopy plugin and it will speed up the process.
As we can see in the following images, using Volatility on the hibernation file works as expected. Many of the plugins are able to return the relevant information. The catch, however, is that when a system goes into hibernation mode the network connections are closed so the connections plugin will not return the network connections of the system. The good news is we can look at the running processes with the pslist plugin, check associated handles with processes, and so forth.
Also, malware may have had a chance to clean up before going into hibernation mode and hide itself from memory analysis. If it didn’t though, we can still use the malfind command to locate malware injected into different processes.
To wrap it up, I want to reiterate the importance of capturing memory during incident response and memory analysis during your forensics examination. The evidence in memory can make or break your case and is too critical to do without. Now that you know what you can do with the hibernation and page file, you have an alternative approach in such a situation.
Be Calm and Memory On.
Read more on Solutionary Minds about: