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.
As you can see below, the landing page is pretty small:
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.
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:
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:
- the 1st string is a URL (see below)
- 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.
- 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:
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
Exploit site: onas[redacted].pl/yzvl971xl
Exploit site: yxyd[redacted].pl/g395xyz9ugkx1qx7hzem
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:
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.
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:
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.