Thanks to Sean McLinden and Mila, I have the sample (md5: f79cdd1a958ffe430fff8362642dafb6) that I am going to analyze. In this analysis I will focus on a trick that the Java malware is using to avoid detections.
The malware contains a “reflective-class“, which is interesting since it uses reflection to provide additional “protection” to the real malware. If you want to know more about malware and reflection, please read my previous post here.
Let’s start by analyzing the five methods available in this class.
M1 - function(Object obj, String name).
M2 - function(Object obj, String name, Object  val).
It implements a n-parameters (where n >= 0 ) method call. In this case val represents the arguments of the method that will be invoked.
M3 – constructor(String className, Object  obj, Class  list).
M4 – check(Class  cls, Object  val).
It is an auxiliary method that checks for class compatibility.
M5 – checkMethod(Method m,Object  val).
Here is a graphical schema of a constructor call, normal vs reflected:
The idea is nice indeed, and as we can see this is a generic “trampoline” class that has nothing malicious by itself. Moreover, in my opinion the one who wrote the main malware, probably is not the author of the class above, he/she just used the class in a weird way.
This class has the aim to provide a generic way to call methods and contructors by using Java reflection. This is to confirm that the complexity of Java malware is growing up very fast, soon the AV companies will need to use a dynamic approach to detect that kind of malware, if they are not using any at the moment.