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
- 8d499308df04932ed1b58a78417d6fb9.jar from JAVA Exploit Kit Malware #1 Post #1 Virustotal 26/40
- 7e92d280472ca426aff1c20fbeb8d2db.jar from JAVA Mobile Malware #1 Post #2 Virustotal 17/41
- 38f083169319d0141532db992d295448.jar from JAVA Sound malware Post #3 Virustotal 11/41
- 52586e8a85188a0ada59294650c91362.jar from JAVA Sound malware Post #3 Virustotal 19/41
- 3af7627af6348a76d1bf3b7bf31514e0.jar from JAVA malware family Post #4 Virustotal 20/38
- a022524cb52223a939ba50043d90ff94.jar from JAVA malware family Post #4 Virustotal 21/39
- d45a156c76f3c34bac0cf22cb586fdd1.jar from JAVA malware family Post #4 Virustotal 16/40
- 2138bfc0c92b726a13ff5095bd2f2b72.jar from JAVA Malware evading decompilation Post #5 Virustotal 11/39
- a0585edf638f5d1c556239d3bfaf08db.jar from JAVA Malware evading decompilation Post #5 Virustotal 10/40
Wednesday, March 17, 2010Donato "ratsoul" Ferrante
Wednesday, March 17, 2010
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.Sample 1.
Sample 2.Sample 3.
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 ;]
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 :]