Finding an Injected iframe

Sunday, July 21, 2013 Posted by Corey Harrell 3 comments
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.
Labels: , , , , , , ,

Finding Malware Like Iron Man Slide Decks

Friday, July 12, 2013 Posted by Corey Harrell 8 comments
This year I decided to step out of my comfort zone by presenting at conferences. I’m not a public speaker but I wanted to reach an audience beyond jIIr to provide information that may be helpful to combat malware. Specifically, a triage technique I have been using to find malware extremely fast (in less than 15 minutes). Below are my CFPs and links to the slide decks for the talk I gave at the SANs Digital Forensic and Incident Response Summit and New York State Cyber Security Conference.
 
FYI, both presentations are pretty much the same except for the lead in to the triage technique. I tailored that to the audience.
 

Finding Malware Like Iron Man – SANs DFIR Summit Version

 
When confronted with a system impacted by unknown malware time is of the essence. Triage needs to be done, information technology units need guidance, and the business needs to get back up and running. Questions have to be answered quickly: is the system infected, what malware is involved, and how did the infection occur in the first place. The available triage options all take time: scanning with antivirus, dumping and analyzing memory, performing live analysis, or performing a full post mortem examination. Mass malware makes triage even more challenging with new variants being released at a pace faster than signatures and IOCs are generated.
 
This presentation discusses how to perform triage on a system infected with malware in three examination steps. Within minutes not only can the majority of malware be detected but the initial infection vector can be identified as well. Topics will include: malware indicators, program execution artifacts, auto-start extensibility points (ASEPs) artifacts, and NTFS artifacts and then there will be a mock case study tying everything together.
 
Finding Malware Like Iron Man – SANs DFIR Summit Version slide deck can be downloaded from: PDF format or viewable online
 

Finding Malware Like Iron Man – NYS Cyber Security Conference Version

 
There are several common misconceptions about malware. One being that malware is just a nuisance, and is usually the product of bored teenagers sitting in their bedrooms. As a result, the typical response to a malware incident is to reimage, rebuild, and redeploy. The primary focus of this response is getting the system back into production as quickly as possible. Analysis of the malware and further research on the system is not a priority or goal.
 
Malware is not a nuisance or a minor disruption; it can pose significant risks to an organization. Malware is a tool that is leveraged by numerous threat groups to accomplish specific goals. When malware impacts a system the system does not become sick, it becomes compromised, and our incident response processes need to reflect this accordingly.
 
Root case analysis needs to be performed on systems impacted by malware to improve decision making. Questions need to be answered including: how did this happen, when did it happen, what (if anything) was taken, were we targeted, or what can be done to mitigate this from re-occurring. By re-imaging and re-deploying malware infected systems we no longer answer these questions, and we lose critical intelligence to better protect our organizations. The first step in root cause analysis is locating the malware.
 
In this technical presentation Corey will discuss three steps to locate malware on a computer running the Windows operating system. The topics will include the following: what is malware, why perform root cause analysis, program execution artifacts, persistence mechanism artifacts, NTFS artifacts, and freely available tools.
 
At the conclusion of the presentation, attendees will know how to perform three specific examination steps that help to identify common artifacts that point to where malware is located on the infected system.
 
Finding Malware Like Iron Man – NYS Cyber Security Conference Version slide deck can be downloaded from: PDF format or viewable online
 
Labels:
Subscribe to: Posts (Atom)