Journey Into Incident Response

This post is about the brief examination I recently performed on an infected system. I received permission from the person I assisted to write this post because I thought the content could be helpful to others. This post is broken up into two parts and will contain the majority the steps and research I conducted.

A couple of Sundays ago I was working on a draft of the first post for my next series which will be discussing the overall forensic investigation process. This was when I received a text from a friend asking for help. Basically, a security program was blocking him from starting any program and when his computer was idle porn websites would appear. This security program just seemed to appear out of nowhere. I recommended he power off his computer since he is probably infected with a Fake Antivirus Trojan and I would take a look at the computer over the following weekend. This is the system under examination.

Background Information
My friend just asked for help cleaning his system but I also wanted to determine what the root cause of the infection was. This information could help my friend and his family from being re-infected because they could take steps to help protect their computer in the future.

Here is the background information about this request for assistance. My friend noticed the rogue security software on the evening of Sunday September 12. When I asked my friend what occurred on the computer around this time, he mentioned he was surfing the web including checking his email and going to Facebook. The system was powered off on Sunday 09/12/2010 between 08:00PM and 9:00PM.

During the following week I noticed my friend wasn’t the only person infected over the weekend with rogue security software. On 09/15/2010, I was speaking with two of my co-workers who both knew about someone being infected on Sunday as well. In addition to this, the 09/13/2010 McAfee Avert Labs blog had a post stating over the previous few days there was an increase of submissions from of customers with a variant FakeAlert-SpyPro.gen.ai. There is no way for me to know if these events were related but I thought it was some coincidence.

I acquired an image my friend’s system then I loaded the image into Encase v6.17. All of the files were hashed and a file signature analysis was run against the files. I created a timeline of the system using the log2timeline program in the Sift v2 workstation. I selected the following items to be included in the timeline because it appeared like the infection came from the Internet: file system, prefetch files, recent files, UserAssist key (for three user accounts), index.dat files (for three user accounts), event logs, and registry files (Software, System, and Ntuser.dats). The first timeline I created I overlooked the index.dat file in the PrivacIE folder in one of the  user’s profile. The entries in this index.dat file is from third party content providers on websites a user has  visited. I noticed the missing index.dat because I parse the Internet artifacts with another tool by selecting the entire user’s profile folder  in order to have quick access to the Internet usage information. I noticed right away the missing PivacIE URL entries in the timeline so I generated another timeline with this index.dat included.

The examination will start by locating the rogue security software then the activity on the system will be reviewed with the focus on the time when the Trojan appeared on the system in order to determine where it came from.

Examination of the Auto-start Locations
I was only provided with the hard drive from the system so I didn’t have access to any volatile data which could have helped me determine what program my friend saw running. One of the purposes of rogue security software is to convince a person to part ways with their hard earned money. To accomplish this, the program has to run shortly after a person accesses their computer by either launching when the computer starts up or when the user logs on. The first examination step I performed was to review the system auto-start locations in order to gain a lead I could use to know where my investigation should start. The Sysinternals autoruns utility was run against the hard drive so the programs automatically starting could be reviewed.

I reviewed all of the tabs in the autoruns utility but I only found suspicious programs under the Logon tab. The first suspicious program is shown in the image below.

This program caught my attention for two reasons. The first being the path to the executable because the program is located in the user’s local settings folder. The second reason was due to the naming convention used; the program’s name was hcdrsjbuqiw while the parent folder’s name was bfuqvjmoj. The same two reasons drew my attention to the next suspicious program which is shown below.

There were about four other programs on the Logon tab I marked for closer inspection since I was unsure about them. One of these files was named egugehudafu.dll and is shown below.

Examination of the Files of Interest
The examination of the auto-start locations step provided a few leads about the rogue security software on the system. These leads were two suspicious files and about four other unknown files. The files were examined on the forensic image to determine if they were malicious, and if so to review the files’ metadata for additional information.

VirusTotal (VT) was used to help determine if a file was malicious. At first, I tried to identify the file by searching for the file’s hash in VT but if the hash wasn’t present then I uploaded the file to VT once I confirmed the file was an executable. I understood the risk of uploading the file as a last resort but I would have missed one piece of malware by solely relying on the hash as you will see. The following was discovered about the identified files:

hcdrsjbuqiw.exe
* File path: \Documents and Settings\******\Local Settings\Application Data\bfuqvjmoj\ hcdrsjbuqiw.exe
* VT result: malicious and hash search identified the file as SpyPro
* MD5 hash: ce5806f3f3a2afa8efe0272440ae6b2d
* Creation date: 09/12/10 06:39:04PM
* Last written date: 09/12/10 06:38:51PM
* MFT last modification date: 09/12/10 06:59:06PM

hdwhvqmuqiw.exe
* File path: \Documents and Settings\*****\Application Data\oexrvilnf\hdwhvqmuqiw.exe
* VT result: malicious and hash search identified the file as SpyPro
* MD5 hash: ce5806f3f3a2afa8efe0272440ae6b2d
* Creation date: 09/12/10 06:38:58PM
* Last written date: 09/12/10 06:38:42PM
* MFT last modification date: 09/12/10 07:02:52PM

egugehudafu.dll
* File path: \WINDOWS\egugehudafu.dll
* VT result: hash 30fd84f3c0e0dc7666658dc52c216a2a wasn’t in the VT database but the MFT timestamp was in close proximity to the previous files’ creation dates. I had to confirm if the file was malicious so the file was uploaded to VT, confirmed as malicious, and identified as Hiloti.
* MD5 hash: 30fd84f3c0e0dc7666658dc52c216a2a
* Creation date: 08/16/05 06:18:42AM (note: this file’s timestamp was modified)
* Last written date: 04/13/08 08:12:08PM
* MFT last modification date: 09/12/10 06:40:40PM

The other unknown files identified in the auto-start locations step were examined but didn’t get identified as being malicious. However, I already located two unique pieces of malware which were the SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) located in two places and Hiloti (MD5 30fd84f3c0e0dc7666658dc52c216a2a) located in the Windows directory. McAfee’s detection of SpyPro program in the VT report was FakeAlert-SpyPro.gen.ai, which is the same name mentioned in blog post I referenced earlier. Furthermore, McAfee’s description write-up on FakeAlert-SpyPro.gen.ai showed the discovery date being on 09/12/2010.

As I was browsing the folder locations containing the above programs a folder and four executables caught my attention. The folder had the same name as oexrvilnf while the executables were out of place since they were located in the root of the user’s application data folder as can be seen below.
All of the files were reviewed and the following was discovered:

176572328.exe
* File path: \Documents and Settings\*****\Local Settings\Application Data\176572328.exe
* VT result: malicious and hash search identified the file as Hiloti
* MD5 hash: 5170e6923859a70ede3b2685ccd5ba04
* Creation date: 09/12/10 06:38:42PM
* Last written date: 09/12/10 06:38:42PM
* MFT last modification date: 09/12/10 06:39:04PM

176572329.exe
* File path: \Documents and Settings\*****\Local Settings\Application Data\176572329.exe
* VT result: malicious and hash search identified the file as SpyPro
* MD5 hash: ce5806f3f3a2afa8efe0272440ae6b2d
* Creation date: 09/12/10 06:38:42PM
* Last written date: 09/12/10 06:38:42PM
* MFT last modification date: 09/12/10 06:38:42PM

176581812.exe
* File path: \Documents and Settings\*****\Local Settings\Application Data\176581812.exe
* VT result: malicious and hash search identified the file as Hiloti
* MD5 hash: 5170e6923859a70ede3b2685ccd5ba04
* Creation date: 09/12/10 06:38:51PM
* Last written date: 09/12/10 06:38:51PM
* MFT last modification date: 09/12/10 06:38:51PM

176581813.exe
* File path: \Documents and Settings\*****\Local Settings\Application Data\176581813.exe
* VT result: malicious and hash search identified the file as SpyPro
* MD5 hash: ce5806f3f3a2afa8efe0272440ae6b2d
* Creation date: 09/12/10 06:38:51PM
* Last written date: 09/12/10 06:38:51PM
* MFT last modification date : 09/12/10 06:38:51PM

hdwhvqmuqiw.exe
* File path: \Documents and Settings\*****\Local Settings\Application Data\oexrvilnf\hdwhvqmuqiw.exe
* VT result: malicious and hash search identified the file as SpyPro
* MD5 hash: ce5806f3f3a2afa8efe0272440ae6b2d
* Creation date: 09/12/10 06:38:58PM
* Last written date: 09/12/10 06:38:42PM
* MFT last modification date: 09/12/10 06:38:42PM

Needless to say at this point in the examination it was confirmed that the system was pretty infected. I was able to identify the rogue security software (SpyPro) my friend saw running on his computer and a few programs lurking beneath the surface.  There were five copies of the SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d), two copies of Hiloti (MD5 5170e6923859a70ede3b2685ccd5ba04), and one copy of Hiloti (MD5 30fd84f3c0e0dc7666658dc52c216a2a). The earliest that any malware appeared on the system was at 09/12/10 06:38:42PM and the latest was 09/12/10 06:40:40PM, which means all of this activity occurred within a two minute time period.

The first part of this examination confirmed my friend’s computer was infected but the answer of what occurred on the system for the malware to appear is still not answered. Did my friend use one of McAfee’s suggested distribution channels such as using peer-to-peer networks, email, or newsgroups? I admit I ruined the suspense with a few hints in this post but finding the answer is still an interesting journey.

Stay tuned for the second part of this post when the examination will try to answer the question of how the malware ended up on the system.

The examination of the Infected 2 system didn't complete one of the initial examination steps which was examining the executables of interest. I wanted to explain how I didn't completely answer the question of how the system became infected because this step wasn't completed.

The picture below shows the evidence located from the examination and I concluded the malware identified in memory was the related to the website hosting a malicious PDF, which answered to a certain extent both of my questions 1) is the system infected and 2) how did the system become infected.


I have incorporated Dr. Peter Stephenson's End to End Digital Investigation (EEDI) framework into my investigation process. I will be explaining how I have been using EEDI in my next few posts but for this post I wanted to discuss one of the activities, which is the chain of evidence construction. The evidence located throughout the examination is correlated into a chain of evidence. "The term chain of evidence refers to the chain of events related in some consistent way that describes the incident" (Stephenson, 2009). The description of the incident could explain what happened including how the incident occurred. Each piece of evidence (event) in the chain should link to the next piece of evidence, and when the link does not exist then it should be able to be explained.

The importance of creating the chain of evidence is that the chain can be used to test your theories and/or conclusions. A theory can be tested against the evidence in the chain to see if the theory is based on fact instead of an assumption. Also, this testing can help highlight links between evidence that may require additional collaboration in order to support how the evidence ties together.

To explain how the chain of evidence can be used to test a theory I will use a scenario that every parent will encounter at some point. You walk into a room where your child is and see a disaster. One of the first questions you ask is what happened. The answer you may encounter is probably similar to some of the answers my teenager and toddler say to me when I ask them a question about some disaster. The answer will have some truth to it but will not completely answer the question because it doesn't explain how all of the evidence in the room fits together. Let’s say a window is broken and in the corner of the room is a baseball. Naturally, you ask what happened and the answer given is the window just broke. This starts the “question and answer process” of pointing out how all of the evidence in the room does not link together. The purpose of the questions is to get additional information that helps support your theory of what happened. You may point out the baseball in the corner of the room, the baseball bat in your front yard, or how all of the kids who were playing outside suddenly disappeared. Your goal is to get the answer which explains how all of the evidence links into a chain thereby describing how the disaster occurred.

Now back to why the question (how the Infected 2 system became infected) was not completely answered. Last spring, I based my conclusion that the system became infected as a result of the administrator account visiting a malicious website on the various pieces of evidence. This evidence included: the malware existing in the administrator account's temporary folder, the activity on the system only involved Internet usage, the malicious PDF was downloaded from a website, malware appeared on the system within one second of the malicious PDF appearing on the system, and the malicious PDF targeted a vulnerability that was present on the system.

However, reviewing the evidence in the picture shows there are a few unanswered questions about how the system became infected because not all of the evidence is linked together (or I haven't explained how I think the evidence links together). For example, the examination did not explain where all of the malware came from. The payload of the malicious PDF made calls to additional URLs and does not directly show a call to download any malware.

When my conclusion is tested against the evidence in the picture this test highlights the evidence which is not linked to the next piece of evidence. Take for example the first piece of malware on the system which was ~TM4.tmp. The evidence does not show directly where this malware came from so I cannot be certain this malware was the payload of the malicious PDF or came from the hxxp://googlecounter.cn website. The link between ~TM4.tmp, googlecounter.cn, and the malicious PDF needs additional collaboration. The examination step of examining executables of interest could help explain how the malware fits into the chain of evidence.

The brief examination I am going to describe is for illustration purposes only and by no means am I suggesting this is how executables should be analyzed. I didn't complete this activity last spring but I wanted to show how this step could provide additional information to help answer your questions.

The ~TM4.tmp's Virus Total report was reviewed in order to locate a detection that could be used for further analysis. I decied to use Microsoft's detection of TrojanDownloader:Win32/Bredolab.X. Microsoft’s Malware Protection Center states this malware connects to a remote server to download and execute additional files.

The installation information section on the webpage states the malware “is installed to the Startup folder using a variable file name. It injects itself in the 'svchost.exe' and 'explorer.exe' processes”. The examination of the Infected 2 system located a copy of the ~TM4.tmp file (mgjwin32.exe) in the Startup folder while the examination of the strings shows the explorer.exe and svchost.exe processes made references to the mgjwin32.exe program located in the Startup folder (this isn't reflected in my earlier post). This is useful information that could help explain how the other pieces of malware ended up on the system. However, this information doesn't explain how ~TM4.tmp ended up on the system, which is the link we are trying to establish.

Continuing with the examination of the ~TM4.tmp file, a Google search of the file's MD5 hash was performed. The search result only had one hit and this was an entry in the Malc0de database which is shown below.
 
     * date of entry was 2010-04-08
     * domain was googlecounter.cn/web/load.php
     * IP address was 109.196.143.33
     * Autonomous System Name was VLTELECOM-AS VLineTelecom LLC  
        Moscow, Russia
     * file's MD5 hash is e40b4170d3f9252a4339bb2c2d0db7f2
 
The Malc0de database entry was on 04-08-2010 which was one day after the system was infected and the domain involved was the same one the Administrator user account visited (hxxp://googlecounter.cn). I think the most significant piece of information is that the domain listed (googlecounter.cn/web/load.php) is the same domain in the URL requests in the malicious PDF. This additional collaborating evidence establishes the link between the first piece of malware on the system, malicious PDF, and the suspected website; thereby completing this portion of the chain of evidence. The examination of the executables of interest would continue with the remaining malware in order to complete the chain of evidence.
 
Infected 2 System Examination Conclusion
 
The examination of the Infected 2 system did not completely link all of the evidence together. (Eventually, I want to be able to completely link all of the evidence together) Despite this, the examination was able to answer both of my initial questions to a certain extent. These questions were is the system infected and how did the system become infected. Memory analysis was able to locate suspicious files while uploading those files to Virus Total confirmed them as being malicious. The remaining examination steps combined with timeline analysis was able to determine the system was infected by visiting a website hosting a malicious PDF.
 
The examination was performed on a test system so I didn't have to determine what made the administrator user account access the malicious website. Something would have to deliver the website's URL to the administrator and this delivery mechanism could have been a link in an email, link in instant messaging, or a browser redirect from a compromised website. I think this would have been my next step in answering the question how did the system become infected. This line of thinking is what spawned my next area to explore which will be trying to gain a better understanding of the common attack vectors.
 
 
References
Stephenson, P. (2009). Cyber Investigation. In S. Bosworth, M. Kabay, & E. Whyne, Computer Security Handbook (pp. 55.1 - 55.27). Hoboken: John Wiley & Sons, Inc.

My previous post explained why I incorporated timeline analysis into the examination of the Infected 2 system.

I created a supertimeline to help answer the second question of how did the system become infected. My examination of the timeline focused on the creation and last modified dates in order to simulate a real security incident because the last access times may not be accurate depending on the time that elapsed between the initial infection and the examination. (I doubt I will be able to preserve a system at the exact moment of infection similar to the tests I conducted). In addition to the timeline, I used Guidance Software's Encase to hash and perform a file analysis on all of the files on the system in advanced of examining them. I also used Encase to examine any files identified in the timeline.

How the system became infected?

The examination of volatile data identified the following in the Infected 2 system: rogue aaclientt.exe process, 612835656.dat opened by aaclientt.exe, svchost process with an injected DLL, and a rogue 75622830.exe process. I examined the timestamps of aaclientt.exe and 75622830.exe files in order to get a starting point to begin the timeline review. The picture below shows the timestamps for aaclientt.exe.

The arrows in the picture are highlighting a time discrepancy between the Standard Information Attribute (SIA) date creation time and the Filename Attribute (FNA) date modification time. This is an indication the timestamps could have been changed on the aaclientt.exe program. I used Lance Muller's enscript to compare the two timestamps as can be seen below.

The timeline shows on line 163833 the 75622830 folder was created at the same time as the 75622830.exe file. Continuing to work backwards, the next file created on the system is named 612835656.dat, which occurred at 03:20:13PM (line 163831). The memory examination identified that the aaclientt.exe process had this file opened. 612835656.dat was examined on the system but the contents only showed a few characters.

The next few lines (163831 to 163828) show a few registry entries being modified. The HKLM\System\ControlSet001\Services\TapiSrvALG was examined and the value name display name contained the data Telephony TapiSrvALG while the imagepath value name contained the data C:\WINDOWS\system32\aaclientt.exe srv. This service seems very similar to the Telephony service which contains the data Telephony in the display name value name. This registry key is the persistence mechanism for aaclientt.exe which starts the program as a service. Line 163827 shows a prefetch file being created at 03:20:08PM for a program named _ex-68.exe. The analysis of the system did not locate a file by this name. Another prefetch file, for wpv901264679855.exe, was modified and last accessed at 03:19:59PM (line 163824). The last line I will discuss in this picture is the creation of aaclientt.exe's prefetch file at 03:19:57PM which is shown on line 162822. At this point in the examination, aaclientt.exe's persistence mechanism was identified and there is evidence of various programs being executed on the system in addition to the aaclientt.exe and 75622830.exe programs.

The picture below is the next section of the timeline.

Lines 163821 to 163817 show evidence of more programs being executed on the system but the wpv901264679855.exe prefetch file (line 163820) is the same one mentioned from line 163824. Think back to the time discrepancy involving aaclientt.exe which indicated the timestamps may have been modified. Line 163813 shows the MFT modification of 03:19:48PM for the file aaclientt.exe and this was the real time the file was created on the system. The MFT modification time can still reveal files of interest even if the files' timestamps have been stomped on. At this point in the examination, additional programs that executed on the system have been identified and the aaclientt.exe program, which was identified in the memory image, was located.

The picture below is the continuation of the timeline.

Line 163811 shows the first unknown program, wpv901264679855.exe, was created on the system at 03:19:44PM. Wpv901264679855.exe's prefetch file was referenced on lines 163820 and 163824. This file was uploaded to Virus Total and the detection rate on 04/10/10 was 38 percent. Line 163808 shows the next unknown program, wpv791264677196.exe, was created on the system at 03:19:44PM. The examination of this file revealed it had the same hash as aaclientt.exe, which means wpv791264677196.exe and aaclientt.exe are the same file. Line 163807 shows another unknown program, wpv351269312857.exe, was also created on the system at 03:19:44PM. This file was uploaded to Virus Total and the detection rate on 04/10/10 was 25 percent. Line 163806 shows a log file was created on the system but the examination of this file determined the file's signature was invalid and the contents were only a few characters. Line 163804 shows aaclientt.exe was last accessed at 03:19:35 while line 163803 shows another unknown program, e.exe, executed on the system one second earlier (the examination did not find any files by this name on the system). Line 163802 shows the Administrator user account's Startup folder was modified at 03:19:34PM. The examination of the Startup folder identified a program named mgjwin32.exe. This file had a discrepancy between the SIA date creation time and the FNA date modification time. Similar to the aaclientt.exe program, mgjwin32.exe's timestamps were modified so the creation date appeared to be 08/04/04 08:00:00AM. The timestamp comparison showed the real creation date of the mgjwin32.exe file was 03:19:34PM. Lastly, this file had the same hash as the file ~TM4.tmp which is on line 163801. The file's extension indicates it is a temporary file but the file signature analysis determined the file is an executable. ~TM4.tmp was uploaded to Virus Total and the detection rate on 04/20/10 was 70 percent.

At this point in the examination, three of the unknown programs (wpv901264679855.exe, wpv791264677196.exe, and wpv351269312857.exe) that were executed on the system were located and confirmed as malicious. Also, wpv901264679855.exe and aaclientt.exe are the same file. Mgjwin32.exe was another program identified as malicious and this program's persistence mechanism is the Administrator user account's Startup folder. The ~TM4.tmp file is an executable and is the same file as mgjwin32.exe.

The picture below is the continuation of the timeline.

So far the examination has identified various pieces of malware on the system but these files do not directly relate to the question of how the system became infected. At 03:19:32 there was a MFT modification for a PDF file, gla[1].pdf, located in the Administrator user account's Temporary Internet Files folder (line 163800). I used Didier Stevens PDF tools to analyze this file but for this post I am using a link to Virus Total since the website uses his tools. The gla[1].pdf Virus Total report showed the detection rate on 04/10/10 was 25 percent and a Javascript is executed when the file is opened (refer to the picture below).

The gla[1].pdf file was uploaded to Wepawet to help determine if the file was malicious. The gla[1].pdf Wepawet report confirmed the file was malicious. The report identified the two vulnerabilities being targeted were CVE-2008-2992 and CVE-2009-0927, and the payload requested three websites involving hxxp://googlecounter.cn/web/load.php?id=. The next line, 163799, in the timeline shows the file gla[1].pdf was downloaded to the system from the hxxp://googlecounter.cn website. The image below shows the administrator account was used to access this website at 03:18:08 (line 163783).

I infected this test system back in April by visiting a malicious website using the Administrator user account. I obtained the website from the Contagio post March's malware links. I knew ahead of time about the malicious PDF since it was indicated next to the URL but I didn't know what the outcome was going to be when I visited the website. The examination of the Infected 2 system's volatile data and hard drive helped me understand what this outcome was.

Conclusion

The files located in memory were used as the starting point to examine the activity on the system. The examination worked backwards in time and the image below shows all of the evidence located during the examination. Not only does the image show all of the evidence identified but it also shows the activity after the 75622830.exe file was created on the system. (Note: 75622830.exe uses HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run as its persistence mechanism)

The examination of Infected 2 covered all of the initial examination steps except one which was the examination of the executable files of interest. The next blog post will examine the importance of this step and why it may be needed to fully answer the question of how the system became infected.