The four seasons of Glazunov: digging further into Sibhost and Flimkit

In the analysis of the Glazunov exploit kit that I posted early last week, I mentioned two other kits that are very similar – Sibhost and Flimkit. In this post, I am going to take a quick look at these and highlight the similarities and differences between the three kits.


As is the case with Glazunov, the official name that the author gives to this kit is not known, but Sibhost seems to be the name that has been adopted.

User web traffic is redirected to the Sibhost landing page via the usual array of iframe and JavaScript redirections. But unlike Glazunov, the landing page is not injected into legitimate sites. It is hosted on the exploit server, alongside the other malicious components.

As you can see below, the landing page is pretty small:

Sibhost landing page

The JavaScript library (deployJava.js) and JAR ( that are loaded by this page are both local files (stored on the exploit site). Other than this, you can see definite similarities between the landing pages for Sibhost and Glazunov.

Notice also the long string embedded in the landing page, which is decrypted by the malicious Java. In this example, the string is as follows:


Java Network Launch Protocol (JNLP) is used to deliver the malicious content, and if we decode the base-64 encoded configuration file we can confirm use of the same security bypass.

JNLP configuration data for Sibhost

Within the JAR is the expected assortment of randomly named class files. However, the archive contains an additional file that was not present in Glazunov. This file typically uses a filename consisting of a 32-character hash and .dat extension.

Sibhost JAR directory

At a quick glance, this large file looks like garbage, though there are repeating bytes present (two of which are highlighted).

Header of encoded file in Sibhost JAR

As with the Glazunov analysis, let’s start off by decrypting the string embedded in the landing page. The decryption routine is again easy to find, and, surprise surprise, it is identical to that used in Glazunov.

String decryption routine in Sibhost Java

Once we decrypt the above string, we end up with:


Aha! Unlike Glazunov (plus Redkit, Blackhole and others), we seem to have ended up with more than just a payload URL.

Sure enough, if we continue analysing the malicious Java, we find code to split this string (on ‘;’) into 3 components:

  1. the 1st string is a URL (see below)
  2. the 2nd string matches the repeating block highlighted in the encoded data file (above), suggesting this is the XOR key required to decode the payload.
  3. the 3rd string is the reference to the encoded data file within the JAR archive. This data file can then be loaded.

Decoding the data file with the 2nd string confirms that it is the XOR key. We end up with a valid executable:

Decoded sibhost payload

Given that the encoded payload is stored within the JAR file, what is the purpose of the 1st string (the URL)? Another payload perhaps?

It appears not. The Java does send an HTTP POST request to that URL, sending some text=[0-9]+ data. The response from the server is read, but not used (at least not in the malicious JARs analysed). It is probably used for tracking purposes, although it has to be said this section of code does look a little bit like an afterthought – not least because it is the only code where strings are not obfuscated.

An overview of Sibhost is shown in the diagram below:

Overview of Sibhost exploit kit


Once again I am using a name assigned from within the security community that seems to have stuck. Flimkit has been quite active recently, with malicious ad and Flash (SWF) content redirecting user traffic to the exploit sites. The exploit sites are currently using the Polish (.pl) TLD, for example:

Exploit site: ulen[redacted].pl/58jam7ucyyvok5
Referrer: [redacted]

Exploit site: onas[redacted].pl/yzvl971xl
Referrer: [redacted].com/newServing/showbanner.php?[snip]

Exploit site: yxyd[redacted].pl/g395xyz9ugkx1qx7hzem
Referrer: [redacted].com/b.swf

Sophos products block access to the exploit site landing page as Mal/ExpJS-BJ.

The landing page itself is very similar to Sibhost:

Flimkit landing page

As you can see, we have the expected encrypted string, stored as an attribute within the param element:


The JAR that is loaded contains an additional extension-less file, as well as the expected randomly named class files:


The string decryption routine is identical to Sibhost and Glazunov, and once we have found it we can decode the string from the landing page.

We end up with three strings again, like Sibhost (though they are in a different order):


The 2nd string is the reference to the encoded payload within the JAR.

Encoded Flimkit payload

The 3rd string is the XOR key, which lets us decode the payload:

Decoded Flimkit payload

Within the malicious Java there is a notable difference in Flimkit however. After using the 2nd and 3rd strings (highlighted in red) for extracting and decoding the first payload, the Flimkit code checks for additional string values (green). If present, these (the 4th and 5th values) are used to extract and decode a second payload.


So Flimkit is obviously intended to be able to deliver two payloads stored within a single JAR.

An overview of Flimkit is illustrated below:

Overview of Flimkit exploit kit


In this article, and my previous post on Glazunov, I have described three exploit kits that are all being actively used to infect users with ransomware.

Upon closer inspection, it is clear that there is some overlap between these kits:

  • identical string encryption routine
  • similar landing page structure, though for Glazunov elements of the landing page are injected into victim sites.
  • Sibhost and Flimkit both carry the payload within the JAR, XOR encoded.
  • Sibhost and Flimkit both pass a tracking URL via the landing page string data.

The similarities suggest that either the same author/group is behind these kits or that there is significant code sharing (or copying) between different authors.

My suspicions are the former. Are these three kits actually just different versions/options of a single kit?

As ever, the best advice for users looking to protect themselves from these kinds of attacks is:

  • Follow general security best practice. Ensure you are using security technologies that add different layers of protection, for example decent generic detection, reputation filtering of web traffic and runtime detection/HIPs.
  • Patch. Patch. Ensure you patch software (application and OS) quickly.
  • Java. All of these kits target Java vulnerabilities. Ask yourself if you really need to have Java installed.

Image of spider courtesy of Shutterstock.