Archive for the 'java' Category

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

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 :]

JAVA Sound Malware

Hello guys,

I’m sorry for the few posts in the last weeks, but I was quite busy. Today I am going to analyze another interesting JAVA malware.

Our target is a jar, md5: 38f083169319d0141532db992d295448. The jar contains one class: AppletX.  After using a java decompiler on our target, we will get the AppletX class code.

I will report only the relevant parts. Let’s go..


Firstly, the malware tries to discover the operating system in use by using System.getProperty(“os.name”), then it fills str1 according to the O.S. in use.

At this point the malware proceeds by exploiting a vulnerability located into getSoundBank method [CVE-2009-3867] to execute malicious code on the victim system. It retrieves the parameters: sc and np (meaningful names) and then it uses the following spray method in order to place the shellcode:


As we can see, this function simply converts the parameters into hex and then it calls the real spray method:


This method is the heart or engine(if you prefer) of the malware. I have underlined the value of the variable i, since I have found another variant of this malware md5: 52586e8a85188a0ada59294650c91362, that only changes the value of i to an higher value.

This malware is another good reason to turn off all java* contents while browsing the web. As always feedbacks and comments are welcome.

I hope you have enjoyed this post.
See you soon ;]

JAVA Mobile Malware #1

Hi guys,

today I will focus on a JAVA mobile malware (md5 is: 7e92d280472ca426aff1c20fbeb8d2db).

It is spread as jar, containing a class with an attractive name. The jar contains three files:

  • a java class (the malware engine);
  • an icon image (it is used in order to be attractive..);
  • an inf file (it is used to extract sms information).

The following is the class code after the usage of jd. I report only relevant parts:

LoadData:

This method is used to read the inf file in order to fill smsnumber and smstext fields. It uses the first byte of the inf file to know how many sms should be sent.

InputStreamString:

This method is used to read user-defined strings from the inf file.

SendSMS:

This method is used to send the crafted sms.

Focus on inf:

As we can see, the malware uses the inf file to extract information such as: sms number and text. Let’s take a look at this file to understand its format:


Question: have you noticed anything wrong in this format ? Before proceeding, please focus on inf format and the three methods reported above.

Answer: It seems that we have a programming bug or a bad-edited inf file. In fact, the malware will try to send 0x10 (16) sms by using this inf, but it has information only for 8 sms. Maybe this is a mistake of the malware author, or someone else has wrongly edited this file.

I hope you have enjoyed this article… see you soon ;]

JAVA Exploit Kit Malware #1

This is my first blog post of the new year. New year new target!
I am going to analyze a JAVA exploit kit malware, the md5 is: 8d499308df04932ed1b58a78417d6fb9.

Since our target is a jar, containing three class files, we try to get more information about it by using a java decompiler (i.e. jd).

After decompilation, we have a java package that contains three classes:

  • C1. AppletX.java
  • C2. LoaderX.java
  • C3. PayloadX.java


C1. AppletX.java


Here we have an Applet subclass that mainly does three things:

  1. It deserializes a serialized object;
  2. It grabs a couple of information via applet parameters: data and cc;
  3. It plays with a custom class loader named: LoaderX.

The most interesting part is the serialized object obviously.
Do you have any idea about the usage of the serialized object in the above code ?

Well, I will lead you to the right answer. Please just focus on the above AppletX code. If you pay attention to the above code, you can see the initialization of localObject, it is located just above the if test. But we can’t see any sort of explicit initialization for LoaderX.instance. In fact the initialization lies in the deserialization routine… nice eh ?

Here is a visual recap:

Let’s examine the custom class loader now.


C2. LoaderX.java

Here is the custom loader, I will report only the relevant parts. We have a custom class loader that inherits from the Java ClassLoader class.

The custom class loader (LoaderX) sets the “instance” static field to “this“, in order to be not garbage collected. This trick allows LoaderX to be used further after the deserialization. In fact it is required in order to use the following method:

The bootstrapPayload method above does the following things:

  1. It loads the payload class (PayloadX), by setting the ProtectionDomain;
  2. It sets data and cc parameters for the PayloadX class and then instantiates the PayloadX object.

As we can see, this custom class loader (LoaderX) is used to exploit a Java Runtime Environment (JRE) vulnerability, which is reported here.

Well, we have finished playing with the LoaderX class, let’s play with the PayloadX class now :]


C3. PayloadX.java

I will summarize the behaviour of this class with the following schema:


It uses data parameter and cc parameter as follow:

  • data: points to a malicious site where it will find one or more malwares to download.
  • cc: indicates the number of malwares to download. By default “null” means one.

So suppose that data is: malicious.x/mw and cc is: 3.
The above method will download (and execute) the three malwares located at:

  • malicious.x/mw0
  • malicious.x/mw1
  • malicious.x/mw2

into the system temporary directory of the victim system. Each downloaded file will be an EXE file with a random number as name.


Final Notes.

This jar is a pre-built kit that allows to infect victim systems with custom malwares, by exploiting a well known JRE vulnerability. This kit is thought to be embedded into malicious webpages and customized by using data and cc applet parameters to control its behaviour.

It’s all.. I hope you have enjoyed the reading.

Alla prossima ;]