The Websense® ThreatSeeker® Network has detected that two Nepalese government websites, the National Information Technology Center (NITC) and the Office of the Prime Minister and Council Minister (nitc.gov.np and opmcm.gov.np respectively), have been compromised and injected with malicious code that tries to exploit the Java vulnerability CVE-2012-0507. The aim of this injection is to install, through successfully exploiting that Java weakness, a backdoor that is also dubbed "Zegost" on the systems of visitors to these websites.

This vulnerability (CVE-2012-0507) was also used in the Amnesty International UK website compromise and in the INSS website compromise that we reported a few months back. It's interesting to note that all those compromises had injected code that was taken from the Metasploit framework, served in clear form, and not obfuscated. Although the use of code from the Metasploit framework doesn't necessarily indicate a link between all the compromises, we found further common characteristics between the compromises of the Amnesty UK website and the Nepalese government website by analyzing the backdoor C&C points when we noticed that they connected to the same domain in China. 

The backdoor variant in this attack is known to have been used in other targeted attacks that were aimed at Uyghurs, Tibetans, and others in that area.

Websense customers are protected from these threats by ACE, our Advanced Classification Engine.

Technical Analysis

According to Cyberwarnews, in early 2012, the websites of Nepalese institutions, such as the police, suffered two other types of attacks mainly in the form of defacements and data leakage. But it's not just Nepal that has been affected. This region has recently seen a sequence of targeted attacks and APTs.

Below is the content of the Nepalese National Information Technology Center (NITC) Web page along with the injected code marked in red: 

The main page was injected with a Java JAR file loader which once rendered by the Web browser is executed and attempts to exploit the CVE-2012-0507 vulnerability. The name used for the Java class name ("msf.x.Exploit.class") and the content of the file confirmed that the code was taken from the Metasploit framework. If the exploit code in the JAR file has been successfully executed, the exploit shellcode downloads and runs the executable file named "tools.exe" on the impacted system (MD5: 3c7b7124f84cc4d29aa067eca6110e2f).

The ThreatSeeker Network was able to connect that same executable file dropped from nitc.gov.np (National Information Technology Center) to another Nepalese government website, opmcm.gov.np (Office of the Prime Minister and Council Minister website), as shown below:

The red, boxed URL is the website of the Office of the Prime Minister and Council Minister. We found out that this particular website was compromised this year, at least from May 9-15, to serve this same backdoor executable (MD5: 3c7b7124f84cc4d29aa067eca6110e2f):

The content that was injected between these dates at the website of the Office of the Prime Minister and Council Minister was identical to the code injected at the National Information Technology Center website, confirming that the same attack vector was used for both:

We detected that the dropped backdoor "tools.exe" (MD5: 3c7b7124f84cc4d29aa067eca6110e2f) is a variant "AD" of the backdoor Zegost. This backdoor toolkit or remote administration tool (RAT) has also been involved in other targeted attacks in Asia, according to an analysis by AlienVault in their research blog.

Thanks to the Websense ThreatScope® sandbox service, the C&C address was detected at "who.xhhow4.com," as shown in the picture below (for the complete sandbox report, click here). 

The domain "hhow4.com" was also used as a C&C point for the dropped backdoor served at the compromised Amnesty  UK website, where that variant specifically connected to the address at "shell.xhhow4.com" (for the complete sandbox report, click here).

Both C&Cs are hosted at IP address 184.22.171.216:

The domain "xhhow4.com" is hosted in China by a Web hosting company known as Hichina Zhicheng Technology Co., Ltd. The next image shows a Robtex DNS names graph analysis for that domain:

Once the backdoor is installed on the impacted system, it initiates connections from local TCP port 1320. The destination address is to the C&C  at "who.xhhow4.com" and uses remote TCP port 53  (usually the port reserved for the DNS Zone transfer). However, it's important to note that the traffic wasn't DNS traffic but the proprietary protocol used by the backdoor for remote communications. Below is the first connection sequence between the backdoor and the C&C:

By decoding the TCP stream, it is possible to recognize that custom encryption was used to exchange information with the C&C. The network traffic starts also with a keyword, "URATU," as shown below: 

Once executed, the binary creates a Mutex named "microsoft.com" reported below:

The backdoor also uses common features like other common backdoors, such as keylogging, and supports the ability to accept and run commands remotely. As in other cases, we can see that this backdoor isn't highly complex at all, but it's certainly no less effective than other complex malware once executed on the target systems. Another interesting aspect of this backdoor file is that it's signed with what appears to be an invalid\fake certificate issued to 360.cn (a Chinese ISP) by VeriSign, as shown in the properties box:

The certificate contains the following details:

Having malicious code signed with certificates is a trend that we’ve seen in other targeted attacks that can reduce the effectiveness of human and automatic countermeasures. 

In this blog, we covered the compromise of Nepalese government websites in what appears to be a chain of targeted attacks. We managed to connect those attacks to a previously reported attack that took place in a different country: the compromise of the Amnesty International UK website. This shows that cyber warfare is trending and kicking and that there's certainly an effort by international players to stay dominant and persistent in that realm.

Security Researchers: Gianluca Giuliani, Elad Sharf.

The Websense® ThreatSeeker® Network discovered on June 27, 2012, that one of the most popular travel websites in India, cleartrip.com, was compromised and served malicious code. The website was informed of this breach and no longer serves malicious code.

In this blog, we'd like to share our insights about this attack and focus on the tactics that we observed being used. We managed to spot this attack iteration before it became fully active, before malicious files were uploaded to the exploit kits that cleartrip.com was redirected to, and before all the malicious redirection nodes that cleartrip.com led to were active. 

The tactics that the cyber criminals used show what goes into making a legitimate website's infection less obvious and more difficult for security products to detect. These tactics included the following:  

• Targeting a website's local ad system and masquerading as legitimate ads 
• Manually intervening on a compromised website and preparing multiple domains to ensure redundancy  
• Obfuscating available malicious toolkit redirectors to circumvent detection
• Using advanced traffic direction system components and masquerading as a legitimate website to remain covert 
• Using exploit kits that serve Java-based exploits only

The next image summarizes the infection redirection chain leading to the exploit website as it started from cleartrip: 

In this section, we'll take a closer look at the tactics we listed above: 

Tactic 1: Targeting the local ad system and masquerading as part of the legitimate ad chain

The attackers seemed to focus on cleartrip.com's local ad system. Having that specific component compromised allowed them to serve malicious code through ads maintained by the website itself. The ad system on cleartrip is a third-party component plugin developed by Openx. Targeting third-party plugins is a very common tactic used to compromise legitimate websites. In this instance, it looks like the attackers gained control of the website's ad system since malicious code was restricted and served from that area only. Other cases of abuse of Openx components through exploitation and serving malicious content are documented throughout the Web. 

"Malvertizing" is another form of loading malicious code with advertisements. This is when third-party advertisers have their ads or their infrastructure compromised and then having their ads injected and loaded with malicious code. However, in the cleartrip attack, the local ads were served by cleartrip.com itself and not by a third party. By gaining unauthorized access to the Openx advertising component on the website, the attackers succeeded in sabotaging and injecting ads with malicious code. Malicious code loaded by ads is harder to detect because loaded ads usually reside at deeper path levels of the website and the malicious code blends well with the rest of the ad content. In contrast, most compromises we see in the labs tend to have injected code on the main page of a website or through pages that are loaded by the main page of a website.  

When we checked the IP address of the website of one of the malicious redirectors in this attack, euro-cool.in, we saw that it was hosted on IP address 85.17.122.245. A host report on that IP revealed more websites that have the same purpose and that are part of the attackers' malicious infrastructure (image 2). Some of the websites' names contain "openx," which leads us to surmise that the individual or group behind this attack is purposefully targeting websites that have the Openx plugin.

It's evident that the attackers were trying to blend in with legitimate ad traffic and appear to be a legitimate part of the ad chain. If you look at the detailed redirection flow in the set of images below and specifically at steps number 3 and 4, you'll clearly see keywords like "advertisement" and URL patterns that are used by legitimate ad providers, such as this on the malicious redirection stage: /banners.cgi?advert_id=1&banner_id=1&chid=341aa8fca26bcff7830499c1c5f8e359 

Tactic 1 summary: By targeting a local website's ad serving component and injecting code into legitimate ads served locally by a website, attackers can more easily evade detection and remain undiscovered.

Image 1: The Openx advertising plugin login page 

Image 2: Websites hosted on  85.17.122.245 (euro-cool.in)

Image 3: Detailed redirection flow of the attack

Tactic 2: Manually intervening on a compromised website and preparing multiple malicious domains to ensure redundancy  

The redirection chain we illustrated above led to an active exploit website, however the malware binaries that were downloaded after the successful exploitation were just stubs and didn't do anything malicious at all. It appears that the attackers didn't get a chance to upload their desired malicious files to the exploit website. In addition, the redirection chain illustrated above didn't use the illustrated websites exclusively. For example, in other locations on cleartrip.com, infected ads led to the malicious redirector euro-mary.in, which had the same purpose of euro-cool.in and was served in the same structure as euro-cool.in. But euro-mary.in was a "dead" redirect and didn't redirect to an exploit website.

hxxp://euro-mary.in/banners.cgi?advert_id=1&banner_id=1&chid=341aa8fca26bcff7830499c1c5f8e359

Admin Name:Roman Inozemtsev
Admin Organization:N/A
Admin Street1:R-N TBILISSKIY, UL. TRUDOVAYa D.18
Admin Street2:
Admin Street3:
Admin City:Tbilisskaya
Admin State/Province:Tbilisskiy r-n
Admin Postal Code:352361
Admin Country:RU
Admin Phone:+7.9060585279
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email: rework11@mail.ru

From the tactics that we have observed so far, we believe that the attackers were intervening and setting up an infrastructure necessary for exploitation manually, and that it's being done with redundancy in mind. The attacker, in this case, was a bit careless and had one of the malicious redirectors, euro-cool.in, on its way to carrying out the exploitation. However, as we mentioned, although the exploits were active, the downloaded malware was a stub and not malicious. The image below reveals how the malware stubs were downloaded to the Windows temporary files folder after the exploit succeeded (image 4). 

Tactic 2 summary:  Manually intervening on a compromised website and preparing multiple domains to ensure redundancy are ways to prolong the duration of an attack by serving several exploitation chains.

Image 4: Dropped stub files by the exploit kit

Tactic 3: Obfuscating available malicious tool-kit redirectors to circumvent detection

The code that the attackers injected into legitimate ads on cleartrip.com was obfuscated (marked as 1 and marked in red on the exploitation chain image). Once the code was de-obfuscated, it unveiled a known redirector tool-kit code that is used and available in the underground for the same purposes of acting as a redirection point to exploit websites. The de-obfuscated code shows "decision-making" code, which means it includes code that detects the browser's version of the browsing user. In this case, if the user's browser is Internet Explorer or Firefox, only then will the user be sent to the next level of the exploitation chain. The code also assigns a cookie to the user's browser, so it can be identified at the next redirection levels. 

Obfuscating code is a very common tactic to hide injected malicious code on legitimate websites. It can effectively hinder efforts to detect malicious code since it applies the same concept as compressing and encrypting code for malicious files with packers and crypters in order to evade known malicious code detection. Scanning the obfuscated code of the redirector toolkit yields a lower number of results from antivirus vendors than scanning the clear text code of the redirector toolkit.

Tactic 3 summary: Another way to avoid detection is obfuscating available malicious tool-kit redirectors, such as by using reliable underground tool-kits that are reliable and proven to work while hiding their activity with layers of obfuscation.

Tactic 4: Using advanced Traffic Direction System (TDS) components and masquerading as legitimate websites to remain covert

The redirector on stage 2 of the attack (euro-cool.in and euro-mary.in) does not redirect directly to the exploit website, but to a Traffic Direction System on sciencedailyreview.com (marked as 3 in the exploitation chain). This system picks and chooses whether to exploit the computer. The purpose of a TDS is to scrutinize all the possible details that can be derived from the visiting user's IP address and the visiting user's browser. For example, this method is a handy way to avoid known IP ranges of security companies and IP ranges that reside in certain geographic locations that might not be of interest for the attacker to infect.

In this case, the TDS system resides on sciencedailyreview.com. This website mimics and contains some code from the legitimate website, www.sciencedaily.com, a website about science. The malicious TDS in our case has two faces: if the visiting browser fulfills certain conditions, then it will be redirected to the exploit website, but if it doesn't, then it will be redirected to a false and copied representation of a legitimate website with content taken from the legitimate website www.sciencedaily.com. This fake, malicious website is even indexed through Google and serves legitimate content if visited through Google searches and has more than 34,000 cached pages by Google (see Image 5). 

The malicious side of sciencedailyreview.com redirects to the exploit website, but first, it checks exactly what Java version is installed on the user's machine (marked as 3 in the exploitation chain). The Java version information is essential because then a decision can be made about whether the user's installed Java version is vulnerable and based on that decision, redirects to the exploit website and serves the right Java exploit to the user's machine.

 sciencedailyreview.com was registered on 2012-05-03, and its registration details are anonymous.

Tactic 4 summary:  Using advanced Traffic Direction System (TDS) components and masquerading as legitimate websites to remain covert help evade detection and prolong the lifespan of malicious websites.

Image 5: sciencedailyreview.com masquerades as a legitimate website and is cached by Google search engine

Tactic 5: Using exploit kits that serve Java-based exploits only

The exploit website (marked as 5 in the exploitation chain) serves Java-based exploits only. Java has been one of the most popular exploited components on user machines in the past year. In general, exploit kits target several components by holding several exploits for local installed components like the local browser, Adobe Acrobat Reader, Adobe Flash Player, Java, and more. Using several exploits can prove "noisy" and can result in detection of the exploit site. Tactically targeting one component for exploitation is more effective than targeting a few components since doing so is a more focused, and hence "quieter" approach that reduces the chances of the kit being discovered. Java is a good choice since usually exploits for that platform are reliable and can serve several platforms (e.g., the Java framework is also installed on Mac computers). In addition, Java is an interpreted programming language, which means, with relatively little effort, attackers can use it to obfuscate malicious code with cheap obfuscator kits that can be bought in the Black Hat underground market. 

In our case, the exploit kit on the exploit server appeared to be the "Neosploit" exploit pack, and the exploit that was served targeted the Java vulnerability described in CVE-2012-0507. This infamous exploit was used in the Flashback mass attacks and also used in the compromise of Amnesty International UK and the compromise of the Institute for National Security Studies (Israel).

Tactic 5 summary: Using exploit kits that serve Java-based exploits is an effective way to evade detection

Image 6: Neosploit exploit kit - this version serves only Java based exploits

In this blog, we took a look at several tactics that cyber criminals employ when they compromise a legitimate website for malicious purposes. Please let us know if you have any additional insights regarding this specific incident and also, please drop us a line if you'd like to share some insights about similar compromises that you have encountered.

Between May 8 and 9, 2012, the Websense® ThreatSeeker® Network detected that the Amnesty International United Kingdom website was compromised. The website was apparently injected with malicious code for these 2 days. During that time, website users risked having sensitive data stolen and perhaps infecting other users in their network. However, the website owners rectified this issue after we advised them about the injection. In early 2009, we discovered this same site was compromised, and in 2010, we reported another injection of an Amnesty International website, this time the Hong Kong site.

In the most recent case, we noticed that the exploit vector used was the same Java exploit (detailed in CVE-2012-0507) that has been used worldwide, and which has become somewhat infamous as the cause of the recent massive Mac OS X infection with Flashback. 

Websense customers are protected from these threats by ACE, our Advanced Classification Engine.

The following is a screen shot of the detected code injection:

a

                                                                  (click on the picture to enlarge)

In the screen shot, we can see the similarities between this injection and the INSS injection we reported last week. This clearly shows the use of the Metasploit framework and the precise name of the Java class used. In addition, the associated JAR file is a well-known vector exploit for the CVE-2012-0507, as shown below:

                                                                 (click on the picture to enlarge)

Once the exploit is successful, a file download is initiated for an executable from this URL: "hxxxp://www.48groupclub.org/images/uploads/image/sethc.exe" - MD5 : 3EC4DE9EF2E158473208842F4631236A

Further analysis shows that when the "sethc.exe" file is executed on the compromised system, it creates a new binary file in the Windows system directory: C:\Program Files\...... 

The ruse appears credible because the executable file has been signed by a "valid" certificate authority (CA), as shown below:

Through further research we learn that this certificate has been in use for a while and does not appear to have been revoked at the time of this latest exploit activity.

Analyzing this low AV detected binary file, we recognize that this is a variant of the well-known Remote Administration Tool Gh0st RAT, which is used mainly in targeted attacks to gain complete control of infected systems. With this control, the remote administrator has access to a user's files, email, passwords, and other sensitive personal information. Following is the initial network capture with Wireshark between a compromised system and the remote administration center, which reveals the header information of the traffic (pay particular attention to the starting keyword "gh0st"), confirming the use of Gh0st RAT:

                                                     (clieck on the picture to enlarge)

The Remote Administration Center commands to the compromised system originate from this address: shell.xhhow4.com. At the time of this writing, the address is still active.

[Update]

Websense® ThreatSeeker® Network detected that the Amnesty International Hong Kong sister website was also compromised to serve Gh0st RAT over the weekend, and the malicious codes are still live and active. Below are some of the pages infected redirecting to the exploits. Websense Security Labs will continue to monitor and update any new changes to this attack.

The recent advent of flashback malware that includes exploit code for CVE-2012-0507 has been creating waves and quickly adopted by various other attackers as Websense® Security Labs™ has shown. This blog post detail some of the aspects of CVE-2012-0507 and how this exploit has been used in the wild.

The Java code first starts with the excerpt below:

The string "sobj" contains a stream of characters that trigger the vulnerability and force Java to render something which it usually wouldn't be allowed to. The string "8BCA ..." is obfuscated with an XOR key of 0x27 shown below:

After this string is de-obfuscated, it looks something like the image below:

We compared the exploit code used in the flashback campaign (above) with another instance in the wild that surfaced recently. Apparently, the attacker is using the exploit code provided by the metasploit framework.

The only difference between the flashback exploit code and the one used by metasploit is the bytecode array, where one is a signed byte array while the other is unsigned, as revealed below:

In our flashback sample, the string that triggers the vulnerability is "XOR-ed" with 0x27, while the string seen in the metasploit sample uses a signed byte array.

Lastly, the payload used by the flashback malware is a dropped Mach-O binary executable, while the metasploit exploit opens a listening TCP port shell pipe depending on what operating system the victim is on (This highlights the beauty of a design flaw as opposed to a vulnerability that corrupts memory). The code excerpt is shown below:

 Websense security solutions protect users from these kinds of exploits.

The Websense® ThreatSeeker® Network has discovered a new wave of injection of malicious code disguising itself as Google Analytics, by adopting similar code snippets and malicious domains.

It is quite convincing at first glance, but remember, usually we put the analytics code at the bottom of the page, instead of at the top, so this is a good hint to Web masters. Another hint is that they are using "UA-XXXXX-X", a placeholder as their "Google Analytics account", obviously this is not what people usually do. We found other similar domains like google-analytics[dot]su in this attack, and will update once we find more. The evil ga.js code is as below:

it is highly obfuscated, hard to understand, but after all tricks it finally will redirect to IP address 37.59.74.145 which hosts Black Hole Exploit.

 Websense customers are protected from these threats by ACE^TM, our Advanced Classification Engine.

I returned this past weekend from SOURCE Boston, where I presented the new features and architecture of Fireshark v2.

I have had the opportunity to speak at many conferences before, but this was my first time doing so in my university town of Boston (Northeastern), and my first time speaking at SOURCE. SOURCE has conference locations in Seattle, Barcelona, and Boston, and attempts to bring security experts together to create a very positive mix of business needs and technology expertise. Boston is a bustling city with a number of technology companies and top universities. The location alone is worth the visit.

That aside, I was impressed with some of the presentations I saw. Here are a few worth mentioning, which are available online at http://www.sourceconference.com/boston/speakers_2011.asp:
 

• On The Use of Prediction Markets in Information Security - Dan Geer, Alex Hutton, Greg Shannon
• The Exploit Intelligence Project - Dan Guido, iSEC Partners (great talk!) 
• Incursion - From Internet To SCADA, Critical Systems Compromise Case Studies in Pictures - Val Smith, Attack Research, and Chris, SecureDNA 
• Fuel for pwnage: Exploit kits - Vicente Diaz and Jorge Mieres, Kaspersky Lab
• Reverse Engineering Flash Files with SWFREtools - Sebastian Porst (Flash analysis tool released!)
• Reversing Obfuscation - Adam Meyers, SRA International
• Streamline Incident Types for Efficient Incident Response - Predrag Zivic and Mike Lecky, Canadian Tire (really interesting talk on identify tracking)
• Network Stream Hacking with Mallory - Raj Umadas, Jeremy Allen, The Intrepidus Group (Mallory is a tool worth checking out!)
• Adding another level of hell to reverse engineering - Ben Agre, Raytheon (Something as reverse engineers that we'll have to become acustomed to more and more: used junk code!)

and finally...

My presentation: Fireshark v2 - An Analysis Toolkit for Malicious Web Sites - Stephan Chenette, Principal Security Researcher, Websense Labs (to be publicly available on or before May 5)

(Figure 1: Stephan Chenette introducing Fireshark v2, an analysis tool kit for malicious websites)

I want to thank Stacy Thayer,  SOURCE founder, the SOURCE advisory board and all attendees.

(Figure 2: SOURCE founder, Stacy Thayer)

In this post I'll cover an interesting piece of obfuscation that we recently came across while handling a blended threat.  This threat began as several malicious emails containing a link that redirected to the site below.  The obfuscation was found in part of an attack site using the Phoenix Exploit Kit. 

Here is a screen shot of the Phoenix Exploit's Kit login at the site we are going to analyze:

Once decoded, like many attack kits, this attack site attempts to exploit a visiting computer using a number of known vulnerabilities.  The vulnerabilities focused on Java, Flash, and PDF.  What made this obfuscation particularly interesting was the way in which the decoding was done.  The algorithm used to deobfuscate the sample I reviewed was a type of random access file. 

Here is a screen shot of the HTML payload:

That alone looks like a big headache and may make your eyes cross at first glance!  We can see that there is a Java applet in the HTML code, but there is also a large script which we will focus on deobfuscating so we can understand the threat a little better.  Let's parse out the script and beautify it a bit so we know where we can start. 

Here is a beautified version of the script:

This is much easier to review but obviously still obfuscated.  At least we can now see a structure to the obfuscated JavaScript and we can see a few key areas.  First there is a huge variable declaration, cut off in the screen shot, which is probably what the algorithm is going to work on decoding.  Then there is a function definition, a <p> tag being written to the page, a nested for loop, and finally an eval. 

The first thing that caught my eye in this obfuscation was the document.write('<p>3360</p>') code.  My first thought was "Why would a malicious script write a paragraph tag containing a single number to the page?"  Then, on the next line, we can see that the above number is loaded into a variable.  This is somewhat hidden in a simple obfuscated document.getElementsByTagName call.

Here is a screen shot of the above referenced code:

The for loop is the next interesting part and, as with most deobfuscation routines, is the main part of the algorithm.  If we step through the for loop a number of times, we see that it's working to access that huge variable using the number from the above paragraph tag as a byte offset.  The inner loop is where the random access actually happens.  It runs through the long variable, starting at index 0, and uses the number in the <p> tag written to the document from the above code as the byte offset from the index until it comes to the end of the variable string.  Once the end of the variable string is reached, the outer loop forces the inner loop to pass through starting at an index of 1 and so on.  Stepping through this algorithm 15 times, you will get a bit of an obfuscated document.write( call.  Each of the characters at the index + byte offset is concatenated into another variable which, when these loops complete, turn out to be the deobfuscated attack script.

Screen shot of the nested loop code:

From this point, there are a few simple search and replace actions done via a function call and an eval to execute the JavaScript code that holds the exploits.  Reviewing the code, we were able to see that there are a hefty number of exploit attempts on different versions of Adobe Reader, Java, Flash, and other Windows components.

This is a snippet of the attack code after it's been deobfuscated:

Another thing that this site has done that is getting to be more common with attack sites, is allow only one visit to the attack page.  This seems counter intuitive as it would also limit the attack exposure for these sites.  However, this technique is meant as a protection mechanism for attackers to prevent researchers, such as ourselves, from analyzing the attacks occurring on the site.  This also makes things harder when figuring out whether to publish attacks to block databases.  Our ACE analytics allow us to capture these sites and protect our customers in a real time fashion, not relying on URL database production.  This means that from the first time our customers visit these attack sites, they are protected.

Websense® Security Labs™ ThreatSeeker™ Network has discovered that over 100 Web sites on the Media Temple Web host servers have been compromised, and will lead visitors to the Phoenix Exploit Kit. It's not the first time they have had a WordPress injection, but a quick investigation suggests that only 46% of these sites have WordPress installed, and Sucuri Scanner reveals that they do have multiple vulnerabilities. So what happened to the other sites? They don't have WordPress installed but have still been compromised; why? According to the statement from Media Temple, neither Media Temple’s architecture nor the up-to-date versions of WordPress is the source of these compromises. Some insecure 3rd-party software applications installed on customer servers are the root cause, which has been verified by Sucuri.

All the injections are designed to only work on JavaScript files as shown below, and are obfuscated to evade detection.

After deobfuscation, we got a simple algorithm to generate malicious URLs. We generated 64 URLs which are all already covered by Websense. Now we go to check those generated URLs, and find there are 2 different scripts. One is very simple with an anti-bot trick so it won't be crawled by search engines. Unfortunately the payload site it redirects to is now down.

The other is highly obfuscated, and finally redirects to an exploit kit called Phoenix.

The Phoenix Exploit Kit is a sophisticated hacker tool set that exploits several of the latest vulnerabilities on popular vectors to execute arbitrary code.

Websense TRITON Advanced Classification Engine(ACE) is protecting customers against this attack. We will keep track of it and provide updates when it changes. 

Probably the biggest computer threats nowadays are the Exploits. Exploits seek out the vulnerabilities of an application to launch their malicious activities. Cyber criminals target popular applications such as Shockwave Flash and Adobe Acrobat PDF to keep the chances high that a user's computer is vulnerable. In this blog we will examine a Flash exploit using a very simple crypto-analysis technique we call X-ray.

Crypto-analysis of malicious code is not a new technology or invention. It has been used in fighting MS-DOS viruses since the '90s. This article provides an in-depth, detailed discussion on this subject, explaining how it works and how it can be used for malicious content detection in shell code.

First we need to understand the X-ray technique and how it works, and then we can see how it helps us to analyze and detect malicious content in shell code. X-ray is basically a differential crypto-analysis method which is a very easy way to attack simple encrypted data. What we assume is that when a simple block encryption algorithm is used, the difference between the consecutive data blocks remains the same.

One very good way to explain this is to encrypt a picture and then try decrypting it. Take a look at this picture:

The picture does not tell us much, except that we can see that it is encrypted. It looks random enough, even though we can spot some repetition. In fact the algorithm used is very simple stream ciphering with some avalanche effect. The result is a picture that suggests very little about itself. However, when we generate the difference in between the consecutive bytes, we get this:

Ah-ha! Now we see that this is the logo of our secret weapon against Internet threats.  :-)  (See the original graphic below)

Now, no wonder it is called X-ray!  We may not see the 'skin', but we clearly see the 'bones'. The resulting picture is far from the original one, but is good enough to see what it was. Nice, but how does it work?

To understand, we need to get into the math behind cryptography. Take a look at this very simple block ciphering algorithm. We have a message of:

Where M is the n length of plaintext message and m is the block of the message (typically a character).

In order to get the ciphered message of:

Where C is the n length of ciphertext (encrypted) message and c is the block of the message (typically a character),

we need to apply an encryption to each one of the message blocks using the same key:

Where E is the encryption algorithm using k key.

When E encryption algorithm is a simple XOR using the same k key on each block, then

the (above) formula gives us the encrypted stream. Usually we see this simple method in shell code with byte size blocks. In other words, each one of the characters of clear text is simply XORed with a constant (see the pseudo code). The reason this kind of encryption is so popular is that it is easy to understand and it is also easy to obfuscate the data and the code sections enough to avoid detection by a simple string detection engine.

Now we can note that a simple differential analysis will easily decypher this kind of encryption:

Why? Because:

Because XOR is commutative, we can remove the brackets and reorganize the equation to:

We know that:

Therefore:

As we can see, a simple block ciphering does not provide strong encryption. And because simple block ciphering is widely used in exploits, we can easily break those by decyphering known text or binary content in them. To put the theory in practice, let's take a look at this simple decryption loop taken out of shell code used in an SWF exploit:

(MD5 of the sample: 32398CBF94CA9B42E0B415BB93B00CFE)

As we can see, the code uses byte size blocks and a simple XOR ciphering with a constant 0x3D. Inside the code we can also see a pattern starts with some 0x3D following by a text "UIIM":

We might suspect that is an encrypted URL starting with "http://". Now that we know the algorithm and the encryption key, it is easy to double check if our suspicion is correct. The question is how do we find this string without knowing the key?

Do you remember the differential attack? All we need to do is to take a known text, which is "http://", and create a stream of differences:

Similarly, we create a difference on the encrypted stream:

And then, if we can find ΔM in ΔC, then we have what we are looking for. Obviously, the longer the known text, the less prone it is to falsely detecting the string.

The next step is to determine the key, and decipher the entire URL, which is very simple by just doing an XOR on the first detected block and the first block of the known text:

Knowing all of this, we can now write a simple analysis tool that can find and extract 'interesting text' from a binary file. As an example, here is the output of a small Perl hack I wrote earlier (see the script attached below):

The good thing about this technique is that we have to generate the differential set from the known text set only once in the lifetime of the application. Also, we need to generate the differences of the scanned shell code only once to check all the known text from our dictionary. Our dictionary therefore can be huge, including not only known and unknown URL patterns, but binary sequences that can identify each type of shell code we already know.

So far so good, however, life would be too easy if all of our work was finished now, yes? Many times, we see the shell code in compressed and otherwise obfuscated format. For example a Flash file could be compressed, or in a PDF file each stream can be compressed and encoded in different ways, which than can contain obfuscated JavaScript code that holds the shell code. The detection or analytics engine therefore first needs to do all the necessary transformations and de-obfuscations in order to be able to analyze the shell code. Maybe this is one of the reasons we can see simple encryptions most of the times.

Although in reality we see mostly simple block ciphers in exploits, there are many examples in viruses and trojans of much more sophisticated encryptions. These use a variety of block and stream ciphers with different length encryption keys, even applying more than one algorithm on top of each other to harden the encryption. Breaking such ciphertext requires more complex method, however, due to constantly increasing computing power, it is even possible to attack the DES algorithm. The good news is that even when stronger encryption has been applied, we have better techniques to detect malicious content.

Injecting malicious html code into legitimate Web sites has become commonplace in the past few years.  More often than not, the attackers inject a script or iframe tag in a legitimate site which is meant to redirect visitors to attack sites without their knowledge.  Last week, however, we discovered an outlier of that trend which was a malicious applet code injection.  The injected applet allows the code to work as a drive-by attack that downloads and then executes a malicious application.

Screen shot of injected page:

Reviewing the applet code, we can see that a 'Client.jar' file is downloaded.  This Client.jar file runs and uses some of the code found in the applet to create a .vbs file on the local system.  Reviewing the contents of Client.jar, we can see that it does this by getting the contents of the parameter "windows1". 

Screen shot of Client.jar:

Reviewing the applet code on the injected site, we can see a <param tag with name='windows1'.  The contents of the tag are actually one long command using  cmd.exe to create a .vbs file in %temp%/winconfig.vbs.  At the end of this command you can see that the .vbs file is executed to download a malicious file and place it on the local file system as %temp%/update.exe.  Notice the use of the tinyurl passed to winconfig.vbs, this is probably an attempt to make the code look a bit more legitimate as it doesn't look like it's downloading an executable file. 

Screen shot of the .vbs code:

The interesting thing about these injections is the social engineering aspect of the attack.  Remember that this applet code is being injected by attackers into legitimate pages, and the attack .jar file is hosted on the same infected domain.  This means that you may get a few warnings popped up by Java, but most people will simply click through and ignore them, especially if they are visiting a "trusted" page.  After all, who really reads warnings when they are visiting a page they have been to before?  Most people would think that if a warning is coming from a page which they have been to and trusted before, there must be a false positive situation occurring. 

Here is a quick video of this attack in action.

Websense Messaging and Websense Web Security customers are protected against this attack.