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.

Sibhost

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:

The JavaScript library (deployJava.js) and JAR (random_filename.zip) 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:

value="5c73411212392829704f7f4f43076f6a490552662d20712b69
3c680c7d1a7e6c7c04425249214c5775516d3f5c735032584b0252222
9491557242a2562307d53436e463d4c696446652165315533056a6729
2a627f5e3f0c6a026a74715f525a345a031020605f730d33163a50520
021774564120f032325523102534b2735753616334e5000"

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.

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.

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

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.

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

hxxp://[redacted]/BYzcamFTzpcRTyarvjjz2C1YK5oB19V7H1kxAzIKyl
TUk5xB?id=2;
uL4oz7VAw8qe;
/576cf5020bbc00d5f27e89f671c12234.dat

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:

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:

Flimkit

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].com.br/www/images/adv/index.php

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:

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

value="3a2944034d603e082f443a42655c0c672c4a391f5c7b1f4d53
38114b517c032929633d746651052276744f1c602b79120a6b4841755
9174d305d23656f594e"

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):

hxxp://[redacted].pl/70937e78106;
/nkaans;
wjuk7dilx6y11zec2fufhq;

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

The 3rd string is the XOR key, which lets us decode the 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:

Summary

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.