I am going to analyze a FakeAV (thanks to MDL) md5: 5493bb325f4b3a1cc6efab226d1c4600. This analysis will be focused on how to spot the serial checking algorithm and retrieve a valid serial.

So we have to locate the routine that checks the serial provided and figure out how to craft a valid serial. Since the sample is packed with a custom packer, we have two ways. The first one is to get rid of the packer (maybe I will write about it in the near future) and then work on the unpacked sample. The second way is to get infected (use a Virtual Machine!) and then attach the debugger to the process in memory :]

Once you have chosen your way, we have to find out how to locate the serial checking function. We know that we have to put a string that will be used by the serial checking routine, so what about setting a breakpoint to trap the access to the serial string ?

Once you have set your breakpoint (@0×507288), we can resume the process and then press the “Activate Now” button, after few msec you will reach the following code:

As we can see from the code above, we have a function that takes two parameters: EAX and ESI, in which EAX is pointing to the serial provided, and ESI instead points to a hardcoded string. If we take a closer look at the location pointed by ESI, we can get the “hardcoded serial” which we are looking for:

So in order to activate the FakeAV, we have to provide a serial which matches the hardcoded one, so our serial must be: 1145-17884799-7733. Finally here is the proof that our serial works:

That’s all. Let me know your comments, so I can decide if I take a look at other samples ;]

I hope you have enjoyed the reading.
See you soon!

the last night we have been under an heavy DDoS attack (so lame!), caused by a botnet that has targeted our blog.

Some Details.

The following is a graphical analysis of the botnet that has conducted this attack:

Question/Answer time.

Are we scared? No :]
Will we stop our research? No no :]
Will we stop reversing malwares? No, instead we are going to boost our performace ;]

Final words.

We want to thank our service provider for the help about this issue. Thanks!

Stay tuned!
- the InReverse Crew

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!

%PDF-1.6
...
%%EOF
[GARBAGE]
%PDF-1.6
...
%%EOF

I tried to run my extractor on the sample to retrieve all the streams decompressed but i didn’t found the one containing the famous exploit

The reason why i wasn’t able to recover the exploit is that the second pdf redefined an object (0 1) and so the first dumped stream was overwritten by the last one thus hiding the exploit.

I just did a little modification to preserve all the streams extracted even if there is a id collision, you can download it

here.

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

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

The program is a simple dropper, there are no antidebug tricks nor it uses complex obfuscation techniques, it just extracts the DLL (md5: 7DEFE341246BB1DE68A7AFB233FB8CAF) that contains the core of the virus. The dll itself is sprayed on multiple (scrambled) resources inside the dropper:

The resoures are extracted and concatenated to form the dll in: C:\Windows\System32\msnjkwfb.dll, and after that the dropper invokes a function in the dll responsible for the installation and deletes itself.

The installer registers the dll for autorun, retrieves the WoW path, and copies inside it the dll under the name msvcr70.dll, after, it injects code into the WoW exacutable (wow.exe): adds a section (.ngaut) and changes the program entrypoint to its code. The injected code just loads msvcr70 and gives control back to the original entrypoint.

When the dll is loaded by wow.exe it starts searching for the main window, and then does some checks on the window’s title “World of Warcraft” and class “GxWindowClassD3d” if both checks succeeded it acquires the SeDebugPrivilege and spawns a thread that collects the information using static offsets into the program. Once all the information is gathered it sends a HTTP request to:

with the following request:

?WOWID=%s&Area=%s&WU=%s&WP=%s&MAX=%d/%d&Gold=%d&Serv=%s&rn=%s&key=%s

the site is still up at this time, so be careful WoW gamers

p.s. for those interested here the py script to descramble and merge the extracted resources

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 0×10 (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 ;]

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

- ratsoul & swirl