Journey Into Incident Response

The purpose to performing root cause analysis is to find the cause of a problem. Knowing a problem’s origin makes it easier to take steps to either resolve the problem or lessen the impact the next time the problem happens again. Root cause analysis can be conducted on a number of issues; one happens to be malware infections. Finding the cause of an infection will reveal what security controls broke down that let the malware infect the computer in the first place. In this post I’m expanding on my Compromise Root Cause Analysis Model by showing how a malware infection can be modeled using it.

Compromise Root Cause Analysis Revisited

The Compromise Root Cause Analysis Model is a way to organize information and artifacts to make it easier to answer questions about a compromise. The attack artifacts left on a network and/or computer fall into one of these categories: source, delivery mechanism, exploit, payload, and indicators. The relationship between the categories is shown in the image below.


I’m only providing a brief summary about the model but for more detailed information see the post Compromise Root Cause Analysis Model. At the model’s core is the source of the attack; this is where the attack came from. The delivery mechanisms are for the artifacts associated with the exploit and payload being sent to the target. Lastly, the indicators category is for the post compromise activity artifacts. The only thing that needs to be done to use the model during an examination is to organize any relevant artifacts into these categories. I typically categorized every artifact I discover as an indicator until additional information makes me move them to a different category.

Another Day Another Java Exploit

I completed this examination earlier in the year but I thought it made a great case to demonstrate how to determine a malware infection’s origin by using the Root Cause Analysis Model. The examination was kicked off when someone saw visual indicators on their screen that their computer was infected. My antivirus scan against the powered down computer confirmed there was an infection as shown below.


The antivirus scan flagged four files as being malicious. Two binaries (fuo.exe and 329991.exe) were identified as the threat: Win32:MalOb-GR[Cryp]. One cached webpage (srun[1].htm) was flagged as JS:Agent-PK[Trj] while the ad_track[1].htm file was identified as HTML:RedirME-inf[Trj]. A VirusTotal search on the fuo.exe file’s MD5 hash provided more information about the malware.

I mentally categorized the four files as indicators of the infection until it’s proven otherwise. The next examination step that identified additional artifacts was timeline analysis because it revealed what activity was occurring on the system around the time when malware appeared. A search for the files fuo.exe and 329991.exe brought me to the portion of the timeline shown below.


The timeline showed the fuo.exe file was created on the computer after the 329991.exe file. There were also indications that Java executed; the hsperfdata_username file was modified which is one artifact I highlighted in my Java exploit artifact research. I was looking at the activity on the system before the fuo.exe file appeared which is shown below.


The timeline confirmed Java did in fact execute as can be seen by the modification made to its prefetch file. The file 329991.exe was created on the system at 1/15/2012 16:06:22 which was one second after a jar file appeared in the anon user profile’s temporary folder. This activity resembles exactly how an infection looks when a Java exploit is used to download malware onto a system. However, additional legwork was needed to confirm my theory. Taking one look at the jar_cache8544679787799132517.tmp file in JD-GUI was all that I needed. The picture below highlights three separate areas in the jar file.


The first area labeled as 1 shows a string being built where the temp folder (str1) is added to 329991.exe. The second area labeled as 2 first shows the InputStream function sets the URL to read from while the FileOutputStream function writes the data to a file which happens to be str3. Remember that str3 contains the string 329991.exe located inside the temp folder. The last highlighted area is labeled as 3 which is where the Runtime function starts to run the newly created 329991.exe file. The analysis on the jar file confirmed it was responsible for downloading the first piece of malware onto the system. VirusTotal showed that only 8 out of 43 scanners identified the file as a CVE-2010-0840 Java exploit. (for another write-up about how to examine a Java exploit refer to the post Finding the Initial Infection Vector). At this point I mentally categorized all of the artifacts associated with Java executing and the Java exploit under the exploit category. The new information made me move 329991.exe from the indicator to the payload category since it was the payload of the attack.

I continued working the timeline by looking at the activity on the system before the Java exploit (jar_cache8544679787799132517.tmp) appeared on the system. I noticed there was a PrivacIE entry for a URL ending in ad_track.php. PrivacIE entries are for 3rd party content on websites and this particular URL was interesting because Avast flagged the cached webpage ad_track[1].htm. I started tracking the URLs in an attempt to identify the website that served up the 3rd party content. I didn’t need to identify the website per say since I already reached my examination goal but it was something I personally wanted to know. I gave up looking after spending about 10 minutes working my way through a ton of Internet Explorer entries and temporary Internet files for advertisements.


I answered the “how” question but I wanted to make sure the attack only downloaded the two pieces of malware I already identified. I went back in the timeline to when the fuo.exe file was created on the system. I started looking to see if any other files were created on the system but the only activity I really saw involved the antivirus software installed on the system.

Modeling Artifacts

The examination identified numerous artifacts and information about how the system was compromised. The diagram below shows how the artifacts are organized under the Compromise Root Cause Analysis Model.


As can be seen in the picture above the examination did not confirm all of the information about the attack. However, categorizing the artifacts helped make it possible to answer the question how did the system become infected. It was a patching issue that resulted in an extremely vulnerable Java version running on the system. In the end not only did another person get their computer cleaned but they also learned about the importance of installing updates on their computer.


Usual Disclaimer: I received permission from the person I assisted to discuss this case publicly.

There are different ways to spread malware. Email, instant messaging, removable media, or websites are just a few options leveraged to infect systems. One challenge when performing an examination is determining how the malware ended up on the system which is also referred to as identifying the malware’s initial infection vector (IIV). A few obstacles in determining the IIV is that a system changes over time: files are deleted, programs are installed, temporary folders are emptied, browser history is cleared, or an antivirus program cleaned the system. Every one of those obstacles may hinder the examination. However, they don’t necessary result in not being able to narrow down the IIV since some artifacts may still be present on the system pointing to the how.

There are various reasons provided why an examination isn’t performed on a malware infected system to locate the IIV. I first wanted to point out why taking the time to find the IIV is beneficial instead of focusing on the reasons why people don’t. The purpose of the root cause analysis is to identify the factors lead up to the infection and what actions need to be changed to prevent the reoccurrence of a similar incident. If the infected system is just cleaned and put back into production then how can security controls be adjusted or implemented to reduce malware infecting systems in a similar manner? Let’s see how this works by skipping the root cause analysis and placing blame on a user opening a SPAM email. A new security awareness initiative educates employees on not opening SPAM email which does very little if the malware was a result of a break down in the patch management process. Skipping figuring out the IIV is not only a lost opportunity for security improvements but it prevents knowing when the infection first occurred and what data may have been exposed. This applies to both organizations and individuals.

Determining how the malware infected a system is a challenge but that's not a good enough reason to not try. It may be easier to say it can’t be done, takes too much resources or it's not worth it since someone (aka users) never listen and did something they weren’t suppose to. As a learning opportunity I’m sharing how I identified the initial infection vector in a recent examination by showing my thought process and tool usage.

First things first… I maintain the utmost confidentiality in any work I perform whether if it’s DFIR or vulnerability assessments. At times on my blog I write detailed posts about actual examinations I performed and every time I’ve requested permission to do so. This post is no different. I was told I can share the information for the greater good since it may help educate others in the DFIR community who are facing malware infected systems.

Background Information

People don’t treat me as their resident “IT guy” to fix their computer issues anymore. They now usually contact me for another reason because they are aware that I’ve been cleaning infected computers for the past year free of charge. So it’s not a strange occurrence when someone contacts me saying their friend/colleague/family member/etc appears to be infected with a virus and needs a little help. That’s pretty much how this examination came about and I wasn’t provided with any other information except for two requests:

        * Tell them how the infection occurred so they can avoid this from happening again

        * Remove the viruses from the computer

     Investigation Plan

The methodology used throughout the examination is documented on the jIIr Methodology Page. I separated the various system examination steps into the first three areas listed below.

        1. Verify the system is infected
        2. Locate all malware present on the system
        3. Identify the IIV
        4. Eradicate the malware and reset any system changes

I organized the areas so each one will build on the previous one. My initial activities were to verify that the system was actually infected as opposed to the requester interpreting a computer issue as an infection. To accomplish this I needed to locate a piece of malware on the system either through antivirus scanning or reviewing the system auto-run locations. If malware was present then the next thing I had to do was locate and document every piece of malware on the computer by: obtaining general information about the system, identifying files created around the time frame malware appeared, and reviewing the programs that executed on the system. The examination would require since the technique excels at highlighting malware on a system. The third area and the focus of this post was to identify the initial infection vector. The IIV is detected by looking at the system activity in the timeline around the timeframe when each piece of malware was dropped onto the system. The activity can reveal if all of the malware is from the same attack or if there were numerous attacks resulting in different malware getting dropped onto the system. The final area is to eradicate every malware identified.

Note: Some activities were conducted in parallel to save time. To make it easier for people to follow my examination I identified each activity with the symbol <Step #>, the commands I ran are in bold, and registry and file paths are italicized.

Verifying the Infection

The computer’s hard drive was connected to my workstation and a software write blocker prevented the drive from being modified. I first reviewed the master boot record (MBR) to see the drive configuration I was dealing with and to check for signs of MBR malware <Step 1>. I ran the Sleuthkit command: mmls.exe -B \\.\PHYSICALDRIVE1 (the -B switch shows the size in bytes). There was nothing odd about the hard drive configuration and I found out that additional time was needed to complete the examination since I was dealing with a 500 GB hard drive. To assist with identifying known malware on the system I fired off a Kaspersky antivirus scan against the drive <Step 2>.

Knowing the antivirus scan was going to take forever to complete I moved on to checking out the system’s auto-runs locations for any signs of infection. The Sysinternals AutoRuns for Windows utility was executed against the Windows folder and the only user profile on the system <Step 3>. In the auto-runs I was looking for unusual paths launching executables, misspelled file names, and unusual folders/files. It wasn’t long before I came across an executable with a random name in the HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell registry key.

The HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key also listed under Auto-runs Logon tab showed that the C:\Users\John_Doe\AppData\Roaming folder had more than just one randomly named executable. The key also showed an additional location which was the C:\Users\John_Doe\AppData\Roaming\Microsoft folder.

I added the hard drive as an evidence item in FTK Imager v3 to review the folders and executables identified by the Auto-runs utility <Step 4>. I noticed there were two additional executables located directly underneath the Roaming folder with the names iexplore.exe and java.exe. Both files had the same MD5 hash e4c2a000e715d16ec25e2b0a0fb3532f so to confirm the infection I searched for the hash in the Malware Analysis Search custom Google search. There was one search hit for VirScan.org and a few scanners flagged the file as malware (Kaspersky identified it as Trojan.Win32.FakeAV.emha). I followed the similar process to confirm that the other executables were malware as well. At this point I no longer needed the antivirus scan to finish since the infection was verified through other means. Before I moved onto manually locating all malware on the system I needed to document what my timeframe of interest was. I looked at the last modification times and creation times for all the folders/files I found. The rough timeframe spanned over a few days: from 10\13\2011 1:29:34 AM to 10/08/11 11:38:48PM. The picture below shows the last modification times for a few folders in the C:\Users\John_Doe\AppData\Roaming folder.


Locating All Malware on the System

After I verified the system was in fact infected I then proceeded to locate and document every piece of malware. First I had to shed light on the system’s configuration since it would impact how I performed my analysis <Step 5>. I used my regripper-general-os-info.bat batch file to run RegRipper against the system’s registry hives including the one profile’s NTUSER.dat hive. Below I highlighted some information and to the right of the arrow are quick notes about its significance.

        * Operating system was Windows 7 Home Premium <= affected what artifacts are available and where they are located

        * OS Install Date was Sun Feb 20 23:26:29 2011 (UTC) <= may assist with identify activity occurring before this date

        * Timezone was Eastern Standard <= needed to understand time information

        * The registry setting NtfsDisableLastAccessUpdate was enabled <= can’t use files’ last access times since it’s not tracked (default setting in Windows 7)

        * Profilelist registry key only showed one user account besides the default ones <= focused the examination around the activity for one specific user account

       * Installer\UserData registry key showed the following programs: Microsoft Office 2010 including Outlook, iTunes v.10, QuickTime v.7.69, Adobe Reader v9.3.4, and Java(TM) 6 Update 17 <= identified applications that could have been responsible for the malware infection

       * Default browser plugin showed the default browser was Internet Explorer <= system had two web browsers (Chrome was the other) so my initial focus is on the artifacts from the default one

       * Listsoft registry key showed McAfee <= McAfee antivirus software was on the system and its logs may show additional information about the infection.

I opted for the timeline analysis technique to locate all malware on the system and the general information obtained about the system helped to narrow down my artifact list to incorporate into my timeline. Building a timeline on a 500 GB hard drive was going to take some time so I looked at the McAfee logs before tying up my workstation <Step 6>. I exported the McAfee logs with FTK Imager and reviewed them using Notepad ++. The last entry in the log occurred at 10/16/2011 6:50:09 PM and it logged that the file "C:\windows\system32\consrv.DLL" was detected as Generic.dx!bbd4. The next entry didn’t occur until 10/12/11 but there were numerous log entries leading right up until 10/08/11. A few detections included Generic Dropper!1cj, DNSChanger!fa, and Artemis!E4C2A000E715 and they were for files located the folders C:\Users\John_Doe\AppData\Local\Temp\, C:\Windows\assembly\tmp\, and C:\windows\syswow64\. The flurry of McAfee detections for files other than cookies stopped at 10/8/2011 11:37:38 PM as shown in the picture below.

The McAfee log identified potential additional malware on the system and expanded my timeframe to 10/16/2011 6:50:09 PM to 10/08/11 11:37:38 PM. A significant piece of information the log highlighted was Internet activity occurred just before the first detection. I leverage the timeline analysis technique for the rest of the examination. I created a timeline by incorporating the following artifacts: event logs (evtx), registry hives (system, software, and ntuser), link files (win_link), prefetch files (prefetch), Internet Explorer history (iehistory), and the Master File Table (mft) <Step 7>. I ran the following command but replaced the plugin and file path for each desired artifact: log2timeline.pl -f evtx -w timeline.csv E:\Windows\System32\winevt\Logs\Application.evtx. Once my timeline was built I then I started my search for all malware on the system.

Identify the IIV

Locating all malware present on the system and identifying the IIV are not separate activities when I perform timeline analysis. The only reason I separated them was to make it easier to explain my thought process. In actuality the two go hand in hand. Each time a piece of malware is located the system activity around the malware is examined to determine what contributed to the malware being created. Approaching timeline analysis in this manner will help determine if the malware is from the one attack or multiple attacks at different points in time. I review timelines working backwards in time since I find that it’s easier to spot the IIV. Each time I come across a file that could be malicious I first review the file’s header (in this examination I used FTK Imager), perform searches for the file’s MD5 hash (search order is Malware Analysis Search, VirusTotal, and then Google), and at times if the hash search results in no hits and the file type is of interest then I may upload the file to VirusTotal to see if it’s detected. I continue this process in the timeline until I reach the point where the malware activity stops and that’s usually where the IIV is located.

To assist with confirming malicious files I used FTK Imager to export a file hash list for the entire hard drive <Step 8>. It’s a lot easier to already have files’ hashes on hand then it is to calculate the hash each time I come across a new file. I started working my timeline keeping in mind everything I found including the timeframe 10/16/2011 6:50:09 PM to 10/08/11 11:37:38 PM. Besides the timestamps that were not accurate (reflects activity in future) the timeline ended on 10/16/2011 so that is where I started my analysis. I first saw the consrv.dll file detected by McAfee but there were no artifacts around the malware indicating it was the result of a different attack.

After 10/16/11 the next activity started appearing in the timeline on 10/12/11. I found the same thing; more malware and artifacts associated with malware but no artifacts indicating an attack occurred.


I kept working the timeline going backwards in time. I kept finding more malware and malware artifacts but nothing pointing to an IIV explaining how the malware got onto the system. I finally reached the earliest time I noted which was 10/08/11 11:37:38 PM. There was a lot of activity involving files with similar names to the ones reflected in the McAfee log file.

I continued working backwards until I saw no more activity involving the C:\Windows\assessmbly\tmp\U\ folder which is shown in the screenshot below. The U folder was created on the system at the same time as a file resembling a configuration file. One line in the file was srv=hxxps://212.36.9.52/ and my research showed the address appeared in a blacklist and the spsyeyetracker IP blocklist. The activity just before the U folder and configuration file were created was an executable named dbywqomgec (MD5 hash a70e5c48612159b3e936d7e478f4d451) appearing in the John_Doe’s temp folder. VirusTotal showed a few antivirus programs identified the file as a dropper (Microsoft detection was TrojanDropper:Win32/Sirefef.B). Afterwards I analyzed the file with ThreatExpert to see what changes the malware caused.

The activity on the system before the dropper (MD5 hash a70e5c48612159b3e936d7e478f4d451) appeared on the system was a file showing up in the Java cache folder as shown below.

I previously discussed the forensic significance Java index files provide in the post (Almost) Cooked Up Some Java. I exported the Java index file 46e770f3-38b55d85.idx with FTK Imager and looked at the file with Notepad ++. The file’s contents are shown below.

The index file 46e770f3-38b55d85.idx showed a few interesting tidbits. First the file 46e770f3-38b55d85 was downloaded from the URL hxxp://www.seyminck.com/FFFO009/560[dot]gif which had the IP address 212.95.55.40. Secondly, the URL indicated the file was a gif image but the index recorded the file as an application. I checked the file 46e770f3-38b55d85 (MD5 hash 2e833ac26483aaad13a8051bc857ef15) header and it was indeed an executable since the file started with MZ. I analyzed the file with ThreatReport and it was identified as a dropper (Microsoft detection was TrojanDropper:Win32/Sirefef.B). The IIV still wasn’t located so I looked at the activity just before the dropper appeared in the Java cache. The activity showed at the same time another duplicate of the dropper (MD5 hash 2e833ac26483aaad13a8051bc857ef15) appeared in the John_Doe’s temp folder with the file name 0.945837921339929.exe. Four seconds beforehand a file appeared in the Java cache folder which can be seen below highlighted in red.

The Java index file 25e8c780-5c17647b.idx was exported with FTK Imager and read with Notepad ++. The information contained in the index showed that a Java archive file was downloaded from the URL hxxp://www.seyminck(dot)com/FFFO009/RRo/realestate (IP address 212.95.55.40). The Java archive came from the same domain and IP address as the executable located in the Java cache folder. I exported the Java archive 25e8c780-5c17647b (MD5 hash 6b478de65071d94c670a0bfa369a7890) and confirmed the file was a Jar file by examining it with JD-GUI. The MD5 hash search didn’t result in any hits so I uploaded the file to VirusTotal and only 2 out of 42 antivirus products detected it as an exploit. I wanted to know if Java actually executed around the time the exploit appeared in the cache. I exported and reviewed the Java log file C:\Users\John_Doe\AppData\Local\Temp\java_install_reg.log and the log showed Java did in fact execute.

The last piece I needed to identify the IIV was to determine what delivered the exploit to the system. The activity on the system before the exploit answered that question as shown below.

There was a PrivacIE entry for seyminck(dot)com/FFFO009/RRo/*87354602 which means the exploit came from third party content being displayed on a website. The PrivacIE entry was mixed in with activity resembling advertisements from the user searching for someone on peoplefinder and whitepages websites. I continued working backwards in the timeline but there was no more malware activity. The IIV was identified. A user was surfing the Internet when a website visited was hosting third party content which resulted in a successful drive-by download targeting a Java vulnerability.

More Information about the IIV

The Java archive 25e8c780-5c17647b (MD5 hash 6b478de65071d94c670a0bfa369a7890) didn’t have to be examined closer in order to identify the IIV. However, I wanted to better understand how to examine Jar files since they may provide more information about the IIV and help explain some files found on the system. I debated if I should put this section in another blog post because I didn’t want people to think this activity had to be done in order to figure out the IIV. I opted to include the information since it sheds light on what occurred when the exploit was downloaded.

The code in the Jar file was obfuscated to conceal its purpose. I reached out to the Win4n6 group about any methods to automate analyzing Jar files with obfuscated code. A few members pointed me to Java de-obfuscation tools and I’m still in the process of trying to learn how to use them. Another member mentioned that Java obfuscation appears to be not making analysts’ life difficult, but to evade detection by antivirus. The person went on to say the obfuscation is usually weak so it’s relatively simple to de-obfuscate. My first reaction was it may be simple for Java programmers but it seemed impossible to me; I know nothing about Java besides the artifacts left by Java exploits. I took a shot at manually trying to see what the Jar file did by focusing on trying to follow the logic associated the variables, class methods, and functions in the code (I don’t know the Java syntax so if I butcher the names of things such as functions then you know why).

I opened the Java archive 25e8c780-5c17647b in JD-GUI and looked at the manifest file to see the wall Java class gets executed first.

I extracted the Java source code by using the “Save All Sources” option in JD-GUI. I started reviewing the obfuscated source code in the Wall Java class when I saw two lines of code making a call to the Java method Muuum.kjdhfdkjg or Muuum.idufhidufh. For those who don’t know what a Java method is: it’s basically going to the Muuum class and executing the code listed under the method kjdhfdkjg or idufhidufh.

I followed the code to the Muuum class file and found out its purpose was to set a variable to contain an URL. Two variables are set to contain part of the URL and they are then used to build the entire URL. One URL that is built is hxxp://www.seyminck.com/ FFFO009 /560[dot]gif and this was the URL I found in the Java index 46e770f3-38b55d85.idx showing it was where the executable file 46e770f3-38b55d85 (MD5 hash 2e833ac26483aaad13a8051bc857ef15) came from. The screenshot below shows the URL being put together.

I went back to the Wall class and kept reading the code until I came across the first Java function as shown below. The Inputstream function reads data and the data being read was coming from the Java method Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk.sodarifhsdoiufhdoiufg86fetgfyusgfyudif. I highlighted the Inputstream function in green while the Java method is highlighted in red.

The followed the code to the sodarifhsdoiufhdoiufg86fetgfyusgfyudif method. The method set the variable URL to contain the value contained in variable s3 which the Wall Java class passed to the method. The method ended with by returning a call to another method in the Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk class as highlighted in red below.

Next I went to the mmmm3 method which is pictured below. The first function InputStream sets the URL to read from while the second function Openstream reads the URL stored in the URL variable. I couldn’t find the code that resulted in the URL variable containing the domain hxxp://www.seyminck[dot]com. However, this was the URL the method was reading from becaue the Jar file didn’t reference any other websites. The method returns to the Wall class the data read from the URL.

I went back to the Wall class and continued to follow the code. The next portion I picked up on is the data read from the URL was saved to a file with an exe extension. The picture below shows the code that accomplished this and I highlighted a few areas to make it easier to see. The variable ufy highlighted in the first red box was set to contain a string with a random number ending in .exe. The next variable iioi655er5w5 (highlighted in blue) was set to contain another variable concatenated with the ufy variable at the end. This means the string contained in iioi655er5w5 ends in .exe. The function FileOutputStream writes data to a file and names the file with the string in the iioi655er5w5 variable.

The previous code explains the activity on the system immediately after the exploit was downloaded. Reading the URL hxxp://www.seyminck.com/FFFO009/560[dot]gif resulted in Java caching the file while Java wrote the data to a file with an .exe file extension. The Java index file 25e8c780-5c17647b.idx showed that the file 46e770f3-38b55d85 (MD5 hash 2e833ac26483aaad13a8051bc857ef15) in the Java cache was read from the URL in the Java exploit. Another file with the same MD5 hash was created on the system at the same time and was named a random number with exe as the file extension.

At the bottom of the previous screenshot shows the Java method Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk.kjsf8888 being called and the variable iioi655er5w5 (contains the filename ending in .exe) is passed for the method to use. The picture below is a close up of the method call.

My journey following the code ended when I went to the kjsf8888 method in the Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk class file. The code highlighted in green in the picture below highlights the function Runtime exec executing the file contained in the iioi655er5w5 variable which is a file whose name is random number with an .exe extension (seems like this file 0.945837921339929.exe found on the system). The activity on the system after 0.945837921339929.exe was created in the temp folder was another dropper (MD5 hash a70e5c48612159b3e936d7e478f4d451) showing up on the system. To me this further confirms the Jar file was successful in exploiting a vulnerability in Java and this was how the system became infected in the first place.

Summary

I went into the examination planning on to perform a surgical malware removal and ended up doing a complete system rebuild due to how bad the infection was. The initial infection vector was a user surfing the Internet and coming across a website hosting third party content which resulted in a successful drive-by download targeting some Java vulnerability. Going back to the person and telling them how the infection happened makes it easier for them to change what lead up to the issue. I would have done a disservice if I skipped trying to find the IIV and went back to the person with a laundry list of recommendations. Enable the firewall, use strong passwords, update anti-virus software, use caution with opening attachments, use caution clicking on links, update computer software, etc … Throwing out a laundry list of recommendations is a lost opportunity to improve security since it doesn’t address the root cause. Trying to implement five or ten recommendations is a lot harder than focusing on the one recommendation that actual caused the infection.

Identifying the IIV is a challenge worth confronting. For success one not only needs to understand the forensic artifacts located on a system and their significance but needs to know about attack vector artifacts and how to recognize them. Being able to understand both artifacts types can help in answering the question how did malware end up on the system.

In this round of links I’m talking about drive-bys, malicious ads, web attack artifacts revealed with Mandiant’s Highlighter, and a justification for companies to fail security audits.

Video Showing Drive-by Download from MySQL

As most people probably heard by now MySQL.com was serving up malware to its visitors last month. SecurityMonkey put together the post [Video]: Watch Malware Drive-By Download from MySQL.com which contained various links about the incident. One link was to a video created by Armorize that captured what happened to anyone who visited the website when the issue was occurring. The video is about five minutes long and I highly recommend for people to check it out. I’ve never seen a drive-by broken down before by video. The video by itself is pretty cool but I think the true value is in what it shows about the attack vector infecting people visiting the website. Check out the sequence of events I noted from the video:

        -  (00:55) Internet Explorer starts to load the website mysql.com
        -  (01:04) Java.exe starts running on the computer
        -  (01:11) Executables are dropped onto the computer. These were the attack’s payload
        -  (03:43) It was revealed that a Jar file was downloaded to the system and this is why Java started. The Jar file download occurred before the executables appeared on the computer

The attack summary was a user visited mysql.com and eventually gets redirected to a site hosting the Black Hole exploit pack. In that instance, the exploit pack used a Java vulnerability to infect the system. Why does any of this even matter … knowing this can help determine how a system was compromised. Let’s say someone was dealing with an infected computer and were trying to figure out how the malware got installed on the computer. The video didn’t show what was on the system’s hard drive but the attack is very similar to the Java exploit artifacts I documented. To date I’ve documented three different ones which were Java Signed Applet Exploit Artifacts, CVE-2010-0840 (Trusted Methods) Exploit Artifacts, and CVE-2010-0094 (RMIConnectionImpl) Exploit Artifacts. There was a consistent pattern to the all the artifacts:

        -  Temporary file created (Jar file got dropped onto the system)
        -  Indications of a vulnerable Java executing
        -  Internet activity showed a user visited a malicious website

The key difference (besides the Java vulnerability) between the Armorize video and the method I used to document the exploit artifacts was the tool used to create and deliver the exploit. The video documented a Java exploit from the Blackhole exploit pack and according to Contagio’s August 2011 Exploit Pack Overview spreadsheet Blackhole goes for $1,500 a year. My testing leveraged the freely available Metasploit to document exploit artifacts. Taking the time to document the exploit artifacts can pay big dividends during an examination when trying to determine the “how”. How did the system get infected? Well if the activity on the system around the time malware was created shows either a Jar file appearing or Java executing then a Java vulnerability may have been the culprit. If there is Internet activity then the Internet and a web browser may have been used to deliver the exploit to the system.

Malicious Advertisement Leads to PDF Exploit

I first started looking into attack vector artifacts when one of my systems got whacked with a Fake AV virus. At the time I had the DF skills but I lacked the IR skills such as figuring out what happened to my system. I took a shot at trying to figure out how the system became infected to see if I could. It took me a little bit but I was not only able to find the malware dropped onto my system but I traced the infection back to Yahoo email. I was even able to determine the exploit used in the drive-by. It was a malicious PDF file that targeted a vulnerability in Adobe Reader. The PDF appeared on the system in the temporary Internet files folder just prior to the first malware getting dropped. The experience taught me valuable lessons. First the more obvious one; don’t quickly check your web email from a test system with vulnerable apps even if it’s only for a few seconds. The second and more important lesson was the need to understand how different attacks appear on a system after they have occurred. The examination took me some time to figure out since I didn’t really know what to expect or what artifacts to look for.

I recently came across TrendMicro’s post Malicious Ads Lead to PDF Exploits. The post is from last year but it made me reflect on the experience that motivated me to start my journey into incident response. The post mentioned how malvertisements on a popular web-based email service lead to users being directed to sites with exploits. The article isn’t written from the DFIR perspective since it was focused on the vulnerabilities targeted in the attack. There wasn’t much discussion about the artifacts left on a system either besides malicious PDFs and internet activity. The little information provided did show how the attack occurred.

        -  User visits web based email service
        -  Redirect downloads malicious PDFs targeting Adobe Reader vulnerabilities
        -  Adobe reader has to process the PDF for the exploit to be successful and install malware

The attack pattern is something I’ve seen in a few other places. My infected test system had the same sequence of events but it took me a bit to actually see it. That examination made me more aware about the artifacts associated with a PDF exploit thereby making it easier to spot it in a few other examinations I did afterwards. I also saw the same pattern on my test systems I exploited with Metasploit. I researched a PDF exploit in the post CVE-2010-2883 (PDF Cooltype) Exploit Artifacts. Do the following areas I noted in the post look familiar?

        -  PDF document created
        -  There were references about a PDF file being accessed
        -  A vulnerable Adobe Reader started on the system

Web Attack Artifacts

Russ McRee’s October’s Toolsmith Log Analysis with Highlighter is a great read for a couple reasons. I enjoy reading his articles since he provides an overview about a tool’s functionality. In this edition he doesn’t disappoint as he covers how to perform log analysis with Mandiant’s Highlighter. Showing how to do log analysis is cool enough but he demonstrates the tool by looking for attacks in his website’s logs. He looks for specific artifacts caused by remote file include and directory traversal attacks. I haven’t found any references that document the artifacts left in logs by different attacks so I enjoyed reading about it. Eventually I’m going to start researching the artifacts left in logs but I still have a lot to do with the artifacts left on systems.

Fail a Security Audit Already Will You

When I started working full time in the information security field I was performing vulnerability assessments and security audits. Maybe I’m a little biased because of my background but I can see the value security audits provide when performed correctly. I’m not talking about audits where boxes are just checked off but risk based audits looking at the security controls protecting an organization’s critical information. Andreas M. Antonopoulos's article Fail a security audit already -- it's good for you provides an argument for why companies should fail security audits. The article makes some great points but the one thing I thought was missing is when organizations try to justify (aka make excuses) or minimize why serious weaknesses are present. Take patching as an example.

Patching isn’t done to prevent applications and systems from breaking. I was a system admin so I get it … especially since I’ve dealt with the hassle of tracking down the patches that jacked up my systems. However, using the reason as a justification to not patch without doing any due diligence by you know actually testing patches to see if anything breaks is something else. The SANs Top Cyber Security Risks report from a few years ago highlighted how third party applications on client systems are targeted. The exploits I discussed in this linkz edition targeted vulnerabilities in client applications such as Java and Adobe. How can these vulnerabilities on computers with users surfing the web be lumped into the same category as some application supporting a critical business process with neither of them getting patched? The security risk didn’t go away and the vulnerabilities don’t magically repair themselves. It’s too late to finally figure it out once the organization is staring at the artifacts from a successful exploit.

Anatomy of a Drive-by Part 1 was the first part of this post and it provided some background information about the system under examination. Part 1 also covered the first two examination steps which were the examination of the auto-start locations and the examination of the files of interest. This post is the second half of the examination where the question of what happened on the computer will tried to be answered.

As a reminder, the examination so far has located the following: five copies of the SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d), two copies of Hiloti (MD5 5170e6923859a70ede3b2685ccd5ba04), and one copy of Hiloti (MD5 30fd84f3c0e0dc7666658dc52c216a2a). The first piece of malware was created on the system at 09/12/10 06:38:42PM.

***Caution: The URLs and domains I reference in this post were hosting malicious content at some point in time. I haven’t sanitized these URLs or domains (besides making them un-clickable) in order to allow people to conduct their own research if they choose to. With that said, please use caution if you are going to research any of the URLs or domains since they still may be hosting malicious content.****


Timeline Analysis
The previous steps indicated the timeframe I was interested in was on the evening of 09/12/2010. To reduce the amount of data in my timeline I applied an Excel filter to only show entries from this day since my focus was determining how the malware was created on the system. I recommended to my friend that he turn off his computer and the timeline showed the computer has been powered off since my recommendation was made. The last entry in the timeline occurred at Sun 09/12/2010 20:13:08 which was approximately 95 minutes after the malware appeared on the system.

I started my timeline review at Sun 09/12/2010 20:13:08 and worked my way backwards. Whenever the timeline showed a file of potential interest I would examine the file closer using other tools such as Encase. I will be providing multiple updates throughout the timeline analysis section in order to summarize how certain artifacts tie together before I move on to the next set of artifacts.

Before I asked my friend to turn off his computer I tried to help him identify the rogue security program by using the task manager. This approach didn’t work because the security program blocked any new process, including the task manager, from running. In addition to blocking the new process, a fake security alert would appear indicating the process was virus. The timeline entries below show the task manager being accessed.
Working through this portion of the timeline I had to go through a lot of files that were accessed. The amount of files accessed in such a short period of time made it appear like the computer was shutting down and/or a scan was occurring on the system. The next timeline entry of interest occurred at 19:05:45 which involved one of the copies of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d).
The image below shows the next timeline entries of interest.
The files arezires.dll and get2[1].php were created on the system at the same time which was 19:03:12. Both of the files were examined and it was determined the files were the same since the MD5 hashes matched each other. The following is the additional information about the files:

arezires.dll and get2[1].php

* File path: \WINDOWS\arezires.dll and \Documents and Settings\*****\Local Settings\Temporary Internet Files\Content.IE5\M95YKOXS\get2[1].php
* VT result: malicious and hash search identified the file as FakeWarn and FakeAlert
* MD5 hash: ef3501a3a215949bd61142139f631406
* Creation date: 09/12/10 07:03:12PM
* Last written date: 09/12/10 07:03:12PM
* MFT last modification date : 09/12/10 07:03:12PM

The content of the arezires.dll file contained script which appeared to force a person to a certain website as can be seen below.
I ran the arezies.dll file through the online scanner Jsunpack, and the following paths were being accessed on the domain: logotarget.jpg, images/point.png, and images/downbutton.png. A Google search for the domain antivirpwr[dot]com was performed and the top four hits are shown below.
As shown in the picture, the antivirpwr[dot]com domain is advertising security software and my theory is this would have been the website my friend would have been directed to if he tried to purchase the SpyPro software. McAfee’s description write-up on FakeAlert-SpyPro.gen.ai strengthens this theory since the sample analyzed tried to access the same website listed in the arezires.dll file. I never confirmed this theory because I didn’t examine the SpyPro Trojan I located.

Continuing on with the timeline there was another entry that occurred at 19:03:12 and is shown below.
The entry shows that the get2[1].php (MD5 ef3501a3a215949bd61142139f631406) file came from the 231207da0903[dot]deanard[dot]com domain. I queried the domain using Robtex and the domain mapped to an IP address which is shared with over 40 other hosts. The picture below shows a few of these hosts.
Looking further into the 231207da0903[dot]deanard[dot]com domain I reviewed the records section of Robtex and the picture below shows the IP address for this domain mapped to *[dot]deanard[dot]com.
231207da0903[dot]deanard[dot]com was mapping back to the parent domain so I performed a Google search on the domain which lead me to a Malware Intelligence blog post titled Pirated Edition Affiliate program Pay-per-Install. The post discusses the business model of affiliate programs paying customers for spreading their malware. The following are the interesting connections between the post and the system I was examining:


* The file being referenced in the post was named get[2].php which has the same name as the file brought down by deanard[dot]com domain.
* The host assiocated with the get[2].php file was husseta[dot]com which is also one of the hosts that is mapped to the 94.75.221.77.
* The deanard[dot]com domain also maps to the IP address discussed in the blog post.
* The IP address in the post 95.221.98.246 and the IP address 94.75.221.77 both have the same Autonomous System number which is AS16265 “LeaseWeb AS Amsterdam, Netherlands”.

I found this to be a fascinating connection and it makes me wonder if this affiliate program is involved with the malware present on my friend’s system, and if so how would you go about to confirm this link.

Timeline Examination Summary Update:
**** So far, the analysis determined the computer has been powered off since Sunday night and there is activity involving the domain deanard[dot]com. This domain has links to an affiliate program which pays customers to spread their malware. There were two copies of the FakeAlert (MD5 ef3501a3a215949bd61142139f631406) downloaded from deanard[dot]com at 09/12/10 07:03:12PM. The FakeAlert made references to the antivirpwr[dot]com website which was advertising security software. There were indications this website is not advertising legitimate software. ****

The next few entries of interest are associated with the SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d). The entry below shows one of the copies of the program is referencing htmlMain.htm at 19:02:56.

Just before this entry the timeline showed the SpyPro program being accessed.
My friend had MacAfee antivirus installed on his system at the time of the attack and the entry below shows a scan was started at 19:01:26. There were other event log entries around this time reflecting services being started in addition to the McAfee scanner.
The 19:01:12 entry showed another copy of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) was accessed.
The next portion of the timeline had a lot of activity involving the Temporary Internet Files folder and a lot of the files were images. The picture below shows a couple of these files.
The entry right before these image started appearing on the system shows my friend visited Facebook at 18:50:29.
Continuing to work backwards in the timeline the next entries of interest occurred at 18:41:52, which is just under two minutes of when the last piece of the identified malware was created on the system (this last creation time was 18:39:04). This was when cookies from Yahoo were created on the system.
 At 18:40:58 my friend accessed his email.
Timeline Examination Summary Update:
**** The examination at this point is closer to the timeframe of interest which is 09/12/10 06:38:42PM since this is when the first piece of identified malware was created on the system. The significant piece of information from this portion of the timeline indicates my friend was already infected when he went to Facebook and he might have been using Yahoo’s email around the time the computer was infected. The other activity in this portion of the timeline involved SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d). ****

The next entries of interest occurred at 18:40:42 which is shown in the image below.
The files Gwomiliyojoqo.dat and get2[1].htm were created on the system at the same time and both files had the same MD5 hash. The content of this file was a string of 120 characters that started with 3C3E7A6E68. The hash search at VT had 0 out of 42 dections and the Google search only had two hits with one of the hits being a July 21, 2010 file submission at Jsunpack.

At 18:40:40 the Hiloti Trojan (MD5 30fd84f3c0e0dc7666658dc52c216a2a) appeared on the system. This malware was first identified reviewing the autoruns output. The image below shows that a .htm file was modified at the same time but the examination of this file didn’t reveal any additional information.
Also at 18:40:40 a software run key was also modified.
The following are modifications made to this key and the output is from Harlan Carvey’s Regripper:
* Prehoherajoza -> rundll32.exe "C:\WINDOWS\egugehudafu.dll",Startup
* cepijgkk -> C:\Documents and Settings\****\Application Data\oexrvilnf\hdwhvqmuqiw.exe
* anyplcer -> C:\Documents and Settings\****\Local Settings\Application Data\bfuqvjmoj\hcdrsjbuqiw.exe

The Internet history shows my friend was on Yahoo’s website at 18:39:31 and this is shown in the image below.
The next few entries in the timeline indicated Adobe Reader was running and there was a modification to a log file used by Adobe at 18:39:19.
The content of this log file provided some useful information. First was that the Adobe ARM 1.4.5.0 logging was started at 18:39:18 and ended one second later. Second the log showed the version of Adobe Reader on the computer was 8.2 which is outdated since the latest version (at the time of this post) is 9.3.4.
The timeline showed there were modifications to Adobe ARM prefetch files further collaborating the ARM logging was running. At 18:39:14, a copy of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) executed.
The remaining timeline entries leading up to when the last piece of identified malware was created on the system shows another copy of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) executed, and there was a modification to a run key in my friend’s user account ntuser.dat. both of these are illustrated in the images below.

The following were modifications made to the ntuser.dat run key and the output is from Harlan Carvey’s Regripper:
* cepijgkk -> C:\Documents and Settings\****\Application Data\oexrvilnf\hdwhvqmuqiw.exe
* anyplcer -> C:\Documents and Settings\****\Local Settings\Application Data\bfuqvjmoj\hcdrsjbuqiw.exe
* Fnanaha -> rundll32.exe "C:\WINDOWS\qdfnst.dll",Startup

These registry modifications are a redundant persistence mechanism to the copies of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) because the same modification was made to the Software Currentversion\Run key. However, the Software run key referenced egugehudafu.dll instead of qdfnst.dll. The qdfnst.dll is a different copy of the Hiloti Trojan and this file will be discussed later in this post.

Timeline Examination Summary Update:
**** The examination at this point brought us closer to the time period of interest which is 09/12/10 06:38:42PM. The examination identified two persistence mechanisms using a Run key in the Software registry hive and a user account’s ntuser.dat. Both of these mechanisms were configured to launch two copies of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) and a copy of the Hiloti Trojan. The other activity in this portion of the timeline that could be meaningful was the Adobe ARM logging service was started.

Hopefully at this point of the examination I haven’t lost too many readers because the next portion of the timeline brings us to the time period of interest. At 18:38:58 two copies of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) were created and executed on the system.
A registry modification occurred at the same time a copy of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) executed on the system. The keys modified are illustrated below.
As can be seen in the picture two modifications occurred to the HCU\Software\Microsoft\Windows\Currentversion\Policies key. This key is associated with the attachment manager which attempts to protect your computer from unsafe attachments in emails or unsafe files from the Internet. For additional information refer to Microsoft’s support article 883260. The Policies\Attachments key was changed by adding "savezoneinformation" with the data of 1. According to the support article, this change makes Windows to not mark file attachments by using their zone information causing Windows to not make appropriate risk assessments.
The Policies\Associations key was changed by adding "LowRiskFileTypes" with a value of .exe. According to the support article, this change results in the user not being prompted when accessing .exe files regardless of the zone including Internet restricted zones.
I am not sure how these registry modifications fit into the attack since the majority of the malware was already present on the system. It leads me to believe the change was made in anticipation of downloading addition malware in the future. The next portion of the timeline is shown below.
Most of the activity between 18:38:53 to 18:38:51 involved copies of SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) and Hiloti (MD5 5170e6923859a70ede3b2685ccd5ba04) which were identified during the examination of the files of interest step. However, at 18:38:49 an executable named google.exe was created on the system (line 4955 in the above picture). The examination of this file determined it was a new piece of malware and the additional details are below.

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

The next few entries in the timeline showed a copy of a SpyPro (MD5 ce5806f3f3a2afa8efe0272440ae6b2d) and an unknown program (0.8503427712213907.exe) executed.
The next entries in the timeline finally bring us to 09/12/10 06:38:42PM which is the point of time when the first piece of identified malware identified was created on the system.
As you can see in the image copies of SpyBot (lines 4927 and 4928) was created on the system, one copy of SpyBot executed (line 4930), and the previously mentioned file qdfnst.dll on line 4929 had its MFT entry modified. The qdfnst.dll file was identified as a new copy of Hiloti and the following is the additional information about this file.

qdfnst.dll
* File path: \WINDOWS\qdfnst.dll
* VT result: malicious and hash search identified the file as Hiloti
* MD5 hash: f1abef9bd8240815ceaf97a7527318b2
* 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:38:42PM

Timeline Examination Summary Update:
**** The examination has identified two new variants of Hiloti (MD5 a06e417b9743e65bbb9ace16d6d3a65f and MD5 f1abef9bd8240815ceaf97a7527318b2) on the system. Finally, we are at the point in time when the first piece of identified malware was created on the system. The examination up to this point has been looking for artifacts associated with the payload of the attack such as the numerous pieces of malware identified. However, the examination will now start to focus on trying to identify the initial infection vector which resulted in the first piece of malware being dropped to the system.****

At 06:38:41PM acrord32.exe prefetch file was modified and the unknown program (0.8503427712213907.exe) was executed. This is the second reference so far regarding this unknown program.
The picture below shows the next entries in the timeline which involve the Java deployment cache folder.
The entries of interest are on lines 4918 and 4919 because it showed 781da39f-6b6c0267.idx and 781da39f-6b6c0267 being created on the system at 18:38:39. The signature analysis identified the file 781da39f-6b6c0267 has having the zip file format. I first reviewed the content of the 781da39f-6b6c0267.idx file and this is shown below.
As you can see in the picture, there are two items of interest which are the IP address 91.213.217.31 and the rox[dot]jar file being accessed from the domain xhaito[dot]com. The IP address was queried and there were five hosts sharing this address.
The xhaito[dot]com mapped to the IP address so next I queried the domain in order to view the Whois record. The whois information is listed below and the contact information could be false.

Did you notice the xhaito[dot]com domain was created on 09/12/2010 which is the same day my friend’s system was infected? The time listed is 04:33:54 but I am not sure what timezone is used when a domain is registered. I performed a Google search for the domain and the domain was present in the MalwareURL database.

The URLs listed in the database don’t match the URL in the .idx file but the URLs still involve the same domain. The picture below was the other information found on MalwareURL about this domain.

Xhaito[dot]com domain was first listed in the database on 09/15/2010 with the description of the Siberia Exploit Pack sitting on this IP address with the Hiloti Trojan as the payload. The examination has already found a few different copies of the Hiloti Trojan so the information in this database seems to match up to the artifacts on the system. The research I did on the exploit pack indicates the tool only has exploits for Adobe Reader and Java.

The 781da39f-6b6c0267.idx file provided valuable information including a jar file being referenced from a domain that is hosting an exploit pack and the Hiloti Trojan. The 781da39f-6b6c0267 file was the jar file downloaded from this domain. The content of this file contained eight class files.

I have been using online scanners to help me examine Java files but I have never encountered a jar file before. I reached out to the Yahoo Win4n6 group for feedback on how to review these files and the answer I received was to examine the jar file with a Java decompiler in order to see the code. I tried this using one of the suggested decompilers which was the JD-GUI. I didn’t make much progress on this and this is an area I have added to my list to improve my knowledge on. However, a member in the Win4n6 group provided me with a hint to look for file names and I saw the reference below.
The jar file had a reference to the file google.exe. Google.exe has already been located and it was confirmed this was a copy of the Hilot Trojan (MD5 a06e417b9743e65bbb9ace16d6d3a65f).

The 781da39f-6b6c0267.idx and 781da39f-6b6c0267 files are good candidates to be involved with the initial infection vector because the files appeared on the system one second before 18:38:42 (this is when the first piece of identified malware was created on the system). Plus whatever the purpose was of these files it appeared to succeed since the google.exe executable ended up on the system. However, I didn’t reach the point in the examination where there was no longer a trail of artifacts so the examination continued. The timeline showed that one second before the idx and jar files were downloaded a different copy of the Hiloti Trojan with the name of qdfnst.dll was accessed. This means the idx and jar files are not the initial infection because the system was already infected before these files appeared on the computer.
The next area of the timeline showed more activity of an infection before the 781da39f-6b6c0267.idx and 781da39f-6b6c0267 files were dropped on the system. The picture below shows the entries.
At 18:38:38 the command prompt was accessed which was one second after a Java prefetch file was modified. Previously I referenced an unknown program named 0.8503427712213907.exe executing on the system and this file was created on the system at 18:38:35. This executable was examined and it was the same file as google.exe since the MD5 hashes were the same. Here is some additional information about the file:

0.8503427712213907.exe
* File path: \Documents and Settings\****\Local Settings\Temp\0.8503427712213907.exe
* VT result: malicious and hash search identified the file as Hiloti
* MD5 hash: a06e417b9743e65bbb9ace16d6d3a65f
* Creation date: 09/12/10 06:38:35PM
* Last written date: 09/12/10 06:38:36PM
* MFT last modification date: 09/12/10 06:38:36PM

At 18:38:35 another file was created on the system at the same time as the Hiloti Trojan (MD5 a06e417b9743e65bbb9ace16d6d3a65f). The content of this file is shown below.
I started performing searches using various strings of characters from this file and this activity lead me to a full discloser archive about the Microsoft Windows Help Center vulnerability. The exploitation of this vulnerability allows an attacker to bypass the trusted documents whitelist and execute arbitrary commands. According to the full disclosure archive, the attack against this vulnerability would look like the following (I am only including the information that provides context to a few of the next artifacts on the system).

* A user would be forced to fetch an .asx file with the htmlview element
* From the htmlview element the hcp protocol gets called in order to exploit the vulnerability to bypass the whitelist
* After the whitelist is bypassed then arbitrary commands can be executed in the context of the user’s privileges

The contents of the hcp[1].htm is the exact same as the code used to defeat the whitelist. A section in the archive mentions accessing a hcp:// URL in Internet Explorer version 8, Firefox, or Chrome results in a command prompt. The system under examination had Internet Explorer 8 installed and Line 4911 shows the command prompt being accessed. The presence of the hcp[1].htm file, the command prompt being accessed, the Hiloti Trojan (MD5 a06e417b9743e65bbb9ace16d6d3a65f ) named 0.8503427712213907 on the system, and the system not having this patch installed leads me to believe this exploit was successful.

The next group of entries in the timeline involved Java running on the system as illustrated below.
The next significant entry in the timeline was a file being created in the Temporary Internet Files folder at 18:38:25.
The content of this file was examined and it showed there was not only a reference to the jar file that was downloaded to the system but there was a reference to the xhaito[dot]com domain as well (note: this was one of the URLs listed in the MalwareURL database). At this point I definitely realized I need a better understanding of examining artifacts.
I uploaded the file to jsunpack to be scanned and the results provide context for a few of the files located on the system. The picture below indicates there was an .asx file located on the xhaito[dot]com which is one required component for the help center vulnerability.
The URLs section of jsunpack shows the URLs requested. Notice the call for the hcp URL which was present in the hcp[1].htm file and the reference to the jar file. I saw the reference for a pdf but there was not one present on the system even though Adobe was running at some point.
Continuing on with the review of the timeline the last significant entry related to the initial infection vector occurred at 18:38:24 which was one second before the show[1].htm file appeared on the system.
I am not sure if you remember when I mentioned in Part 1 the entries from the PrivacIE folder’s index.dat file are from third-parties hosting content on websites. At 18:38:24 a PrivacIE entry shows that the show.php was accessed from the xhaito[dot]com domain.

Timeline Examination Summary Update:
**** The trail of artifacts including malware and the xhaito[dot]com domain stopped after this point in the examination. The antivirus scans I conducted after I cleaned the system confirmed the first piece of malware was the 0.8503427712213907 file (the scans found copies of malware in the restore points). This malware appeared on the system at the same time of an artifact from the exploit of the Windows Help Center vulnerability. This doesn’t have a bearing on my examination but I wanted to mention through my research the Siberia Exploit pack referenced in the MalwareURL database doesn’t have the hcp exploit. A different exploit pack or an updated version of Siberia was used in this attack. The initial infection vector for this system appeared to be that third party content was hosted on a website which redirected users to the xhaito[dot]com domain for a drive-by attack. One of the vulnerabilities targeted in this drive-by was the Windows Help Center vulnerability.****

At this point I wanted to go further down the rabbit hole to see if I could locate the malicious third-party content and to find out what website was hosting the content. Unfortunately, I couldn’t find the malicious content referencing the xhaito[dot]com domain but as I stated previously I need a better understanding of examining artifacts. The bright side was I had another lead to pursue because there were two PrivacIE entries at 18:38:24 as illustrated below.
The other PrivacIE entry was from the batfior[dot]co[dot]cc domain. I tried to research this domain and I was unable to locate any information on it. The other artifacts before these timeline entries seemed to be associated with ads being displayed. The next file of interest was created on the system at 18:38:22 which is one second before the two PrivacIE entries.
The picture below shows the contents of this file.
I performed a few Google searches using different characters from the file’s contents that didn’t result in anything fruitful. I uploaded the file to jsunpack and received the following:
I am not sure what this file is and the function it performs so I continued reviewing the timeline. The next lead I found also involved a file being created on the system at 18:38:22.
This file was uploaded to jsunpack and the first interesting item was the URLs.
The URLs were listed as iframes as can be seen below.
The first URL listed is for the batfior[dot]co[dot]cc domain which appeared at the same time as the PrivacIE entry for the xhaito[dot]com domain. This file was the last reference I found for the batfior[dot]co[dot]cc domain on the system so I started to research the trueffects[dot]net domain. The domain mapped to IP address 72.9.236.172 which was shared with two other domains.
To learn more information I performed a few Google searches for the trueffects[dot]net domain. One of the first hits I found was a post on a blog called Spyware Sucks. There were multiple posts from 09/01/2010 to 09/03/2010 mentioning how the facilitatedigital[dot]net domain was spreading malvertizing. At the time the author suggested to be careful with content from trueffects[dot]net as well since it shared the same IP address. I thought this was interesting and then I saw the next entry in the timeline.
Back to Google I went to search for this URL and the first hit was a thread in the Kaspersky forums. A user posted on 09/18/2010 there was a message indicating something was blocked from the trueffects[dot]net/www/cmd URL. Keep in mind this user’s post was six days after my friend’s computer was infected. I posted a few of the Google search hits below involving this domain (I edited the hits’ URLs). As you can see there is indications this may be a risky domain and there was even a hit for a comment made on 09/14/2010 about one of Yahoo’s advertisers supplying a URL from trueffects[dot]net which tried to infect their computer.
Continuing on with the timeline there was another file created at 18:38:22. This file was a cookie shown below.
Here is the content of this file.
The domain in the cookie mapped to the IP address 168.75.207.20. The few Google searches I performed both resulted in hits on ThreatExpert for the domain and IP address. The picture below shows the search I performed on ThreatExpert in order to show the hits I saw through Google (I only did this for this post because the screenshot of the Google search was too large).
All of the artifacts I have been discussing occurred at 18:38:22 which was one second before the xhaito[dot]com domain PrivacIE entry. You may be asking yourself what occurred before 18:38:22 and the timeline entry below answers that question.
This entry is for the yimg[dot]com domain and the brief research I did on this domain indicates the domain is controlled by Yahoo. The timeline showed there was no activity at all on the system between 18:38:05 and 18:38:21. This means the trail of artifacts on the system ended at 18:38:21 and the last activity on the system initiated by my friend is shown below.
My friend was at his Yahoo email at 18:36:06 but there was a PrivacIE entry from a local newspaper in my area indicating he may also have been at that website as well.

Timeline Examination Summary Update:
**** The trail of artifacts including malware and the xhaito[dot]com domain may have stopped but there was other activity on the system that provided an additional lead. By following this lead it resulted in the trueffects[dot]net domain being discovered and this domain is associated with malvertizing. I wasn’t able to identify the website whose advertiser provided the malicious content that caused this redirect but I was able to narrow it down to two websites. This was the point in the rabbit hole where my journey of trying to find the answer of what on my friend’s system caused the malware to be downloaded ends.****


Overview of the Attack
I don’t want to give the impression my examination was completed because I didn’t complete one important step. This is the examination of the artifacts located including the malware, jar file, and the files associated with third-party content. I think some of these files would have to be analyzed in order to fully understand how the attack occurred. I presented a lot of information involving the examination of my friend’s computer. The sheer amount of information may have made it difficult to see what happened on the system so the following timeline highlights the significant events of this attack.

* 09/01/10 to 09/03/10 Spyware Sucks blog had a few posts mentioning facilitatedigital[dot]net domain was spreading malvertizing. The author warned about the trueffects[dot]net domain since it shared the same IP address
* 09/12/10 McAfee's description write-up on FakeAlert-SpyPro.gen.ai was discovered. This was referenced in the 09/13/10 blog post.
* 09/12/10 Google search hit located a person posting a comment about trueffects[dot]net is connected to malware
* 09/12/10 04:33:54 The xhaito[dot]com domain Whois record was created. This domain was hosting an exploit pack and the Hiloti Trojan.
* 09/12/10 06:36:06PM User accessed Yahoo email and there was activity involving timesunion.com which is a local newspaper.
* 09/12/10 06:38:05PM to 06:38:21PM There was no activity on the system.
* 09/12/10 06:38:21PM PrivacIE entry for a domain controlled by Yahoo.
* 09/12/10 06:38:22PM Cookie from this[dot]content[dot]served[dot]by[dot]adshuffle[dot]com was created on the system. This domain was associated with malware.
* 09/12/10 06:38:22PM asrefinc11[1].js was created. Jsunpack identified this file as suspicious.
* 09/12/10 06:38:22PM l[1].htm was created. This file had references to the batfior[dot]co[dot]cc and trueffects[dot]net domains. The trueffects[dot]net domain was associated with malware and maps to a IP address shared by another domain associated with malware.
* 09/12/10 06:38:22PM PrivacIE entry for the trueffects[dot]net domain.
* 09/12/10 06:38:24PM PrivacIE entries for the batfior[dot]co[dot]cc and xhaito[dot]com domain. This means these domains were hosting content on a website the user visited. the xhaito[dot]com domain was hosting malicious content.
* 09/12/10 06:38:25PM show[1].htm file was created on the system. This file had references to a few of the artifacts (jar file and the Windows Help Center vulnerability). Also, this file was associated with the xhaito[dot]com domain.
* 09/12/10 06:38:35PM The hcp[1].htm file was created on the system. The content of this file is associated with the Windows Help Center vulnerability.
* 09/12/10 06:38:35PM 0.8503427712213907.exe (Hiloti MD5 a06e417b9743e65bbb9ace16d6d3a65f) was created.
* 09/12/10 06:38:38PM Command prompt was accessed. This might have been due to the windows help Center vulnerability being exploited.
* 09/12/10 06:38:38PM Qdfnst.dll (Hiloti MD5 f1abef9bd8240815ceaf97a7527318b2) was accessed.
* 09/12/10 06:38:41PM 781da39f-6b6c0267.idx and 781da39f-6b6c0267 were created on the system. The files were associated with the xhaito[dot]com domain and the 781da39f-6b6c0267 was a jar file with a reference to google.exe.
* 09/12/10 06:38:41PM 0.8503427712213907.exe (Hiloti MD5 a06e417b9743e65bbb9ace16d6d3a65f) was executed.
* 09/12/10 06:38:42PM Qdfnst.dll (Hiloti MD5 f1abef9bd8240815ceaf97a7527318b2) MFT record was modified.
* 09/12/10 06:38:42PM 176572328.exe (Hiloti MD5 5170e6923859a70ede3b2685ccd5ba04) and 176572329.exe (SpyPro MD5 ce5806f3f3a2afa8efe0272440ae6b2d) were created.
* 09/12/10 06:38:49PM Google.exe (Hiloti MD5 a06e417b9743e65bbb9ace16d6d3a65f) was created.
* 09/12/10 06:38:51PM 176581812.exe (Hiloti MD5 5170e6923859a70ede3b2685ccd5ba04) and 176581813.exe (SpyPro MD5 ce5806f3f3a2afa8efe0272440ae6b2d) were created.
* 09/12/10 06:38:58PM hdwhvqmuqiw.exe (SpyPro MD5 ce5806f3f3a2afa8efe0272440ae6b2d) was created on the system in two locations. One was the user profile\Local Settings\Application Data\ while the other was the user profile\Application Data\.
* 09/12/10 06:38:58PM Registry modification was made to HKCU\Software\Microsoft\Windows\CyrrentVersion\Policies. Two keys were modified to make Windows not to make appropriate risk assessments and to not prompt the user when accessing files with the .exe extension.
* 09/12/10 06:39:04PM hcdrsjbuqiw.exe (SpyPro MD5 ce5806f3f3a2afa8efe0272440ae6b2d) was created.
* 09/12/10 06:39:04PM Registry modification was made to HKCU\Software\Microsoft\Windows\Currentversion\Run. There were values here to launch two copies of SpyPro and one copy of Hiloti.
* 09/12/10 06:39:19PM Vulnerable version of Adobe was running (Adobe reader v8.2.0)
* 09/12/10 06:39:31PM The user was accessing Yahoo email.
* 09/12/10 06:40:40PM egugehudafu.dll (Hiloti MD5 30fd84f3c0e0dc7666658dc52c216a2a) MFT record was modified.
* 09/12/10 06:40:40PM Registry modification was made to HKLM\Software\Microsoft\Windows\Currentversion\Run. There were values here to launch two copies of SpyPro and one copy of Hiloti.
* 09/12/10 06:41:52PM Yahoo cookies were created in the user profile.
* 09/12/10 06:50:29PM The user visited FaceBook.
* 09/12/10 07:03:12PM get2[1].php (MD5 ef3501a3a215949bd61142139f631406) was created and this file came from the 231207da0903[dot]deanard[dot]com domain. The parent domain had links to an affiliate program which pays customers for spreading malware.
* 09/12/10 07:03:12PM arezires.dll and get2[1].php (FakeAlert MD5 ef3501a3a215949bd61142139f631406) were created on the system in two locations. One location was \WINDOWS\ while the other was user profile\\Local Settings\Temporary Internet Files\Content.IE5\. The content of this file had a reference to antivirpwr[dot]com domain which was advertising security software.
* 09/12/10 08:13:08PM The system was completely powered down.
* 09/13/10 McAfee Avert Labs blog had a post about an increase of submissions from customers for a variant of FakeAlert-SpyPro.gen.ai.
* 09/14/10 Google search hit identified a person who mentioned that one of Yahoo’s advertisers supplying a URL from trueffects[dot]net which tried to infect their computer.
* 09/15/10 xhaito[dot]com domain was entered into the MalwareURL database as being malicious.
* 09/15/10 Two co-workers mentioned they both knew about someone being infected on Sunday.
* 09/18/10 Google search hit identified a person posted in the Kaspersky forums that the software blocked something coming from the trueffects[dot]net/www/cmd URL.

As I mentioned previously, I haven’t completed the entire examination but I have started to form my hypothesis about what happened. The hypothesis is the computer was infected with SpyPro because my friend visited a website at the time third party content was displayed which resulted in his browser being redirected to a malicious domain. My reasoning behind this hypothesis is because it appears the malicious content (an advertisement) started a chain reaction with the computer visiting the xhaito[dot]com domain which was hosting an unknown exploit pack performing drive-by attacks. This exploit pack attempted to exploit at least two vulnerabilities present on the system (the windows help center vulnerability and an unknown vulnerability the jar file targetted) and at least one exploit was successful since the payload of the Hiloti Trojan was installed on the system. There were no artifacts of another exploit or of another attack when the first SpyPro was created on the system. Plus Microsoft stated the Hiloti Trojan is a downloader. Therefore, I am thinking SpyPro was downloaded to the system by one of the copies of the Hiloti Trojan.

At this point I was able to clean my friend’s computer and I identified a few areas of the investigation process I want to learn more about. My next steps in the examination would have been to complete the examination, develop my hypothesis about what happened, and then test this hypothesis to determine if it is valid.


Lessons Learned
When my friend asked me for assistance I could have just wiped and rebuilt his system for him. This is a practice I have seen back in my IT days, it’s a practice I read about on the Internet, and it’s a practice still occurring at a lot of organizations judging by the discussions I have had with people. If I would have followed this practice then you wouldn’t be reading this blog nor would there have been any lessons learned. My friend eventually would have been re-infected once his programs became out of date again since the lack of software updates contributed to his system getting infected. Plus I wouldn’t have had this opportunity to learn some new things as well as identifying some areas I would like to get a better understanding about.

I was able to explain the significance of regularly updating the software on a computer to my friend since this was what caused his system to become infected. If the cause was opening a malicious email or his children downloading something then my advice would have been different but it still would have focused on the root cause of the infection. As I was thinking about this, a question keeps running through my mind. How can you provide sufficient advice on the security controls that could help mitigate an incident from reoccurring without knowledge of the incident’s root cause? I think this question would apply whether if the recommendations are for a friend, a customer, or an organization you are employed with.


In closing, I wanted to thank my friend for allowing me to share this examination through my blog. I think this information could be useful to a range of people, and comments from readers could help me understand what I missed or what I could do differently. None of this would have been possible without my friend’s willingness to share even if he got free tech support. ;)