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.

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?

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.

I would like to ask, in the image where you show Java executing (source: Pre), just below the entries for Java in your timeline, there's a reference to the LastWrite time for the HKEY_USER\Software\Microsoft\Direct3D\MostRecentApplication key...can you share what the value is within that key? It may be 'iexplore.exe', but it may also point to something else...

A couple of things I saw in the timeline that can be misleading:

- Registry key LastWrite times listed as "MACB" is incorrect...it should be "M...".

- Those entries listed as "Reg - Shim" should have "M..." for the time field, as well, as that's what the time represents, unless your target system is XP, it could be different