Styx Exploit Pack: How It Works

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

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

In addition to this, there are two major unique aspects in the way that Styx operates. These are

  • Multiple exploit pages: Styx distributes the malicious script across multiple pages, which are connected by HTTP redirects.
  • IFRAME data access: Styx 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 Styx and other 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 Styx; in addition we constantly find and block web sites and malicious files used by Styx.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Styx Exploit Pack: How It Works

Read more: Styx Exploit Pack: How It Works

Story added 3. September 2013, content source with full text you can find at link above.