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).
It implements a generic method call. It uses the provided Object to retrieve its class then it will invoke the class.methods[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).
It implements a n-parameters constructor call.
M4 – check(Class [] cls, Object [] val).
It is an auxiliary method that checks for class compatibility.
M5 – checkMethod(Method m,Object [] val).
It is an auxiliary method that checks if a method call is allowable by checking the parameters types.
Recap Time.
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.
Final notes.
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.