Clicky

Pages

Sunday, April 25, 2010

Mar 17 JAVA Malware Family by Donato "ratsoul" Ferrante - www.InReverse.net Post #4

The following article was written and published by Donato "ratsoul" Ferrante (www.inreverse.net) on March 17, 2010. His recent java analysis publications attracted attention of the exploit kit owners who launched a heavy DDoS attack on April 16, 2010.  DDoS is still in progress today, April 25, 2010. They sent their  demands - remove the analysis articles because it hurts their 'business'.
www.inreverse.net is currently inaccessible, therefore, we are publishing the InReverse java analysis here (this is Post #4) but this time together with the malware samples provided by the InReverse crew.  We ask antivirus and security companies to download, analyze, and develop protection (if you have not done yet).  Thank you.

Download 9 files listed below as a password protected archive (please contact me for the password, if you need it)


All Virustotal scan results are from April 25, 2010. Compare to the initial scan results of some of the samples (1/42 a 0/42 - see post #5
  1. 8d499308df04932ed1b58a78417d6fb9.jar from JAVA Exploit Kit Malware #1 Post #1                       Virustotal 26/40
  2. 7e92d280472ca426aff1c20fbeb8d2db.jar from JAVA Mobile Malware #1 Post #2                         Virustotal 17/41  
  3. 38f083169319d0141532db992d295448.jar  from JAVA Sound malware Post #3                          Virustotal 11/41
  4. 52586e8a85188a0ada59294650c91362.jar from JAVA Sound malware Post #3                             Virustotal  19/41
  5. 3af7627af6348a76d1bf3b7bf31514e0.jar from JAVA malware family Post #4                                    Virustotal 20/38
  6. a022524cb52223a939ba50043d90ff94.jar from JAVA malware family Post #4                                   Virustotal 21/39
  7. d45a156c76f3c34bac0cf22cb586fdd1.jar from JAVA malware family Post #4                                      Virustotal 16/40
  8. 2138bfc0c92b726a13ff5095bd2f2b72.jar  from JAVA Malware evading decompilation Post #5      Virustotal 11/39
  9.  a0585edf638f5d1c556239d3bfaf08db.jar from JAVA Malware evading decompilation Post #5      Virustotal 10/40
        -----------------------------------------

Wednesday, March 17, 2010
Donato "ratsoul" Ferrante

Wednesday, March 17, 2010


JAVA Malware Family

Hello guys,

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.

Let's proceed.

Here is some snippet of code taken from the Applet subclass of each sample above.
Sample 1.


Sample 2.
Sample 3.
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.

Another way to detect this family (a really fast way) is by looking at the ClassLoader subclass. Why? Let's see. Try to guess, if you want ;]

Sample 1.


Sample 2.

Sample 3.
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 :]

3 comments:


Boncho said...
DJ Java Decompiler can be a very handy development tool in your arsenal. It is a must have so as to understand the contents of java binary file:
http://members.fortunecity.com/neshkov/dj.html
http://www.neshkov.com/

Steve said...
Another serialization value used in my samples
0xd30f41af207ff1c8

sha1:713322fe052e593da52e17a2025b35cbfe3ece86
md5:b91d3eaeb5e298df0b86e74729ff4baf

Donato "ratsoul" Ferrante said...
Hi Steve,
thanks for reporting ;]

No comments:

Post a Comment