Coming To A System Near You
Wednesday, May 11, 2011
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.
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.
Labels:
attack vectors,
delivery artifacts,
search poisoning
Posts
