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 cleartrip website describes the attackers' infection redirection chain:
In this section, we'll take a closer look at these tactics:
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 by 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 where code blends with the rest of the ad content. Most compromises tend to inject code on the main page of a website or through pages that are loaded by the main page of a website.
Moreover, when we checked the IP address of the website of one of the malicious redirectors, euro-cool.in, we saw that it was hosted on IP address 22.214.171.124. 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.
On top of that, it's evident that the attackers are trying to blend in with legitimate ad traffic and appear to be part of the add 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: /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, attackers can more easily evade detection and remain undiscovered.
Image 1: The Openx advertising plugin login page
Image 2: Websites hosted on 126.96.36.199 (euro-cool.in)
Image 3: Detailed redirection flow of the attack
Tactic 2: Manually intervening on a compromised website and preparing multiple domains to ensure redundancy
The redirection chain 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 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.
euro-mary.in was registered on 2012-06-26, and we believe that it was registered specifically for this attack but was, fortunately, detected before it became fully active. euro-cool.in was also registered on the same date, 2012-06-26. The domains were registered by an individual called Roman Inozemtsev. Here are more details:
Admin Name:Roman Inozemtsev
Admin Street1:R-N TBILISSKIY, UL. TRUDOVAYa D.18
Admin State/Province:Tbilisskiy r-n
Admin Postal Code:352361
Admin Phone Ext.:
Admin FAX Ext.:
Admin Email: [email protected]
From the tactics that we have observed so far, we believe that the attackers are setting up an infrastructure necessary for manual exploitation, 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 a 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 toolkit 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, some checks are done, and 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 toolkit redirectors, such as by using reliable underground toolkits that are 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 IP ranges of security companies and IP ranges that reside in certain locations that might not be easy to detect.
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 this 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 representation of a legitimate website with content taken from the legitimate website, www.sciencedaily.com. This false, 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, reducing 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.
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 in action
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, drop us a line if you'd like to share some insights about similar compromises that you have encountered.
Leave a reply