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. AppletX.java
- C2. LoaderX.java
- C3. PayloadX.java
- It deserializes a serialized object;
- It grabs a couple of information via applet parameters: data and cc;
- 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:
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:
- It loads the payload class (PayloadX), by setting the ProtectionDomain;
- 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:
- 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:
into the system temporary directory of the victim system. Each downloaded file will be an EXE file with a random number as name.
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 ;]