JAVA Malware evading decompilation

Hello,

some days ago Param (thanks!) one of our blog readers sent me a couple of undetected JAVA malwares, which I’m going to analyze, the md5 are:

(Sample 1) 2138bfc0c92b726a13ff5095bd2f2b72
(Sample 2) a0585edf638f5d1c556239d3bfaf08db

At this time, both of this malware have a low detection, the first one 1/42 and the second one 0/42 from VirusTotal.

One of the interesting things is that if you try to decompile these samples by using jD you will get the following notice:

So after a little investigation I figured out the reason. The reason is that jD is unable to handle methods with a large body.

Is it a problem ? No. To proceed with the analysis we can summon JAD. In fact by using JAD we can obtain the full code. Here are some snippets taken from the two samples.

(I will go fast on the analysis, at the end of the post you can find a couple of links with more details about these malwares.)

Sample 1:
([CVE-2009-3867])

Imports reveal a lot of information about what the malware is trying to “use”…

A lot of strings and a known pattern…

Here is the shellcode…

And the exploitation…

Sample 2:
([CVE-2008-5353] )

Again the imports are telling us that the malware will try to load “untrusted” class..

Here the malware gets data and cc fields…

This is the strategy used to run the malware on the victim system:


As we can see we have a long obfuscation that uses string replacements, scrambled names and base64 encoding.

In conclusion, both these malwares are using well known vulnerabilities being exploited since a while. These malwares still have no generic detections at all.

If you are interested you can read more in detail about these vulnerabilities in two of my previous posts here and here.

See ya!

Advertisements


%d bloggers like this: