Journey Into Incident Response

Christmas is in the rear view mirror and you may be left wondering about the gift you didn't find under the tree. The gift loaded with DFIR goodness to bring you into the new year. A gift you can use to improve your knowledge and skills. A gift to help you get to the next level in digital forensics, incident response, or malware analysis. You didn't get any DFIR goodness so it's a great opportunity to reward yourself with a gift of your own choice; one to accomplish what the previous sentences alluded to. If you fit this description then the book The Art of Memory Forensics is what you should be looking for. Even if the description doesn't fit and you don't already own this book then you should seriously check it out. This post is my review of the book The Art of Memory Forensics.

Three in One

The book addresses memory forensics on the following three operating systems: Windows, Linux, and Mac. This makes it an outstanding book since it addresses the most commonly faced operating systems. Furthermore, the content not only addresses memory forensic techniques but goes into detail about operating system internals. The majority of the systems I encounter are Windows systems so my focus was on the Windows portion of the book. (I did skim the other sections but I took my time in the Windows section.) The content went deep into the various Windows data structures and function calls. This makes the book an outstanding reference to better understand operating system internals. I easily envision myself using this book as a reference for years to come.

Not Just Words but Hands-on

One thing I tend to look for in a technical security book is how easy is it for the reader to take the content/techniques then apply it elsewhere. This is another area where the Art of Memory Forensics shines. The book's website provides additional materials that accompany the book. The items include lab questions, lab answers, and memory images for each chapter. This allows the reader an opportunity to do the hands-on labs to re-enforce that chapter's content. It's a great way to learn since you are actually performing memory forensics on an image after reading about it. Furthermore, to explain concepts the book uses - for the most part- memory images freely available on the Internet. As you read the book you can follow along by performing the same activities on the same memory images. At times the authors don't explicitly say what memory image they are using but the name of the memory images is pretty revealing. For example, in the Detecting Registry Persistence section (Kindle version page 4626) the Volatility handles plug-in is ran against a memory image named "laqma.mem". On the SampleMemoryImages webpage you can see a Laqma memory image is available and this is the one used in the book. This occurs frequently in the book as well as the authors specifically mentioning the memory image they are using.

The one area I thought that could make this book even better would be for the authors to explicitly state the memory image being used in the examples. This would make it easier for others (especially people who are not aware about the available memory images) to follow along in the book doing the same examples.

Memory Forensics in Toolbox

The last point I wanted to touch on about why I think so highly of this book is memory forensics is a process we need to have in our toolbox. This is true regardless if the work involves incident response or malware analysis. In incident response, there are times when you need to examine the volatile data on a system to obtain an answer. For example, a system is making network connections to a known malicious domain, which is setting off alerts. To tie the network connections to an actual process on the system requires memory forensics. The need for this in incident response is even more so with the recent increase of an exploit kit leveraging fileless malware. In malware analysis, there are times when memory forensics can provide additional information about a sample under examination. Does it open a socket, make network connections, inject code, hook functions, etc.. Memory forensics is now a process we need available in our toolbox and this book can help put it there.

All in All

If you are looking for a gift loaded with DFIR goodness, looking to improve your knowledge/skills, or looking for help to get to the next level in DFIR then this book is for you. The Art of Memory Forensics is a hefty book loaded with excellent content. It's an outstanding book and for those who don't already own it should seriously consider making it their next DFIR purchase. Just make sure to get your money's worth by grabbing the labs, memory images, and then putting hands to the keyboard as you read along.

There are times when you are doing research and you notice certain behavior. You may had been aware about the behavior but you never consider the impact it has on other artifacts we depend on during our digital forensic and incident response examinations. After thinking about and researching the behavior and impact, it makes complete sense; so much so it's pretty obvious after the fact. In this post I'm exploring one such behavior and its impact I came across researching systems impacted by the Poweliks fileless malware. Specifically, how creating a suspended process and injecting code into it impacts the process's prefetch file.

The statement below is the short version describing the impact injecting code into a suspended process has on its prefetch file. For those wanting the details behind it the rest of the post explains it.

If the CreateProcess function creates a process in the suspended state and code gets injected into the process. The prefetch file for that process will contain the trace for the injected code and not the original process. Therefore, the prefetch file can be an indicator showing this technique was used.

Process Hollowing Technique

Malware uses various techniques to covertly execute code on systems. One such technique is process hollowing, which is also known as process replacement. The book Practical Malware Analysis states the following in regards to this technique:

"Process replacement is used when a malware author wants to disguise malware as a legitimate process, without the risk of crashing a process through the use of process injection.

Key to process replacement is creating a process in a suspended state. This means that the process will be loaded into memory, but the primary thread of the process is suspended. The program will not do anything until an external program resumes the primary thread, causing the program to start running"

In addition, the book The Art of Memory Forensics states the following:

"A malicious process starts a new instance of a legitimate process (such as lsass.exe) in suspended mode. Before resuming it, the executable section( s) are freed and reallocated with malicious code."

In essence, process hollowing is when a process is started in the suspended state, code is injected into the process to overwrite the original data, and when the process is resumed the injected code is executed. In a future post I will go into greater detail about this technique but for this post I wanted to keep the description at a high level.

Windows Internals Information

To fully explore the process hollowing behavior on a Windows system and its impact on the prefetch file it is necessary to understand Windows internals. Specifically, when and why prefetch files are created  and how processes are created.

Windows Prefetcher Information

Prefetch files are a well known and understood artifact within the DFIR field. These files are a byproduct of the Windows operating system trying to speed up either the boot process or applications startup. The book Windows Internals, Part 2: Covering Windows Server 2008 R2 and Windows 7 states the following:

"The prefetcher tries to speed the boot process and application startup by monitoring the data and code accessed by boot and application startups and using that information at the beginning of a subsequent boot or application startup to read in the code and data."

As it relates to application prefetch files the book continues by saying:

"The prefetcher monitors the first 10 seconds of application startup."

The information the prefetcher monitors is explained as follows:

"The trace assembled in the kernel notes faults taken on the NTFS master file table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), on referenced files, and on referenced directories."

In essence, if the prefetcher is enabled on a Windows systems then the first 10 seconds of execution is monitored to determine what files and directories the application accesses. This information (or trace) is then recorded in a prefetch file located inside the C:\Windows\Prefetch directory.

Windows Flow of Process Creation

Knowing about process hollowing and prefetching is not enough. It's necessary to understand the flow of process creation in order to see the various activities that occur when a process is created. The book Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7 goes into great detail about process creation and below are the main stages:

1. Validate parameters; convert Windows subsystem flags and options to their native counterparts; parse, validate, and convert the attribute list to its native counterpart.

2. Open the image file (. exe) to be executed inside the process.

3. Create the Windows executive process object.

4. Create the initial thread (stack, context, and Windows executive thread object).

5. Perform post-creation, Windows-subsystem-specific process initialization.

6. Start execution of the initial thread (unless the CREATE_ SUSPENDED flag was specified).

7. In the context of the new process and thread, complete the initialization of the address space (such as load required DLLs) and begin execution of the program.

The picture below illustrates the process creation main stages:


The main stages highlight a very important point as it relates to process hollowing. When the a process is created it doesn't start executing until Stage 7. If the process is created in a suspended state then the first 6 stages are completed. The question is when does the prefetcher come into play. The book Windows Internals Part 1 states the following activity occurs in stage 7:

"Otherwise, the routine checks whether application prefetching is enabled on the system and, if so, calls the prefetcher (and Superfetch) to process the prefetch instruction file (if it exists) and prefetch pages referenced during the first 10 seconds the last time the process ran."

This is very important so it is worth repeating. The prefetcher monitoring application startup occurs in stage 7 when the application is executing. However, a process that is created in the suspended state does not execute until it is resumed. This means if the process hollowing technique is used then when the process resumes and executes the injected code the prefetcher is monitoring the files/directories accessed by the injected code and not the original process. In shorter words:

If the CreateProcess function creates a process in the suspended state and code gets injected into the process. The prefetch file for that process will contain the trace for the injected code and not the original process. Therefore, the prefetch file can be an indicator showing this technique was used.

Process Hollowing Prefetch File

It's always helpful to see what is being described in actual data to make it easier to how it applies to our examinations. To generate a prefetch file I double-clicked the svchost.exe executable located in the C:\Windows\Prefetch directory. Below is the partial output from this prefetch file being parsed with Harlan Carvey's pref.pl script in the WFA 4th edition book materials. (One note about the prefetch file; I added the underscore at the end to force the creation of a new prefetch file.)

File     : C:\Prefetch\SVCHOST_.EXE-3530F672.pf
Exe Path : \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SVCHOST.EXE
Last Run : Wed Dec 17 20:58:57 2014
Run Count: 1

Module paths:
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS
  

As shown above, the svchost.exe executed one time and some of the files accessed are reflected in the module paths section. I asked Harlan about where the executable path comes from in prefetch parsers since the prefetch file format does not record the executable path. He confirmed what I was assuming. Prefetch parsers search the module paths for the name of the executable referenced at offset 0x0010.

Now let's take a look at the prefetch file for a svchost.exe process that was hollowed out. The Lab12-02.exe executable provided with Practical Malware Analysis performs process hollowing to the svchost.exe process. This can be seen performing dynamic analysis on the executable. The images below are from the executable being ran in Malwr.

Lab12-02.exe first creates the svchost.exe process in the suspended state. Notice the creation flag of 0x00000004. Also, make note about the process handle to the suspended process (0x00000094).


Lab12-02.exe then continues by injecting code into the suspended svchost.exe process.


Lab12-02.exe finishes injecting code into the suspended svchost.exe process with the process handle 0x00000094 before it resumes the suspended process.



Below is the partial output from this prefetch file being parsed with Harlan's pref.pl script.

File     : C:\ Prefetch\SVCHOST.EXE-3530F672.pf
Exe Path : SVCHOST.EXE-3530F672.pf
Last Run : Wed Dec 17 20:59:48 2014
Run Count: 1

Module paths:
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
   \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS
  

It may not be obvious in the partial output but the files accessed by the injected code is different than the normal svchost.exe process. One of the more obvious files is what is not accessed; the original executable itself. Notice how the executable path contains the name of the prefetch file and this is due to the actual svchost.exe process not being accessed within 10 seconds of the injected code running.

Circling Back To Poweliks

I mentioned previously that I noticed this behavior when researching the Poweliks fileless malware. This malware doesn't write its binary to disk since it stays in memory. The malware is not only not on the hard drive but other typical artifacts may not be present as well (such as the normal program execution artifacts.) In the near future I'll have a detailed post about how to triage systems impacted by this malware but I wanted highlight why the information I shared in this post matters. The screenshot below shows parsed prefetch files from a test system infected with a Poweliks dropper. My only clue to you is: one prefetch file is not like the others?


There is one dllhost.exe prefetch file that has the missing process path. A closer inspection of this prefetch file reveals some other interesting file access during application start-up:


During access start-up files associated with Internet activity were accessed in addition to the WININET.DLL dll for making HTTP requests. When Poweliks (or at least the samples I've reviewed) initially infects a computer it performs the following actions: rundll32.exe process starts the powershell.exe process  that then starts a suspended dllhost.exe and injects code into it. Powershell.exe then resumes the dllhost.exe process that executes the Poweliks malicious code. The screenhots above illustrate the behavior of process hollowing performed by Poweliks and the impact on the dllhost.exe prefetch file.

The above indication of the missing executable path in the dllhost.exe prefetch file  is only for the initial infection when process hollowing is used. (The malicious code doesn't access the file it injects in once it executes) If Poweliks remains persistent and the system reboots the malicious code is still injected into dllhost.exe process but it doesn't appear to be process hollowing. These dllhost.exe prefetch files will contain the dllhost.exe executable path; along with the trace for suspicious file access as shown in the last screenshot. This is reflected in the second dllhost.exe prefetch file highlighted in the above screenshot.

Conclusion

Uncovering behaviors during research is helpful to put something you take for granted in a different perspective. Process hollowing behaves in a specific way in the Windows operating system and it can impact prefetch files in a specific way. This impact can be used as an indicator to help explain what occurred on a system but it needs context. A missing process executable in a prefetch file does not mean process hollowing occurred. However, a missing process executable along with suspicious file access during application start-up and an indication a system was compromised means something completely else.