I think therefore I change

Some malware authors tend to be tricky to break detections based on static signature matching. So they scramble the malware code in a way that they consider to be useful to save the malware from being detected.

So here we have a Java malware, which is trying to evade detection. Let’s take a look at the decompiled sample.

Starting from the imports, we can notice the following information:

We can see that this is an Applet which uses byte-level and object-level input.

Here is a byte array obtained by the CfVCpc function, which takes two parameters:

At this point we have to figure out what is hiding in this sequence. So let’s explore the CfVCpc function.

Well, now it is obvious what this function does. It takes an input string s and according to the provided flag decides if it is required or not to remove from the string s all the occurrences of “m“ and “r“. Are you curious to know about the replaced string? Well, please see below:

The red group (in the picture above) leads us to a Java serialized object. Now we know that the provided string is a serialized object. But we miss one part. We have to understand how the malware can propagate itself to a victim system. Let’s go!

First it checks for a target system, in this case the malware checks for Windows systems:

then it loads the serialized object, in the following way:

finally, it loads some Applet parameters and it handles the malicious payload:

As we can see above, this malware is trying to load a “malformed” serialized object in order to exploit a Java Runtime Environment vulnerability (CVE-2008-5353), more details about this vulnerability are here.

We generically detect this malware family as Sus/JavaObCL-A and Mal/JavaObCL-A. We also detect the malware payload as Sus/JavaPld-A.