Taking a closer look at the Glazunov exploit kit

Following on from my recent articles on the Redkit exploit kit, I thought I would take a look at another exploit kit that is not that well known.

The one I have chosen has been quite active of late, and has a few interesting characteristics I wanted to highlight. As it happens, I do not actually know its “official” name (as in the name assigned by the author), but it was originally christened Glazunov by another researcher tracking it back in 2012 and the name seems to have stuck!

Compromised sites

As I am sure most readers are aware, it is typical for exploit kits to rely upon injections of iframes into legitimate web sites in order to drive user traffic to the exploit kit. This is very much the classic drive-by download scenario. For those wanting a bit more background on this type of attack, take a look at this video, which clearly explains how the process works.

_{(Enjoy this video? Check out more on the SophosLabs YouTube channel.)}

Recent Glazunov activity shows a different twist. Compromised web pages are not just injected with some redirect. Instead, pretty much the entire ‘landing page’ is injected. Glazunov-infected web sites are typically injected with:

1. JavaScript element to load remote PluginDetect or DeployJava libraries.
2. JavaScript to write APPLET or OBJECT elements to the page in order to load a remote, malicious JAR file.

Web pages injected in this manner are blocked by Sophos products as Mal/ExpJS-BH.

Site distribution

To get some idea of the volume and distribution of web sites that have been injected by Glazunov I queried data from the past 3 months.

The attacks are not localised to a particular ISP – victim sites have been seen across a large number of ISPs, located all over the world.

Looking at the distribution of server platforms for the affected sites, the vast majority are running Apache.

What can we conclude from this distribution?

The Apache dominance (86%) is not quite as high (93%) as we saw with the Darkleech attacks, earlier in the year. However, it is certainly higher than we would expect if the attacks were agnostic to the server platform. So it could well be the case that malicious Apache modules are being used by Glazunov to inject the malicious code.

Hopefully, community feedback from affected site admins will reveal the truth.

Loading the Java

Recently, the authors behind Glazunov have been trying to evade detection by fragmenting the injected scripts, resulting in three separate script elements being injected. For example:

As you can see, the injected script makes use of the Java Network Launch Protocol (JNLP) in order to deliver the malicious content to exploit the user and infect them with malware.

The base-64 encoded string (snipped in the above diagram) contains the various configuration information needed to load the malicious Java, such as:

• required Java Runtime Environment (JRE) software
• application name, vendor
• runtime parameters
• code source

The astute will also notice the trivial security bypass that pretty much all of today’s exploit kits are using.

Malicious Java

At this point, my original article contained an error! The Java content I dissected was actually from another exploit kit known as ‘Sibhost’ (hat-tip to @EKWatcher for spotting the error). I will post a deep-dive into that exploit kit next!

Actually, this raises an interesting point that is a growing pain for researchers. Distinguishing different exploit kits is becoming much more difficult (e.g. Blackhole and Cool confusion). There is significant overlap between several of the active kits – for example using the same code obfuscation or string encryption techniques. This is likely due to groups of kits being developed by the same criminal groups, either in parallel or as spin-offs. This is definitely the case for three kits right now: Glazunov, Sibhost and Flimkit. Hence my confusion!

Anyway, back to Glazunov…

The JAR file itself is loaded from a remote server, using the “one-time only” URL specified in the JNLP and/or injected script.

Within the JAR is the expected assortment of randomly named class files.

When analysing the Java code, one of the first things I wanted to determine was how to decode the strings included in the injected code. For example, in one of the landing pages we have this string (within the APPLET element):

"1e57571611113f04214876143f210a1f0b5d5202232611106504306d
181d2e641f";

Several kits, including Redkit, pass the payload URL in this manner.

Searching through the malicious Java for reference to the code that retrieves and manipulates this value it is fairly easy to find the decryption routine.

Having located this, it is then easy to decrypt the above string (do it in Java, or convert the routine to your favourite scripting language).

In this case, the above string decrypts to the following:

hxxp://[redacted IP]:8080/18541

So once again, we have what appears to be a payload URL. The payload is simply downloaded and executed – the file is not encoded or encrypted.

An overview of Glazunov is shown in the diagram below:

Summary

Recently we have seen a number of the exploit kits slimming down in the vulnerabilities they are targeting, many of them focussing on just Java. As we have seen in this post, Glazunov is no different. To me, the most interesting characteristics of Glazunov are:

• injection of ‘landing page’ code into compromised sites (not just a simple redirect)
• how are compromised sites getting injected? There is a definite bias towards Apache within the victim servers, which may suggest another malicious Apache module (a la Darkleech)?
• similarity to other exploit kits that have been active recently: Sibhost and Flimkit. This is suggestive of either the same criminal groups behind a lot of the current exploit kit activity, or significant code sharing between groups.

To date, Glazunov has been seen distributing predominantly ransomware, the payload of which (potentially losing your data and document files) makes protection from these attacks very important.

So, how can you best protect yourself from this kind of attack?

• General security software 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. Ensure you patch software (application and OS) quickly.
• Java. In the case of Glazunov, the key application to patch is Java. However, given the number of zero-day vulnerabilities recently, users should really ask themselves whether they really need to have Java installed.

Image of computer and skull courtesy of Shutterstock.