Malicious scripts hidden inside JavaScript files – a new trick used by attackers

We have written many blogs on malicious iframes or script injection in dynamic webpages. The malicious iframes/script tags were typically being injected at the bottom of webpages or after html tags such as , etc. Often, they are very easy to find once you know that site is infected. You can easily able to see the injected malicious code inside the webpages just by opening the source of the page and inspecting the typical injection locations. Recently however, we are seeing another trick used by attackers whereby malicious iframes/script tags are being injected into static JavaScript files rather than on page itself. These are static files in the sense they are JavaScript libraries used for various purposes. This trick is used by the attacker so that it will be difficult to identify the injected iframe simply by inspecting the only source of the page. It also allows multiple pages to be infected, while only injecting content into a single location. Let’s walk through a live example of an infected website. Here is a screenshot of the website:

Interestingly, at present, Firefox does not provide any warning about the threat while Google Chrome does, despite the fact that both leverage Google SafeBrowsing block lists. Here is the block message from Chrome,

Chrome blocks this website with message saying “this site contains elements from the site ‘malepad.ru’ which appears to host malware”. I initially searched for malicious iframe/script tags inside the page source but could not identify it. The source of page looked clean at first glance. I then saw some JavaScript files being used inside the webpage however, they too appeared legitimate. Here is the source of the main page,

I then inspected the source code of the JavaScript files and found that they had clearly been altered. Let’s look at “blockcurrencies.js” as an example:

The malicious script code is being injected at the bottom of the JavaScript file. If you look at the above Chrome block image, you will find that this is the site present in the Chrome message. Every JavaScript file present inside the main webpage was injected with malicious script tags like the one shown above. Interestingly, we have also found the following malicious code present in JavaScript files on alternate sites:It is interesting to study the various tricks and techniques attackers use to hide their malicious code. We have seen an increase in attacks where malicious content is being injected into static JavaScript pages.

This is a good lesson, to not simply inspect the source code of the main page when looking for malicious content.

Have you checked your web files?

Umesh

Spam SEO and adware

It seems that Blackhat spam SEO is getting more and more effective, allowing attackers to spread malware and adware. Spammers can now easily infect thousands of websites in order to rank high in popular searches and trick users into surfings to their malicious pages.

Attackers are never short of ideas for disguising their malware or adware as legitimate software. While following some of the spam links I recently discovered, I stumbled upon a free video site which attempts to get users to install both the Zango and LoudMo adware.

First, an ad for VLC, a popular open-source video player, pops up. However, the executable downloaded is actually Zango adware. Only 8 antivirus vendors out of 42 find this particular piece of adware. This malicious file is only 20KB, compared to the official, and clean,  18.6MB official executable file for VLC.

This VLC executable comes with a spyware

Then, at another site, in order to watch a movie, a user is prompted to download the Bing toolbar. This download however actually contains the Loudmo spyware (caught by only 10 antivirus vendors) that I  had mentioned in a previous post.

Second attempt to install an adware

As always, users should be aware to not download any software outside of official websites, and should not rely on their antivirus to sort out the bad from the good.

These adware attacks are a major source of revenue for websites that distribute copyrighted material such as pirated novies, as they cannot participate in legitimate advertising networks. I've found several websites offering free movie downloads which linked to these 2 sites.

-- Julien

Wikileaks: A Case Study in Internet Rubber-Necking (Gawking)

Background

Wikileaks.org has been the subject of some major news stories in mid-2010. The site is geared toward sharing information that was previously unknown in the public eye, usually obtained through insider contacts (leaks, whistle-blowers, disgruntled employees, etc.). I won’t rehash the history of Wikileaks and all of its related stories, I’ll leave that for the reader to research if they haven’t already done so. These are the prominent Wikileaks stories from mid-2010:

• April 5, 2010 – release of “Collateral Murder” video (reference)
• June 7, 2010 – arrest of Army Spc. Bradley Manning
• July 25, 2010 – release of “Afghan War Diary” (reference)
  

A more detailed timeline of these and other Wikileaks events can be found on Cryptome and Wikipedia.

Internet Traffic: The Wikileaks “Pandemic”

For those unfamiliar with Zscaler, Inc. – we are a security software-as-a-service (SaaS) vendor. I won’t detail our capabilities here (if interested visit our website), but I will say that we have a large and geographically diverse population of enterprise users browsing the web through our solution: several million users across a large number of countries. This puts Zscaler in a unique position to conduct analyses, stats, and trends for a variety of events on the web (e.g., malware threats). In the case of this story, the event is “Internet Rubber-Necking” or “Gawking.” In other words, the population hears about the Wikileaks story on the news, from their friends, etc. and have to go check it out for themselves.

To conduct some basic statistics for this event, I first focused in on the April and June events and pulled logs for traffic to wikileaks.org from April-June and extracted the number of unique client IP addresses seen visiting the site per day. This provided a basic measure of popularity throughout Q2 2010.

(April - June 2010 Wikileaks traffic)

The results show spikes in visiting IPs on:

• April 5 – 8
• June 7 – 9, 11
• June 22
  

The largest spike was April 6^th, where 25% of the total unique IPs seen visiting the site for the quarter were seen visiting the site on this day. The April spike corresponds to the “Collateral Murder” video release. Comparing the spike to the days leading up to the event, shows that the initial spike was roughly a 2000% increase in daily visits. The spike follows a similar pandemic pattern (see below): (1) spike at the onset of the event, (2) secondary spike from those coming in contact with (learning of) the event, (3) drop-off from saturation of the population, and (4) return to slightly elevated normal levels.

(1918 Flu Pandemic - reference)

The spikes in early June are directly related to Manning’s arrest on June 7th and the corresponding press briefing from the Dept. of State on June 11 on the incident. The spike on June 22, 2010 corresponds to Wikileaks announcement of its plans to release documents related to a U.S. airstrike that killed Afghan civilians in 2009 (reference). Eventually it released a corpus of documents July 25, 2010 entitled “Afghan War Diary.”

These documents resulted in much more of a traffic increase. The below chart averages the daily client visits to Wikileaks from March – July 2010 and charted the percentage increase or decrease over time:

(March - July 2010 Wikileaks traffic)

Needless to say, there was a huge spike throughout 7/25 – 7/31 corresponding with the Afghan documents release. To be more specific, 7/25, the release of the documents, saw a 242% increase above average and 7/26 over a 2300% increase above average. In comparison, the April 6th spike for the ‘Collateral Murder’ video was around a 407% increase above average.

Below shows Zscaler’s daily average of unique IPs visiting Wikileaks each month. Both April and June had over twice that of March and May, but July had four times that of April and June.

(2010 Wikileaks traffic)

The following chart shows the geographic distribution of the unique client IPs / organizations visiting Wikileaks. 51.5% of the client IPs seen visiting Wikileaks were from the United States, and Australia, Germany, France, and India made up slightly over 25%.

(Country Breakdown of Wikileaks Visitors)

Purpose / Future Work

Aside from this just being interesting statistics about a noteworthy Internet event, it provides us with some stats/trends to identify a micro pandemic or viral, user-driven event on the Internet. By studying this and other noteworthy events on the Internet, helps us to define models (algorithms) for early detection and prediction of similar future events. Early detections and predictions of these events could be leveraged for a variety of reasons, such as, identification and prioritization of news, stories, and Internet resources (e.g., caching and routing). Google Trends provides a window of such spikes in their search topics. This information can be valuable in advertising and marketing (SEO). It may also be possible to identify and distinguish between an event like the Wikileaks event and a malware attack.

There are several differences between a malware attack and the Wikileaks event on the Internet – most notably was the voluntary, user-driven nature of the traffic to Wikileaks. In comparison, malicious events like the mass SQL injection / robint.us malware from this past June are not voluntary. The involuntary nature means a larger and wider user base is impacted, and depending on the infection vector can spread more quickly than a voluntary event.

SEO spam attacks are getting harder to spot

Spam SEO pages used to be very easy to spot: no Javascript, no style sheets, no images, etc. and  usually just a single link. They only text on the page relevant to the spam was generally a set of short paragraphs, as shown below:

Typical old-style SEO spam page

Recently however, these pages have been changed to look more like a regular web page. They look like a web page taken out of a news site, with multiple columns, images, links to legitimate sites, Javascript, etc. You have to look closer to realize that the text does not make sense - words are cut in the middle, images are not related to the content, and the style is not quite right (misalignment, overflows, etc.)

New style of SEO spam pages on the hacked site brooklyngoesveg.com

These pages are much harder to recognize as computer-generated spam. At first glance, they look like legitimate pages. Fortunately, spammers still use the same type of URLs. The screenshot above was taken from hxxp://www.brooklyngoesveg.com/xmlrpc.php/?showc=williams+syndrome, where the search term "Williams syndrome" is part of the query string.

Another common layout for spam pages mimics MTV's website:

Spam page looks like MTV's site

Spammers and attackers are constantly innovating to stay under the radar.  This is another step to hide their malicious intent from the search engines.

-- Julien

Analysis of recent "Trojan Tacorti" malware run

This summary is not available. Please click here to view the post.

PDF Exploit: Number of pages is the Key

PDF exploits targeting a number of recent Adobe vulnerabilities exist in the wild. In the past, we have seen number of different obfuscation and decoding techniques being used by the exploits to avoid anti-virus detection. Increasingly, PDF exploits are becoming more and more sophisticated. Recently, we came across one PDF exploit which appeared to be targeting recent Adobe vulnerabilities, but it wasn’t clear which ones. Interestingly, the attacker had used a key to decode his malicious code. Here is the screenshot of malicious encoded JavaScript inside the one of the objects within the PDF file,

I decoded this suspicious object using the pdf-parser tool and found obfuscated JavaScript code inside. Here is what the decoded code looked like:

The code is heavily obfuscated to hide the actual exploit code. There were 2 calls to the “eval()” function. The first one extracted one variable (i.e. K9U8Zm8NS4) from another (i.e. KeNJ148) which is then XOR’ed with 2 other variables which are nothing but some secret key values. Confused? Hang tight. After that there is a call to a “String.fromCharCode” function on the final XOR’ed variable (i.e. e208xh). After initial analysis of the code, I pasted the code into Malzilla to see the final output of the obfuscated JavaScript code and found that Malzilla was unable to decode it. Something wasn’t going right for Malzilla.

I figured it out that there are some strings or function like “this.numPages” used inside the code and because of that, Malzilla was unable to decode it. If you observe, this is the first key (i.e. l46bQ8A) which is used to XOR with the original variable (i.e. e208xh). I changed the variable which was using the “this.numPages” function manually to integers such as 1, 2 etc. and tried decoding it once again. Finally, Malzilla started decoding it but the output was still not legible – I’d clearly missed some additional decoding routines. I then realized that there were 2 keys being used for XORing - one was hard coded with value “189” while the other was taking a value from the “this.numPages” function. This function returns the number of pages present inside the PDF file. That means whatever values I was passing to the variable manually, wasn’t correct and the script was unable to decode it. I re-opened the PDF file to search for object which contained the number of pages used inside the PDF and found the exact count,

There are “20” pages inside this malicious PDF file and this is turned out to be the first key which was used for XORing with the original variable. Now I changed the variable value to “20” and tried to decode the JavaScript. Finally, everything went according to plan and malzilla decoded the JavaScript into readable code. This was a rather unique trick used by the attacker to encode/decode the malicious JavaScript leveraging the “this.numPages” function. Once that challenge was solved, the rest was easy to understand as the skeleton of the final code was using a familiar heap spray technique and targeting known Adobe vulnerabilities. Here is the final decoded JavaScript:

The exploit was targeting 3 different vulnerabilities.

1) mediaNewplayer CVE-2009-4324

2) collectEmailInfo CVE-2007-5659

3) CollabgetIcon CVE-2009-0927

The detection for this PDF file remains very poor. Here is the Virustotal result for this file – currently, only 6 of 42 AV vendors detect it. This is a really interesting case as the “key” is actually a component of the PDF file and this is deliberately used by the attacker so that the manual decoding becomes difficult for researchers. Even Webpawet failed to decode it properly. This time attacker has used “number of pages” inside the PDF as a key to decode the malicious script code. I expect that we’ll see similar tricks going forward.

What’s your key?

Umesh

SEO spammers go after Firefox users

Most malicious pages used in spam SEO attacks target Windows users, by showing what looks like a Windows Antivirus screen running, or Internet Explorer with pages displaying fake IE warnings about outdated flash versions or missing video codecs.

But attackers are now disguising their malicious executables as Firefox updates. The malicious pages use the same theme as the official Firefox website - same background, images, etc.

Malicious page warn about outdated Firefox version

At the time of writing, the site is not blocked by Google Safe Browsing, and the detection rate of the malicious executable ff-update.exe is very low: only 6 antivirus vendors out of 42 find it to be malicious.

Our new Firefox extension Search Engine Security does protect against this attack and most other spam SEO threats. You can install it by clicking on the image below:

If you use Internet Explorer, you get redirected to a different domain with the "usual" fake AV screen.

Fake AV page for Internet Explorer users

Attackers are widening their range of targets, and keep innovating to find more potential victims.

-- Julien