Journey Into Incident Response

Mass injection attacks that compromise thousands of websites are now a common occurrence on the Internet. One of the more recent attacks was DarkLeech. Darkleech compromised thousands of servers running Apache which resulted in iframes being injected into the websites to redirect their visitors to malicious sites. Both the Sucuri Blog and Unmask Parasites Blog do an outstanding job talking about the artifacts left on the compromised servers. The one perspective that doesn’t get discussed often is from the visitors’ computers who happen to browse to these compromised websites. This post demonstrates how to perform a root cause analysis on an infected computer to determine if the initial infection vector was the result of an injected iframe.

The Malware Indicator

Every malware incident starts with an indicator. In this instance it was obvious the computer was infected with malware as can be seen in the screenshots below.




A program named “S.M.A.R.T. Repair” started running on the computer spitting up errors about the computer’s hard drive failing. The malware went so far as trying to hide folders and files to make it appear even more authenticate.

The Response

The purpose of this post is not to illustrate my examination process. For that you can refer to my other posts such as Finding Malware Like Iron Man, Malware Root Cause Analysis, or Finding the Initial Infection Vector. Instead my focus is on showing how the artifacts I found on the system lead me to the injected hidden iframe.

Every story has a beginning so I have to at least fill in the blanks about how I found the malware on this box. I initially grabbed the volatile data with modified version of the tr3secure volatile data collection script before taking the box offline. Looking at the running processes I quickly flagged a few suspicious items.


These stood out since they are randomly named programs; a great indicator by the way to identify malware. The process to executable mapping revealed where these files were located.


Armed with the knowledge about two suspicious files (C:\ProgramData\WqPb9DQGxuSfxt.exe and C:\ProgramData\VHuvoNRQPlUqRK.exe) I was able to quickly perform the root cause analysis. This analysis is what lead me to the injected iframe on a cached webpage.

My intention wasn’t even to discuss this examination; I completed it over a year ago. I saw an email come across a listserv about finding computers impacted by an injected iframe. After I read the email exchanges I wondered how many people actually know how to determine if an infected system was the result of an injected iframe or something else. I wanted to shed light on the topic by illustrating how to do it.

               **** Important *****

To protect the identity of all parties I have changed any identifiable information. I altered user names, URLs, domain names, certain values in URLs, dates, search terms, etc... Basically, everything you are reading related to the infection has been altered except for the malicious items. XMEN had nothing to do with the actual infection; I’m just a huge fan of the XMEN. Also, for brevity I’m only showing some of the final timeline I put together about the infection.

               **** Important *****

Following the Cookies Crumbs to an iframe

Searching for the malware I located in the volatile data brought me to the point of interest in my timeline.


The Tracing registry key showed a program named WqPb9DQGxuSfxt executed after the file was created on the system. To find out what happened on the system I had to look at the activity preceding the creation of the WqPb9DQGxuSfxt.exe file. The picture below shows some of that activity.


The jusched.log file revealed that the Java application ran around the time of this infection. Continuing on I found more interesting artifacts.


The Shim cache showed the presence of some other executables that were on the computer around the time of interest. The browser history showed the system accessing the URL hxxp://leynurivid.com. The web browsing activity continued on as shown below.


Remember my disclaimer above? Fake data alert!! The user visited a XMEN WordPress blog and the products page on the blog. Immediately preceding this activity brought me closer to the initial infection vector as shown in the picture below.


The 0.11512169499856473h7i.exe file’s name closely resembles the pattern I’ve seen numerous times for downloaders dropped onto systems after successful exploits. Not only was this the first reference to other file I found in volatile data (C:\ProgramData\VHuvoNRQPlUqRK.exe) but there was another artifact for Java execution. Can you guess what should appear next?


Immediately preceding the downloader and a modification to the Java prefetch file were Java exploits. At the time I parsed these Java index files manually since there were no tools available. However, at the time of writing this post there are now a few tools including: Brian Baskin's Java Cache IDX Parser (I used this parser for this post), Harlan’s idx parser, or Mark Woan’s JavaIDX parser. The 36158da7-67c256c0 file was a Java exploit and its index file (36158da7-67c256c0.idx) contained the following:

IDX file: 36158da7-67c256c0.idx (IDX File Version 6.03)

[*] Section 2 (Download History) found:
URL: hxxp://marcelleoonard.aa.am/gipoto/yzjnbweofzjngtc9.jar
IP: 173.236.50.237
: HTTP/1.1 200 OK
content-length: 18799
last-modified: Tue, 17 Apr 2012 04:45:22 GMT
content-type: application/x-java-archive
date: Fri, 20 Apr 2012 12:39:55 GMT
server: Apache/2.2.3 (CentOS)
deploy-request-content-type: application/x-java-archive

The 10874ac5-7334b734 file was another Java exploit and its index file (10874ac5-7334b734.idx) contained the following:

IDX file: 10874ac5-7334b734.idx (IDX File Version 6.03)

[*] Section 2 (Download History) found:
URL: hxxp://marcelleoonard.aa.am/gipoto/xuxvgpcwawdrdt.jar
IP: 173.236.50.237
: HTTP/1.1 200 OK
content-length: 9722
last-modified: Tue, 17 Apr 2012 04:45:22 GMT
content-type: application/x-java-archive
date: Fri, 20 Apr 2012 12:39:55 GMT
server: Apache/2.2.3 (CentOS)
deploy-request-content-type: application/x-java-archive

Both Java exploits were served up from the URL hxxp://marcelleoonard.aa.am. Java wasn’t the only application that was targeted.


An Adobe Reader exploit was served up as well but the system didn’t have this vulnerability. Notice the lack of Adobe Reader activity on the system? In the midst of all this activity involving the marcelleoonard.aa.am domain there was a cached webpage (xmen-steel_claws-for-sale[1].htm) from the XMEN website.


The activity before the exploits appearing on the system showed more Java execution artifacts and the XMEN webpage being accessed as shown above. At this point in the analysis I identified the malware and then traced the malware infection back to Java exploits. What was left was to identify what served up the exploits which the preceding activity revealed as shown below.


The activity that occurred before the exploits was web browsing activity involving that hxxp://marcelleoonard.aa.am URL again. One item was the cached webpage dabstepinattack[1].htm. Looking at the webpage code was confirmation about its purpose.


The dabstepinattack[1].htm file served up the Java exploits (xuxvgpcwawdrdt.jar and yzjnbweofzjngtc9.jar) and Adobe Reader exploit (grfoinbnktbq.pdf). The last piece to the puzzle was to figure out what caused the dabstepinattack.php page to appear. The preceding activity answered that question for me as shown below.


All of the activity involving malware, Java exploits, Adobe exploits, and the marcelleoonard.aa.am domain just stopped. There was only web browsing activity of the user searching for wolverine steel claws which lead them to the xmen-steel_claws-for-sale page on the XMEN website. Something on that webpage resulted in the redirect to the exploits so I took a closer look at it. In the cached xmen-steel_claws-for-sale webpage’s code showed there was an injected iframe pointing to the dabstepinattack.php page on marcelleoonard.aa.am domain.

In Closing

Systems will visit the thousands of websites compromised in mass injection attacks. If these systems have client-side vulnerabilities then mostly likely some of them will cross our paths due to them getting infected. To tie the initial infection vector back to a mass injection campaign all you need to do is locate the injected iframe at the top or bottom of the cached webpage.

The one thing I like about sharing is when someone opens your eyes about additional information in an artifact you frequently encounter. Harlan has been posting about prefetch files and the information he shared changed how I look at this artifact. Harlan’s first post Prefetch Analysis, Revisited discussed how the artifact contains strings -such as file names and full paths to modules that were either used or accessed by the executable. He also discussed how the data can not only provide information about what occurred on the system but it could be used in data reduction techniques. One data reduction referenced was searching on the file paths for words such as temp. Harlan’s second post was Prefetch Analysis, Revisited...Again... and he expanded on what information is inside prefetch files. He broke down what was inside a prefetch from one of my test systems where I ran Metasploit against a Java vulnerability. His analysis provided more context to what I found on the system and validated some of my findings by showing Java did in fact access the logs I identified. Needless to say, his two posts opened my files to additional information inside prefetch files. Additional information I didn’t see the first the first time through but now I’m taking a second look to see what I find and to test out how one of Harlan's data reduction techniques would have made things easier for me.

Validating Findings

I did a lot of posts about Java exploit artifacts but Harlan did an outstanding job breaking down what was inside one of those Java prefetch files. I still have images from other exploit artifact testing so I took a look at prefetch files from an Adobe exploit and Windows Help Center exploit. The Internet Explorer prefetch files in both images didn’t contain any references to the attack artifacts but the exploited applications’ prefetch files did.

The CVE-2010-2883 (PDF Cooltype) vulnerability is present in the cooltype.dll affecting certain Adobe Reader and Acrobat versions. My previous analysis identified the following: the system had a vulnerable Adobe reader version, a PDF exploit appeared on the system, the PDF exploit is accessed, and Adobe Reader executed. The strings in the ACRORD32.EXE-3A1F13AE.pf prefetch file helped to validate the attack because it shows that Adobe Reader did in fact access the cooltype.dll as shown below.

\DEVICE\HARDDISKVOLUME1\PROGRAM FILES\ADOBE\READER 9.0\READER\COOLTYPE.DLL

The prefetch file from the Windows Help Center URL Validation vulnerability system showed something similar to the cooltype.dll exploit. The Seclists Full disclosure author mentioned that Windows Media Player could be used in an attack against the Help Center vulnerability. The strings in the HELPCTR.EXE-3862B6F5.pf prefetch file showed the application did access a Windows Media Player folder during the exploit.

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\APPLICATION DATA\MICROSOFT\MEDIA PLAYER\

Finding Malware Faster

Prefetch files provided more information about the exploit artifacts left on a system. By itself this is valuable enough but another point Harlan mentioned was using the strings inside prefetch files for data reduction. One data reduction technique is to filter on files' paths. To demonstrate the technique and how effective it is at locating malware I ran strings across the prefetch folder in the image from the post Examining IRS Notification Letter SPAM. (note, strings is not the best tool to analyze prefetch files and I’m only using the tool to illustrate how data is reduced) I first ran the following command which resulted in 7,905 lines.

strings.exe –o irs-spam-email\prefetch\*.pf

I wanted to reduce the data by only showing the lines containing the word temp to see if anything launched from a temp folder. To accomplish this I ran grep against the strings output which reduced my data to 84 lines (the grep -w switch matches on whole word and –i ignores case).

strings.exe –o irs-spam-email\prefetch\*.pf | grep –w –i temp

The number of lines went from 7,905 down to 84 which made it fairly easy for me to spot the following interesting lines.

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TEMPORARY DIRECTORY 1 FOR IRS%20DOCUMENT[1].ZIP\IRS DOCUMENT.EXE

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\PUSK3.EXE

Using one filtering technique enabled me to quickly spot interesting executables in addition to the possibly finding the initial infection vector (a malicious zip file). This information was obtained by running only one command against the files inside a prefetch folder. In hindsight, my original analysis on the prefetch files was fairly limited (executable paths, runcounts, and filenames) but going forward I'll look at this artifact and the information they contain in a different light.

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.

Artifact Name

Exploit Artifacts for CVE-2010-2883 (PDF Cooltype) Vulnerability

Attack Vector Category

Exploit

Description

Vulnerability present in the Cooltype.dll affects Adobe Reader and Acrobat versions 9.x before 9.4 and 8.x before 8.2.5 on Windows and Mac OS X systems. Exploitation allows remote attackers to execute arbitrary code or cause a denial of service.

Attack Description

This description was obtained using the Mitre and ISS X-Force Database references.

1. Create a PDF document with a “long field in a Smart Independent Glyphlets (SING) table in a TTF font".

2. Open the PDF document on the target system.

Exploits Tested

Metasploit v3.5 windows\fileformat\adobe_cooltype_sing

Target System Information

* Windows XP SP3 Virtual Machine with Adobe Reader v9.3 using administrative user account (No PDF files were opened on system prior to test)

* Windows XP SP3 Virtual Machine with Adobe Reader v9.3 using non-administrative user account (No PDF files were opened on system prior to test)

* Windows XP SP3 Virtual Machine with Adobe Reader v9.3 using administrative user account (Non-malicious PDF file was opened on system prior to test)

Different Artifacts based on Administrator Rights

Yes, MFT entry for "Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe" was modified when user account had administrative privileges.

Different Artifacts based on Tested Software Versions

Not tested

Potential Artifacts

The potential artifacts include the CVE 2010-2883 exploit and the changes the exploit causes in the operating system environment. The artifacts can be grouped under the following three areas:

    * PDF Document Creation

    * References of the PDF Document Being Accessed

    * Indications of the Vulnerable Application Executing

note: the documenting of the potential artifacts attempted to identify the overall artifacts associated with the vulnerability being exploited as opposed to the specific artifacts unique to the Metasploit. As a result, the actual artifact storage locations and filenames are inside of brackets in order to distinguish what may be unique to the testing environment.

    * PDF Document Creation

note: the location of the PDF document will vary depending on the delivery mechanism involved

         - PDF document being created on the system in the timeframe of interest. [C:\msf-cooltype.pdf which VirusTotal confirmed as being the exploit]

    * References of the PDF Document Being Accessed

note: the artifacts may vary depending on the method used to access the document. For example, Windows Explorer will leave different artifacts as compared to a web browser involved in a drive-by download. The testing involved opening the document using Windows Explorer.

         - Web browser history with entries containing the PDF document. Entries may involve HTTP or file. [Internet Explorer entry file:///C:\msf-cooltype.pdf]

         - Link files of the PDF document being opened. [C:\Documents and Settings\Administrator\Recent\msf-cooltype.pdf.lnk]

        -User registry keys with values containing the PDF document. [HKCU-\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.pdf. This key had the name of the PDF in the MRU]

    * Indications of the Vulnerable Application Executing

         - Prefetch files of the vulnerable application executing. [C:\WINDOWS\Prefetch\ACRORD32.EXE-3A1F13AE.pf and C:\WINDOWS\Prefetch\ACRORD32INFO.EXE-242CE4AA.pf]

         - Registry modifications involving the vulnerable application. [modifications made to subkeys under HKCU-\Software\Adobe\Acrobat Reader\9.0\]

         - Folder activity involving the vulnerable application. [C:\Program Files\Adobe\Reader 9.0, C:\Documents and Settings\Administrator\Application Data\Adobe\Acrobat\9.0, or C:\Documents and Settings\Administrator\Local Settings\Application Data\Adobe\Acrobat\9.0]

         - Temp files being created. [C:\Documents and Settings\Administrator\Local Settings\Temp\A9R9E95.tmp. The file signature indicated it was a PDF.]

Timeline View of Potential Artifacts

The images below shows the above artifacts in a timeline of the file system from the Windows XP SP3 system that had a non-malicious PDF file opened on the system prior to test. The timeline includes the relevant registry and Internet explorer history entires.











References

Vulnerability Information

     Mitre’s CVE http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-2883

Other Information

     Metasploit Blog Post http://blog.metasploit.com/2010/09/return-of-unpublished-adobe.html

     Mila's Contagio Malware Dump David Leadbetter Post

     ISS X-Force Database http://xforce.iss.net/xforce/xfdb/61635

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. ;)