Tuesday, August 17, 2010
*** Note ***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. ;)
*** Note ***
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.
Review the Open Ports and Network ConnectionsThe 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 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 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|
|Figure 4 Infected 2 Aaclientt.exe Process|
|Figure 5 Infected 2 Aaclientt.exe Open Files|
|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|
|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 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|
|Figure 12 Mandiant's AuditViewer Search Feature|
|Figure 13 Infected 1 Internet Explorer Unfamiliar DLLs|
|Figure 14 Infected 2 75622830.exe Strings|
|Figure 15 Infected 2 75622830.exe Strings|
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.
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