do you remember one of my last post about a JAVA malware exploiting a vulnerability related to the deserialization? If not, you can read it here.
In the last days I have found a lot of variants of this malware. I picked for this post the following:
sample 1: 3af7627af6348a76d1bf3b7bf31514e0
sample 2: a022524cb52223a939ba50043d90ff94
sample 3: d45a156c76f3c34bac0cf22cb586fdd1
In this post we will try to discover a quick way to detect this “family” of malware.
Each jar comes with 3 classes as for the original sample that I analyzed. The class names are changed into AdgredY, DyesyasZ, LoaderX, for one of these samples.
First thing to note is about the class names. We can note the following relations:
C1. AppletX is AdgredY;
C2. PayloadX is DyesyasZ;
C3. LoaderX is LoaderX.
The class name length is the same as the original one, also the position of the capital letters is preserved.
Here is some snippet of code taken from the Applet subclass of each sample above.
As we can see, the malware authors are trying to conceal their dirty applet by using some obfuscation :]
How we can get rid of this obfuscation? If we pay attention we can quickly extract the following common “flow”:
A similiar analysis can be done for the other two classes: PayloadX and LoaderX.
So the first way to detect this family is by looking at the flow of the program. Flow that in these samples is quite trivial.
Well, it seems that the malware authors are customizing the code by using different values for variables and some obfuscation.
But they have one thing that destroys their “obfuscated” castle: the serialVersionUID. As we can see each sample has the same value for this field.
It’s all. I hope you have enjoyed this post.
See you soon :]