Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    September 2015
    S M T W T F S
    « Aug    
  • Email Subscription

  • About Us

    Author Archive - Mark Tang (Threats Analyst)

    While the Blackhole Exploit Kit is the most well-known of the exploit kits that affect users, other exploit kits are also well known in the Russian underground. In this post, we will look at how these other kits work, and its differences from other exploit kits.

    One well-known Blackhole alternative is the Styx Exploit Kit. Websites hosting the Styx Exploit Kit generally use dynamic DNS services together with very long random alphanumeric strings to form their URLs. Here is an example of a typical Styx exploit URL:

    • http://{dynamic DNS service}/ajD8g903fAA0C2GT0YqF70DDBW0Bcto0gRA80hcK80QJkx0q2gm0PNQA0YVmw0XKBF

    However, we recently found a case where a Styx URL was used, but the Cool Exploit Kit powered the actual exploitation itself. The Cool Exploit Kit has two major unique aspects in the way that it operates. These are

    • Multiple exploit pages: it distributes the malicious script across multiple pages, which are connected by HTTP redirects.
    • IFRAME data access: It accesses its data across various IFRAMEs via JavaScript.

    Multiple Exploit Pages

    Figure 1 below shows the overall infection chain, we observed in one of the samples we analyzed. The pages in green are part of the exploit kit, which are responsible for anti-emulation and plugin detection. The entry pageprofession-integrity_medicine.html checks the version of Java installed and redirects to either mortgage-fulfil_distant.html or march_stability_outbreak_vertical.html based on the version found. Both pages host Java exploits, one of which targets CVE-2013-1493.

    If no Java plugin is found, it will redirect to momentum-ornament.html. This page will check the browser’s user agent to see if the user is running Internet Explorer and also looks for the presence of the “WOW64″ string in the browser’s user agent (i.e., the user is running the 32-bit version of IE). If both conditions are met, the user is directed to advise-loaf.html, which hosts CVE-2011-3402.

    If the system is running Windows and uses Google Chrome, it will check for the version of the Adobe Reader installed. If the version is either 8.0 – 8.2 or 9.0 – 9.3, it then redirects users to a malicious .PDF file. If the installed version is neither, users will be forwarded to a site hosting a Java exploit, which targets CVE-2013-1493.

    For users running Windows but with no Google Chrome installed, the malicious code will stop and ultimately, no malware is dropped.

    The malicious payload will be dropped if any of the exploits succeeds in running on the affected system.


    Spreading the malicious code across multiple files is rather unusual. Other exploit kits generally concentrate all the plugin detection code into one file; perhaps this may have been done to appear less suspicious to website administrators looking for files indicating their site has been compromised.

    Data Access Across IFRAMEs

    The malicious scripts in the pages are lightly obfuscated, but the attackers still use some tricky techniques to evade detection.

    The figures below show some code from the entry page profession-integrity_medicine.html. The first part shows an IFRAME tag referring to the page commonly_essential_lexical.html; the second part shows code trying to get the contentWindow of the IFRAME page, then get the string value of a tag named rsifihzl to continue execution. The string will finally be decoded as Javascript code and will then be run.


    Figure 2. IFRAME references

    Figure 3. Content of commonly_essential_lexical.html

    Figure 4. Decoded script


    These findings highlight the differences between various exploit kits; just because the end result is identical does not mean the methods used are identical as well. Solutions have to be able to cope with the various methods that attackers can use.

    Our existing browser exploit prevention technology is capable of detecting and protecting users against this threat; in addition we constantly find and block web sites and malicious files used by various exploit kits.

    Update as of September 3, 7:30 PM PDT

    An earlier version of this blog post claimed that the actual exploit kit used was also Styx, and not the Cool Exploit Kit. We regret the error.


    Websites with exploit kits are one thing that security vendors and researchers frequently try to look into, so it shouldn’t be a surprise that attackers have gone to some length to specifically dodge the good guys. How do they do it?

    The most basic method used by attackers is an IP blacklist. Just like security vendors have extensive blacklists of IP addresses used to send spam, host malicious sites, and receive stolen information, attackers have lists of the IP addresses that they believe are used by security vendors and block all access from these addresses.

    A more sophisticated method is to infect a given IP address only once. How would this work?

    Suppose that a vendor would have a list of websites that is associated with a certain attack. They would access one site (either manually or with automated tools), but the attacker would note that this particular IP address had already accessed a site associated with this attack in a backend database of their own; if the vendor would access other sites that checked with that database they would not be able to successfully access the malicious content.

    Figure 1. Crawling avoidance

    Backend databases like this can also be used together with dynamic DNS services. The attackers would dynamically create so many random URLs with these services so that they can afford to deactivate a URL within minutes of somebody visiting it.

    All of these techniques are supported by exploits kits to different degrees. One of the most common ones is the “infect once” technique, which is used by both versions (1.x and 2.x) of the Blackhole Exploit Kit, as well as Styx and CoolKit.

    While individual countermeasures are available, these do place an additional burden on vendors and researchers. While we are able to work around these limitations, it also highlights how important it is not to rely on any one particular method to secure users.

    There is no silver bullet to security. A “defense in depth” strategy that uses both cloud and endpoint methods is still the most effective way to ward off threats in today’s security environment. Most importantly, correlation between these multiple methods in order to find all aspects of the infection chain is vital to finding and analyzing new threats.

    Securing users via the cloud is still an efficient way of protecting users with broad coverage, powerful correlation and protection while using few resources. Like a cat and mouse game, we will continuously make improvements to crawlers and honey pots to stay ahead of cybercriminals.

    However, endpoint protection is a still an essential complement to cloud protection – the threat is running on the end point in real time, with a real user, and in a real environment. On the endpoint, files and sites the user can be inspected in right away, while potentially malicious content (like Javascript and Java) can be executed and analyzed for malicious behavior. Users can be protected before any malicious files are saved onto the user’s system.

    In the meantime, information about any newly detected threats is fed back into the cloud and the Smart Protection Network.  This allows us both to protect all users “out of the box” and to gather information about these threats, which we can use to learn more about them and devise more effective methods of protecting users.

    Posted in Bad Sites, Malware | Comments Off on How Exploit Kits Dodge Security Vendors and Researchers


    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice