Journey Into Incident Response

The next two blog posts will be answering two questions: 1) is the system infected and 2) how did the system become infected. I prefer to include all of the information at once instead of highlighting a few areas. Therefore, both posts will be long. I promise to try to avoid making this a habit unless if there is good feedback. ;)


My previous post provided a little background information about the images I am referencing. One of the earlier steps to identify an infection would be to search for known malicious code by scanning the computer or image of the computer with various anti-virus products. However, I wanted to find the infection by examining the system’s volatile data so I wouldn’t have to be solely dependent on anti-virus products. I thought about the time a test system was accidently infected with Trojan and the anti-virus product did not have a signature for it. Volatile data examination helped me locate the malware even though my anti-virus was ineffective. Plus I wanted to learn how to examine volatile data, which is also one of the earlier steps.

The books listed in my references section outline a methodology to collect volatile data and some of the tools that can be used. One of the first steps during the collection of volatile data is to acquire an image of the memory before any additional tools are run on the live system to collect additional information. I started off examining only the memory image since this is the first item collected. To date, I have found limited information on the process to use to examine a memory image but there is plenty of documentation about examining volatile data on a live system. I figured I would just use the steps of examining volatile data against the memory image. The following are the examination steps (again the books do an outstanding job of explaining these steps in detail):

     * Review the open ports and network connections
     * Review the running processes
     * Review the system hooks
     * Review the loaded dynamic-link libraries (DLLs)
     * Review the open files
     * Review the loaded drivers
     * Review the strings associated with a process or driver of interest.

Basically, the examination is looking for what does not belong. Unusual ports, processes, files, DLLs, and filenames. I found having a baseline system to reference was useful for some of the steps, such as the steps for reviewing the DLLs and drivers. The tools I used for the collection and examination was Mandiant’s Memoryze and AuditViewer. If you want to read a few blog posts on how to use these tools check out The Digital Standard here then here then here.


The review of the open ports and network connections involve looking for unusual or unfamiliar Internet Protocol addresses or ports as well as taking into consideration the processes involved.
 
The picture below displays a section of the port’s section for Infected 1.

Figure 1 Infected 1 Ports and Network Connections

The activity in the image looks pretty normal with one open port on 135 for Microsoft's RPC and Internet Explorer connecting to the default HTTP port (80) on a remote system. The activity may look pretty normal but Internet Explorer was not visible on the system when the memory image was acquired. This was the first red flag in Infected 1 that needs to be examined further.
 
The second image referenced in this post (Infected 2) appeared to be infected with rogue security software which prevented any new processes from running. This rogue software prevented the memory imaging software from executing so to bypass the rogue software the memory was imaged as soon as the user logged on. This enabled Memoryze to execute before the rogue security software but Memoryze also executed before the network services fully loaded. This resulted in the memory image not containing any information related to network connections or open ports.
 
 
Review the Running Processes
The review of the running processes involve looking for which ones do not belong. For each process the following is some of the information that should be reviewed: process’s executable path, command argument to launch the process, the security context of the process, and the enumerated handle information such as the open files and registry keys.
 
For Infected 1, the review of the open ports and network connections showed an unusual network connection involving Internet Explorer. This will be the first process examined as illustrated below.

Figure 2 Infected 1 Internet Explorer Process

The command argument shows the Internet Explorer executable path is correct but the argument used to launch Internet Explorer included an URL in order which makes Internet Explorer connect to the website when it launches. The last bit of information from the picture shows that Internet Explorer is running in the context of the local administrator account (Security ID ending in 500).
 
The review of the rest of the running processes in Infected 1 identified another questionable process, which is shown in Figure 3. Asr64_ldm.exe is questionable because the program was launched from a temporary folder, which is not a standard location for programs to be run from. This process is also running in the context of the local administrator account similar to the Internet Explorer process.

Figure 3 Infected 1 Asr64_ldm.exe Process

The review of the processes in Infected 2 identified three unusual processes. The first process is illustrated in Figure 4. The svchost.exe process is highlighted in red because the process has an injected DLL, and the rating next to the process was done by the MRI feature. Despite this process being highlighted by Auditviewer, the other characteristic that makes it unusual is the command argument launched a program called aaclienttt.exe instead of svchost.exe. This action is trying to hide the presence of aaclientt.exe by running the program under a different name. If someone were to use the task manager to inspect this process they would only see the name svchost.exe listed in the processes tab.

Figure 4 Infected 2 Aaclientt.exe Process

The review of the open file handles for aaclientt.exe shows the process has a few files open including a .dat file. This is shown below.

Figure 5 Infected 2 Aaclientt.exe Open Files

The second unusual process in Infected 2 is another svchost.exe process. This process also had an injected DLL and a MRI rating. The characteristic of this process making it unusual is the lack of switches in the command argument used to launch the svchost.exe program. The other svchost.exe processes' command arguments use a switches as illustrated in Figure 6.

Figure 6 Infected 2 Svchost.exe Process

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
The last unusual process in Infected 2 is shown in Figure 7. Similar to Figure 3, the unusual characteristic about this program is the path it was started from, which was the applications folder in the All Users profile.

Figure 7 Infected 2 75622830.exe Process

The enumerated handles for this process, 75622830.exe, also revealed something interesting. The task manager was a process as shown in Figure 8. As mentioned previously, Infected 2 was obtained from a system that appeared to be infected with a rogue security application that prevented any new programs from running. Not only did the rogue security application prevent the memory imaging software from running, but at the time of imaging the application also prevented the task manager from starting. The process 75622830.exe appears to be the rogue security application since the task manager is listed as a child process.

Figure 8 Infected 2 75622830.exe with Task Manager Child Process

 
 
Review the System Hooks
I thought a brief definition of system hooking would be helpful before I explain this step. The Wikipedia webpage defines hooking as a range of techniques used to alter or augment the behavior of an operating system or other software components by intercepting function calls, messages or events passed between software components. There are several methods and techniques for hooking, and I found the Hacking Exposed Malware & Rootkit book provided a good explanation of the different types of hooking. Also, openrce.org has a good article about a malware sample that uses hooking.
 
Similar to the previous steps, the review of the hooking involves looking for what doesn’t belong. The picture below shows the System Service Descriptor Table Hooks for the Infected 1 image. The picture shows that two functions are being hooked but the name of the hooking module isn’t displayed. I still have to follow up on what would prevent a name from not displaying in this area.

Figure 9 Infected 1 SSDT Hooks

The first function being hooked is NtEnumeratekey. This function returns information about a subkey of an open registry key. Hooking this function enables the information to be filtered, and this could be used to hide the presence of something in the registry. The second function being hooked is NtFlushinstructioncache. This function appears to be undocumented and it empties the execution cache for specified region of code. I came across an interesting analysis describing this function, which allows a driver to execute additional commands such as hide an injected DLL, obtain list of running processes, and to terminate a current process. (note: this analysis was released in August so I did not have access to this information when I first examined this system but I wanted to include the information)
 
The Infected 2 image did not have any hooks in the three hooking techniques displayed by AuditViewer.
 
 
Review the Loaded Dynamic-Link Libraries
Another definition before I explain this step. Microsoft’s MSDN defines a DLL as an executable file that acts as a shared library of functions, which provides a way for a process to call a function that is not part of its executable code. The review of the loaded DLLs is to determine if any are rogue. This was one of the steps I thought was helpful to compare the infected memory images to a memory image from a known good system. There are a lot of DLLs loaded on a system and I found it hard to determine which ones actually belonged on the system. If I do eventually become a cyber investigator then I will be keeping this tip in mind because I would want a baseline of all of the standard configurations for the computers on the network.
 
I was unable to locate the DLLs that were present in the Infected 1 image during this step but I was able to find them once I completed the review of the strings step. As for the Infected 2 image, there was no rogue DLLs.
 
 
Review the Open Files
The review of the open files on the system can not only show unauthorized files on the system but the review can also show what files a user and/or process was accessing at the time of the memory image. I reviewed the open files in both images but I wasn’t able to identify anything else in addition to what I found using the other examination steps. Plus there wasn’t much time available for additional files to be opened because once the system became infected it was disconnected from the network and imaged.
 
 
Review the Loaded Drivers
The review of the drivers involve looking for unusual or unfamiliar drivers. The review of the memory images found that Infected 2 did not have any unfamiliar drivers while Infected 1 did. If you remember Infected 1 was also the image that had hooked functions (refer to Figure 9). The picture below shows the driver in question, which is the _VOIDd.sys driver. This driver appeared in the list of drivers where the memory image was scanned for driver objects but didn’t appear in the list of drivers from traversing the PsLoadedModuleList. The AuditViewer documentation explains the significance of this but basically the driver is hiding from the operating system because the PsLoadedModuleList contains the list of drivers the operating system can see.

Figure 10 Infected 1 Loaded Drivers

 
 
Review the Strings Associated with a Process or Driver of Interest
Finally we are at the last step, which is to review the strings associated with a process or driver of interest. The strings of the _VOIDd.sys driver found in Infected 1 were examined. The picture below shows an unfamiliar DLL that has a similar name as the driver.

Figure 11 Infected 1 _VOIDd.sys Driver Strings

At this point I decided to try to search the memory image for DLLs starting with the name of “_void”. Using the search feature in AuditViewer (shown below) I searched all of the DLLs on the system and there were about five processes that had a loaded DLL with name starting with _void.

Figure 12 Mandiant's AuditViewer Search Feature

Infected 1 had the instance of Internet Explorer connecting to a remote host so I reviewed the search hits for Internet explorer. There were two unfamiliar DLLs and neither of them was the DLL first found in the driver strings.

Figure 13 Infected 1 Internet Explorer Unfamiliar DLLs

The strings of the 75622830.exe process found in Infected 2 were also examined. The first interesting set of strings is shown in the picture below since this was the error message that appeared when the task manger was blocked from running.

Figure 14 Infected 2 75622830.exe Strings

The next string of interest is probably what would have appeared if I selected the option to remove all of the infections.

Figure 15 Infected 2 75622830.exe Strings

 
 
Conclusion
The examination of the memory images from the infected systems provided me with a few files to examine first. The Infected 1 image had the following: suspicious Internet Explorer process, rogue asr_64_ldm.exe process, hooked functions, rogue _VOIDd.sys driver, and rogue DLLs with name starting with _void. The Infected 2 image had the following: rogue aaclientt.exe process, one file of interest opened by aaclientt.exe, svchost process with an injected DLL, and rogue 75622830.exe process.
 
The initial question of is the system infected requires an additional examination step in order to determine if the files are malicious. This step is to confirm if the file is malicious. The files can be acquired directly from memory or the files can be accessed from the hard drive. I opted for the latter option and submitted the files to VirusTotal for scanning. All of the files were confirmed as being malicious with a detection rate less than 20 percent when I uploaded them in the Spring.

The examination of a memory image is one method that can be used to find an infection on a system, and one additional step can be used to confirm the infection. This was the process I used to answer the question of is the system infected. However, I think the examination of memory is just one step out many that is required to examine an infected system. I am interested in how others approach examining a memory image to locate an infection. Are you doing anything different than what I posted?

My next blog post will explain a few more examination steps to answer the question of how the Infected 2 system became infected. *Hint* I visited a malicious website listed in Contagiodump's March links.



References
Aquilina, J. M., Casey, E., & Malin, C. H. (2008). Malware Forensics Investigating and Analyzing Malicious Code. Burlington: Syngress Publishing, Inc.

Carvey, H. (2009). Windows Forensic Analysis. Burlington: Syngress Publishing, Inc.

Hidden Registry Detection. (2009). Retrieved August 16, 2010, from Rootkit Analytics: http://www.rootkitanalytics.com/userland/Hidden-Registry-Detection.php

Malware links March 2010 . (2010, March 29). Retrieved April 06, 2010, from contagiodump.blogspot.com: http://contagiodump.blogspot.com/2010/03/malware-links-march-2010.html

Mandia, K., Prosise, C., & Pepe, M. (2003). Incident Response & Computer Forensics. Emeryville: McGraw-Hill/Osborne.

NtEnumerateKey. (2010). Retrieved August 16, 2010, from msdn.microsoft.com: http://msdn.microsoft.com/en-us/library/ff556510(v=VS.85).aspx

NtFlushInstructionCache. (2001). Retrieved August 16, 2010, from undocumented.ntinternals.net: http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Process/NtFlushInstructionCache.html