JAVA Exploit Kit Malware #1

This is my first blog post of the new year. New year new target!
I am going to analyze a JAVA exploit kit malware, the md5 is: 8d499308df04932ed1b58a78417d6fb9.

Since our target is a jar, containing three class files, we try to get more information about it by using a java decompiler (i.e. jd).

After decompilation, we have a java package that contains three classes:

  • C1.
  • C2.
  • C3.


Here we have an Applet subclass that mainly does three things:

  1. It deserializes a serialized object;
  2. It grabs a couple of information via applet parameters: data and cc;
  3. It plays with a custom class loader named: LoaderX.

The most interesting part is the serialized object obviously.
Do you have any idea about the usage of the serialized object in the above code ?

Well, I will lead you to the right answer. Please just focus on the above AppletX code. If you pay attention to the above code, you can see the initialization of localObject, it is located just above the if test. But we can’t see any sort of explicit initialization for LoaderX.instance. In fact the initialization lies in the deserialization routine… nice eh ?

Here is a visual recap:

Let’s examine the custom class loader now.


Here is the custom loader, I will report only the relevant parts. We have a custom class loader that inherits from the Java ClassLoader class.

The custom class loader (LoaderX) sets the “instance” static field to “this“, in order to be not garbage collected. This trick allows LoaderX to be used further after the deserialization. In fact it is required in order to use the following method:

The bootstrapPayload method above does the following things:

  1. It loads the payload class (PayloadX), by setting the ProtectionDomain;
  2. It sets data and cc parameters for the PayloadX class and then instantiates the PayloadX object.

As we can see, this custom class loader (LoaderX) is used to exploit a Java Runtime Environment (JRE) vulnerability, which is reported here.

Well, we have finished playing with the LoaderX class, let’s play with the PayloadX class now :]


I will summarize the behaviour of this class with the following schema:

It uses data parameter and cc parameter as follow:

  • data: points to a malicious site where it will find one or more malwares to download.
  • cc: indicates the number of malwares to download. By default “null” means one.

So suppose that data is: malicious.x/mw and cc is: 3.
The above method will download (and execute) the three malwares located at:

  • malicious.x/mw0
  • malicious.x/mw1
  • malicious.x/mw2

into the system temporary directory of the victim system. Each downloaded file will be an EXE file with a random number as name.

Final Notes.

This jar is a pre-built kit that allows to infect victim systems with custom malwares, by exploiting a well known JRE vulnerability. This kit is thought to be embedded into malicious webpages and customized by using data and cc applet parameters to control its behaviour.

It’s all.. I hope you have enjoyed the reading.

Alla prossima ;]


2 Responses to “JAVA Exploit Kit Malware #1”

  1. 1 Seth January 6, 2010 at 3:14 pm

    Thank you for the detailed write up on this Java exploit kit. I’ve never encountered one in the wild, so it was interesting to see a real-world example.

  2. 2 Duarte Silva January 6, 2010 at 7:58 pm

    I have done a similar analysis to such malware,
    check it out at

Comments are currently closed.


%d bloggers like this: