Finding an Injected iframe

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 Blogand 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.

Read More

Compromise Root Cause Analysis Model

A common question runs through my mind every time I read an article about: another targeted attack, a mass SQL injection attack, a new exploit being rolled into exploit packs, or a new malware campaign. The question I ask myself is how would the attack look on a system/network from a forensic perspective. What do the artifacts look like that indicates the attack method used. Unfortunately, most security literature doesn’t include this kind of information for people to use when responding to or investigating attacks. This makes it harder to see what evidence is needed to answer the questions “how” and “when” of the compromise. I started researching Attack Vector Artifacts so I could get a better understanding about the way different attacks appear on a system/network. What started out as a research project to fill the void I saw in security literature grew into an investigative model one can use to perform compromise root cause analysis. A model I’ve been successfully using for some time to determine how systems became infected. It’s been awhile since I blogged about attack vector artifacts so I thought what better way to revisit the subject than sharing my model.

DFIR Concepts

Before discussing the model I think it’s important to first touch on two important concepts. Locard’s Exchange Principle and Temporal Context; both are key to understanding why attack vector artifacts exist and how to interpret them.

Locard’s Exchange Principle states when two objects come into contact, something is exchanged from one to the other. Harlan’s writing about the Locard’s Exchange Principle is what first exposed me to how this concept applies to the digital world. The principle is alive and well when an attacker goes after another system or network; the exchange will leave remnants of the attack on the systems involved. There is a transfer between the attacker’s systems with the targeted network/systems. An excellent example of the Locard’s Exchange Principle occurring during an attack can be seen in my write-up Finding the Initial Infection Vector. The target system contained a wealth of information about the attack. There was malware, indications Java executed, Java exploits, and information about the website that served up the exploits. All this information was present because the targeted system came into contact with the web server used in the attack. The same will hold true for any attack; there will be a transfer of some sort between the systems involved in an attack. The transfer will result in attack vector artifacts being present on the targeted network in the attack.

Temporal Context is the age/date of an object and its temporal relation to other items in the archaeological record (as defined by my Google search). As it relates to the digital world, temporal context is comparing a file or artifact to other files and artifacts as it relates to a timeline of system activity. When there is an exchange between attacking and targeted systems the information left on the targeted network will be related. The information will be very closely related within a short timeframe. Temporal Context can also be seen in my post Finding the Initial Infection Vector. The attack activity I first identified was at 10/16/2011 6:50:09 PM and I traced it back to 10/8/2011 23:34:10. This was an eight day timeframe where all the attack vector artifacts were present on the system. It’s a short timeframe when you take into consideration the system had been in use for years. The timeframe grows even smaller when you only look at the attack vector artifacts (exploit, payload, and delivery mechanisms). Temporal Context will hold true for any attack resulting in the attack vector artifacts all occurring within a short timeframe.

What Are Attack Vector Artifacts?

In my previous post (Attack Vector Artifacts) I explained what an attack vector is and the three components it consists of. I think it’s important to briefly revisit the definition and components. An attack vector is a path or means somebody can use to gain access to a network/system in order to deliver a payload or malicious outcome. Based on that definition, an attack vector can be broken down into the following components: delivery mechanisms, exploit, and payload. The diagram below shows their relationship.

Attack Vector Model

At the core is the delivery mechanism which sends the exploit to the network or system. The mechanism can include email, removable media, network services, physical access, or the Internet. Each one of those delivery mechanisms will leave specific artifacts on a network and/or system indicating what initiated the attack.

The purpose of the inner delivery mechanism is to send the exploit. An exploit is something that takes advantage of a vulnerability. Vulnerabilities could be present in a range of items: from operating systems to applications to databases to network services. When vulnerabilities are exploited it leaves specific artifacts on a network/system and those artifacts can identify the weakness targeted. To see what I mean about exploit artifacts you can refer to the ones I documented for Java (CVE-2010-0840 Trusted Methods and CVE-2010-0094 RMIConnectionImpl) , Adobe Reader (CVE-2010-2883 PDF Cooltype), Windows (Autoplay and Autorun and CVE 2010-1885 Help Center), and social engineering (Java Signed Applet Exploit Artifacts).

A successful exploit may result in a payload being sent to the network or system. This is what the outer delivery mechanism is for. If the payload has to be sent to then there may be artifacts showing this activity. One example can be seen in the system I examined in the post Finding the Initial Infection Vector. The Java exploit used the Internet to download the payload and there could have been indications of this in logs on the network. I said “if the payload has to be sent” because there may be instances where the payload is a part of the exploit. In these cases there won’t be any artifacts.

The last component in the attack vector is the desired end result in any attack; to deliver a payload or malicious outcome to the network/system. The payload can include a number of actions ranging from unauthorized access to denial of service to remote code execution to escalation of privileges. The payload artifacts left behind will be dependent on what action was taken.

Compromise Root Cause Analysis Model

To identify the root cause of an attack you need to understand the exploit, payload, and delivery mechanisms artifacts that are uncovered during an examination. The Attack Vector Model does an outstanding job making sense of the artifacts by categorizing them. The model makes it easier to understand the different aspects of an attack and the artifacts that are created by the attack. I’ve been using the model for the past few years to get a better understanding about different types of attacks and their artifacts. Despite the model’s benefits for training and research purposes, I had to extend it in order to use it for investigative purposes by adding two additional layers (source and indicators). The end result is the Compromise Root Cause Analysis Model as shown below.

Compromise Root Cause Analysis Model

At the core of the model is the source of the attack. The source is where the attack originated from. Attacks can originate from outside or within a network; it all depends on who the attacker is. An external source is anything residing outside the control of an organization or person. A few examples are malicious websites, malicious advertisements on websites, or email. On the opposite end are internal attacks which are anything within the control of an organization or person. A few examples include infected removable media and malicious insiders. The artifacts left on a network and its systems can be used to tell where the attack came from.

The second layer added was indicators. The layer is not only where the information and artifacts about how the attack was detected would go but it also encompasses all of the artifacts showing the post compromise activity. A few examples of post compromise activity includes: downloading files, malware executing, network traversal, or data exfiltration. The layer is pretty broad because it groups the post compromise artifacts to make it easier to spot the attack vector artifacts (exploit, payload, and delivery mechanisms).

Compromise Root Cause Analysis Model In Action

The Compromise Root Cause Analysis Model is a way to organize information and artifacts to make it easier to answer questions about an attack. More specifically to answer: how and when did the compromise occur? Information or artifacts about the compromise are discovered by completing examination steps against any relevant data sources. The model is only used to organize what is identified. Modeling discovered information is an ongoing process during an examination. The approach to using the model is to start at the indicators layer then proceed until the source is identified.

The first information to go in the indicators layer is what prompted the suspicion that an attack occurred. Was there an IDS alert, malware indications, or intruder activity. The next step is to start looking for post compromise activity. There will be more artifacts associated with the post compromise then there will be for the attack vectors. While looking at the post compromise artifacts keep an eye out for any attack vector artifacts. The key is to look for any artifacts resembling a payload or exploit. Identifying the payload can be tricky because it may resemble an indicator. Take a malware infection as an example. At times an infection only drops one piece of malware on the system while at other times a downloader is dropped which then downloads additional malware. In the first scenario the single malware is the payload and any artifacts of the malware executing is also included in the payload layer. In the second scenario the additional malware is indicators that an attack occurred. The dropper is the payload of the attack. See what I mean; tricky right? Usually I put any identified artifacts in the indicators layer until I see payload and exploit information that makes me move it into the payload layer.

After the payload is identified then it’s time to start looking for the actual payload and its artifacts. The focus needs to be on the initial artifacts created by the payload. Any addition artifacts created by the payload should be lumped into the indicators layer. To illustrate let’s continue to use the malware scenario. The single malware and any indications of it first executing on the system would be organized in the payload layer. However, if the malware continued to run on the system creating additional artifacts – such as modifying numerous files on the system -then that activity goes into the indicators layer.

The outer delivery mechanism is pretty easy to spot once the payload has been identified. Just look at the system activity around the time the payload appeared to see it. This is the reason why the payload layer only contains the initial payload artifacts; to make it easier to see the layers beneath it.

Similar to the delivery mechanism, seeing the exploit artifacts is also done by looking at the system activity around the payload and what delivered the payload to the system. The exploit artifacts may include: the exploit itself, indications an exploit was used, and traces a vulnerable application was running on the system.

The inner delivery mechanism is a little tougher to see once the exploit has been identified. You may have a general idea about where the exploit came from but actually finding evidence to confirm your theory requires some leg work. The process to find the artifacts is the same; look at the system activity around the exploit and inspect anything of interest.

The last thing to do is to identify the source. Finding the source is done a little different then finding the artifacts in the other layers. The previous layers require looking for artifacts but with the source layer it involves spotting when the attack artifacts stop. Usually there is a flurry of activity showing the delivery mechanisms, exploit, and payload and at some point the activity just stops. In my experiences, this is where the source of the attack is located. As soon as the activity stops then everything before the last identified artifact should be inspected closely to see if the source can be found. In some instances the source can be spotted while in others it’s not as clear. Even if the source cannot be identified at least some avenues of attack can be ruled out based on the lack of supporting evidence. Lastly, if the source points to an internal system then the whole root cause analysis process starts all over again.

Closing Thoughts

I spent my personal time over the past few years helping combat malware. One thing I always do is determine the attack vector so I could at least provide sound security recommendations. I used the compromise root cause analysis process to answer the questions “how” and “when” which thus enabled me to figure out the attack vector. Besides identifying the root of a compromise there are a few other benefits to the process. It’s scalable since it can be used against a single system or a network with numerous systems. Artifacts located from different data sources across a network are organized to show the attack vector more clearly. Another benefit is the process uses layers. Certain layers may not have any artifacts or could be missing artifacts but the ones remaining can still be used to identify how the compromised occurred. This is one of the reasons I’ve been able to figure out how a system was infected even after people took attempts to remove the malware while in the process destroying the most important artifacts showing how the malware got there in the first place.

Read More

Examining IRS Notification Letter SPAM

A forensicator lives on the 10th floor of a building. Every morning he rides down the elevator to the ground floor and leaves the building to go to his forensic lab. Every night he comes home after spending the day finding evil and gets on the elevator. If it was raining then he takes the elevator to the 10th floor. If the weather is good then he takes the elevator to the 7th floor and walks to the 10th floor using the stairs. Why does he do this?

The forensicator in the elevator is an analogy to a malware infected system. Trying to answer the above riddle cannot be done without looking at the man in his environment (the building). Picturing the forensicator in the building and everything that is in the elevator will shed light on to question of why he takes the stairs. This is similar to answering the question of how malware infected a system. The question can’t be answered without looking at the malware in its environment (the affected system) and examining the other activity on the system around the time the malware appeared. Take the antivirus write-ups as an example. The majority of the write-ups (I’ve read) analyze the malware outside of the environment where it was located. As a result, the write-ups provide vague information on the initial infection vector used such as the statement “distributed through spam campaigns and drive-by downloads, though given its versatility, other vectors may also be utilized”. The description doesn’t shed much light on how a specific system became infected since pretty much all of the bases are covered (SPAM, drive-bys, or some other method). If you have ever wondered what the artifacts are of malware being delivered through SPAM then the rest of this article will be of interest.

Someone was nice enough to send me a SPAM email last month (sarcasm doesn’t come off the some way as the spoken word). The SPAM was a mass mailing so I was probably just one recipient out of thousands but at least the email gave me something to analyze. The examination of this email will first explain the user’s actions followed by the DFIR practitioner’s examination.

Accessing Email

        User Perspective

The user fires up a web browser to check their email. Internet Explorer loads the home page before the user navigates to Yahoo email. A few emails are checked before the user comes across the message below.

The user overlooks the indications that the email is SPAM such as the misspellings, punctuation errors, and even a run-on sentence (see the picture below to see what was missed). They proceed to read the notification letter alerting them to some kind of issue with their tax return.

      
        DFIR Perspective

The forensicator was slowly making their way through a system timeline when there was activity involving Internet Explorer. There were modifications made to few Internet Explorer folders in the Administrator user account’s profile and the user account visited a Microsoft’s webpage.

After weeding through all of the web activity related to the Microsoft webpage he noticed the user went to Yahoo’s webpage and accessed their webmail.

The browser history and cache showed that the user spent some time using Yahoo email.

Opening the Email Attachment

        User Perspective

Worried there might be an issue with their tax return the user decides to open the email attachment. The user felt more comfortable opening the attachment since Norton Antivirus indicated it was virus free.

The attachment doesn’t initially open a document but instead opens a new window showing a file with the name IRS document.exe. Even though file extensions weren’t hidden by Windows Explorer the user didn’t notice the exe extension since they were too distracted worrying about not receiving their tax refund.

        DFIR Perspective

The Internet activity indicated the user was still accessing their Yahoo email when an entry at 06/20/2011 22:10:00 showed the user downloading a zip file.

The file IRS%20document[1].zip was created in the folder \Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\ one second after the browser entry made a reference to a zip file in Yahoo email.

Aftermath of Accessing Email Message

        User perspective

The user double clicks the file named “IRS document.exe” thinking the file contains the list of missing documents but nothing visually occurs. A document doesn’t open, no error messages popup, and the list of missing documents isn’t shown. The user closes the attachment’s Explorer window at 06/20/2011 10:22 and continues surfing the Internet. This is the point in the story where the user perspective ends. The story tried to illustrate how someone could be tricked into opening the attachment in the SPAM email.

        DFIR perspective

The forensicator continued to work his timeline when there was a flurry of activity involving executables. The first artifact was a prefetch file for a program - IRS document.exe - (MD5 hash 77065d6545b0226ccf66ce75d5254bfa and link to the VirusTotal report) that was the executable inside of the zip attachment. 10 seconds later the Windows svchost.exe executable ran before two additional malware were dropped on the system. The malware was PUSK3_~1.EXE (MD5 hash 541c25d26e8b1eb2d1a35cd52854650f and link to the VirusTotal report) and tmp75D5.tmp (MD5 hash 4bda47a91bea4ceccc6003a46aeb754d and link to the VirusTotal report). The executable activity is shown in the picture below.

The forensicator tied the execution of the IRS document.exe and pusk3.exe to the administrator account by finding the following information in the account’s MUICache registry key.

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\Temporary Directory 1 for IRS%20document[1].zip\IRS document.exe (IRS document)
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\pusk3.exe (ProcFeatures)

The last artifact pointing to a zip file occurred at 06/20/2011 10:22 and it was modifications being made to the HCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU registry key. A summary of the information in the BagMRU registry key is provided below.

* Bag: 9
* Registry Key modification Time [UTC]: 06/21/11 02:12:22.734
* Folder Name: IRS%20document[1].zip
* Full Path: Desktop\{CLSID_MyComputer}\C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\IRS%20document[1].zip\

Summary

The artifacts of malware being delivered through SPAM consisted of a user accessing email and opening a file around the same time. These artifacts hold true for malware being delivered via email even if the circumstances are different. At one point I examined an infected system which didn’t involve the IRS notification letter SPAM or web email. The activity on the system showed emails were assessed around the time a zip file was opened which happened just before the first piece of malware appeared on the system. All of the activity (and lack of other activity such as a drive-by download) lead me to conclude the malware was the result of a malicious email attachment. The specific artifacts in the examination varied slightly compared to what was discussed in this article but the general overall artifacts (email and file access prior to malware appearing) remained consistent.

Only examining malware from a system may not indicate email was the vehicle used deliver it. This is similar to antivirus write-ups about the analysis of malware which leave out information about how a specific computer became infected. The same line of thinking applies to the well known but slightly modified riddle at the beginning of the post. The riddle can’t be answered by solely analyzing the man outside of his building. Sure the analysis will reveal a lot of information about the man but it won’t explain why he is on the 7th floor of his building. The man needs to be analyzed in his building and the activity that occurred prior to him reaching the 7th floor should be reviewed. Trying to solve the riddle in this manner will reveal the answer of why he walks the stairs from the 7th to the 10th floor. The guy is too short to press the 10th floor elevator button and the highest he can reach - without an umbrella - is the 7th floor button. Like the man in the riddle, the activity on a system preceding the malware should be analyzed to determine if an email, drive-by, or some other means was used for the delivery.

Read More

Coming To A System Near You

According to Websense, there is a new trend where cyber criminals are spreading malware by taken advantage of Google Image search rankings. The attack involves poisoned pictures being displayed in Google’s image search results which when clicked redirects a user to a malicious site. As I was in the middle of putting together this write-up the Unmask Parasites blog had a great post, Thousands of Hacked Sites Seriously Poison Google Image Search Results, on how the websites involved in this attack were compromised and how the Google image search is poisoned while Brian Krebs wrote his own article on the subject Scammers Swap Google Images for Malware.

Those write-ups provided good information about the Google image search poisoning technique but I was approaching the topic from a different angle. My approach is from the perspective of the digital forensic practitioner who investigates this attack on a computer (client side). The Google image search is being leverage to spread malware but one important question I haven’t seen addressed is what are the potential artifacts that indicate the malware came from a Google image search. Along the same line of thinking, how are the artifacts of this delivery mechanism different than a Google web search, SPAM email, or a network share? The answer to these questions will be discussed in detail, hopefully before the Google image search attack comes to a system near you.

Simulation Setup

I tried to simulate how a user would perform Google searches for a selected topic. The topic I selected for my searches was the news of the day on 05/02/11 since the media coverage was everywhere. The topic seemed like a candidate for cyber criminals to try to leverage for spreading malware. I performed Google web and image searches using different word combinations until I had my first sign of an infection which was a warning message saying my unpatched Windows XP SP3 system was infected. I pretended to be a “normal” user to get rid of the warning by clicking cancel but in a short period of time the computer was held hostage by a fake antivirus program.

The Search Hit Culprit

I usually write my posts the way I conducted the examination. The malware is located then I work backwards in time examining the system activity to identify the initial infection vector. I’m taking a slightly different approach for this write-up by first explaining what the user saw followed by what the digital forensic practitioner would see during an examination. The potential artifacts of the Google image search being used to deliver a payload is shown through the DF perspective.

***** Heads Up: some of the URLs and domains mentioned in this write-up were malicious at one point in time so caution should be used if anyone tries to access them for their own research. All URLs were sanitized (or purposely only shown in images) to prevent anyone from accidently accessing the URLs. *****

User Perspective 1

Starting at 09:41:38 PM on 05/02/11 Google web and image searches were performed looking for sites and images about the news of the day. After about 20 minutes I performed the Google image search shown in the picture below. The highlighted image in the first row of search results is the image I access which lead to my system being infected.

DF Perspective 1

The above picture shows what a user sees when performing a Google image search. Different tools/techniques can be used to see what the search looks like on a system post mortem. The picture below shows the part of the timeline where the Google image search occurred and the images in the timeline were downloaded because of the search.

User Perspective 2

Clicking on the image highlighted in red resulted in the Internet Explorer window disappearing and being replaced by the warning message below.

It wasn’t too long until an Internet Explorer window appeared which was pointing to the malicious mlrglrqj.co.cc domain as illustrated below.

DF Perspective 2

At this point a Google image search resulted in the Internet Explorer browser being redirected to the mlrglrqj.co.cc domain where a fake online scanner was located. To see how this occurred forensically, the activity of the Google image being accessed needs to be examined. The portion of the timeline below shows the Google image URL that was accessed and this resulted in the image (line 151879) and a webpage (line 151880) being downloaded to the system. The timeline also shows a webpage, mlrglrqj.co[2].htm, being downloaded six seconds after the image was accessed (line 151881).

The URL in the above picture shows that when the Google image was accessed it brought the user to hxxp://pimpit.com/pr-Osama-Binladen-Dead.html (the imgrefurl variable contained the URL) and the webpage was using an image located at hxxp://theblackboxoffice.com/wp-content/uploads/2010/08/binladen_dead_alive.jpg (the imgurl variable contained the URL). Besides the image of interest, the only other file downloaded to the system before the browser redirect was an htm file named CA16L2DT.htm (this file was uploaded to jsunpack and can be viewed here). I examined CA16L2DT.htm to see if I could find in the file what caused the browser redirect. There was a reference to the t3.gstatic.com domain so I decided to look into the domain a little closer. The first Google search hit for the domain was a thread in a CNET forum titled “Phishing on Google Image Search - t3.gstatic.com/images” from July 2010. A person in the thread mentioned how Kaspersky antivirus was blocking the t3.gstatic.com domain due to it being a phishing attack. I did a search for the domain using the Malware Analysis Search which found malware samples associated with URLs that looked similar to the URL I found in the CA16L2DT.htm file (two of the malware sample reports can be found here and here). I wasn’t able to confirm what caused the browser redirect but I was able to determine the pimpit.com domain was involved with the redirect and a suspicious URL was present on pimpit.com’s webpage.

User Perspective 3

A “Windows Security Alert” appeared on the fake online scanner as shown below.

Shortly after the “Windows Security Alert” a program named XP Home Security appeared on the system. XP Home Security was the program holding the test system hostage.

DF Perspective 3

User Perspective 3 showed the payload of the attack wasn’t the fake online scanner but was the XP Home Security program which was successfully installed on the system. Continuing with the examination of the timeline, the activity on the system indicates the fake online scanner was still open as can be seen in the timeline below.

After the fake online scanner activity there was an Internet Explorer history entry for the following URL hxxp://mlrglrqj.co.cc/file/sc1/SecurityScanner.exe. Immediately after this URL was accessed there were a few registry modifications and the creation of a prefetch file indicating the SecurityScanner.exe program was executed. The picture below shows this activity in the timeline.

The timeline showed there were no indications of a software exploit (vulnerable programs executing, new files appearing on system ,etc..) on the system so it doesn’t appear an exploit was responsible for installing the malware. However, the administrator user account was responsible for the suspicious Internet activity so the account's recent activity was examined to shed light on how the malware was installed. I used Regripper to examine the user activity stored in the registry by parsing the administrator user account’s NTUSER.DAT registry hive. The MUICache registry key entry in the Regripper report shows the administrator user account executed the Security Scanner.exe and ieh.exe programs. The MUICache data for these programs are shown below:

Software\Microsoft\Windows\ShellNoRoam\MUICache
LastWrite Time Tue May 3 02:09:07 2011 (UTC)
     C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\4967GLU3\SecurityScanner[1].exe (SecurityScanner[1])
     C:\Documents and Settings\Administrator\Local Settings\Application Data\ieh.exe (ieh)

The lack of exploit artifacts and the MUICache registry key data indicate the administrator user account installed the malware which was exactly what happened. Further examination of the system identified the ieh.exe file as the program holding the system hostage and a VirusTotal scan of the file had a detection rate around 30%.

Potential Google Image Search Delivery Artifacts

At this point the user and digital forensics perspectives showed malware being installed on a system because of a Google image. The purpose of this post was to identify the potential artifacts of a Google image search being used to deliver malware which is why I stopped writing about the DF perspective once the malware was installed on the system. The portions of the timeline in my write-up showed had a lot of deleted files which helped explain how this attacked happened. Most likely deleted files will be over written since the system won’t be preserved within 30 seconds of being infected. However, the potential artifacts of the Google image search being used as the delivery mechanism may still be present on a system in the Internet browsing history. If the browser history artifacts occur around the time when malware firsts executes on a system (prefetch files, registry modifications, etc) then this may indicate the Google image search was used as the delivery method. For example, the malware executed on my test system around 10:03 PM on 05/02/11 and the Internet browsing history around this time showed a Google image being accessed followed by my Internet browser visiting a malicious domain. My browser history showing the Google image search is below.

Read More