JaZeus: when Zeus meets Java


This is the first analysis as far as I know, of a Zeus malware that uses a Java engine to infect a victim system, by using a multi-stage approach. The sample is md5: 92869c9f958b5bfddefc09d6bfc03591. Are you curious to know more about? If so, please follow me.

Part 1 : The main EXE

If you take a look at the entrypoint of the main executable you can see that the malware is dropping a file on the victim system.
After dropping the file ( a JAR ), the malware reaches the following piece of code:

the main function named: “startJAR” (red box), it has the aim to run the code contained in the Java archive:

So the malware will run the JAR with the following command: java -jar <jar_archive> <parameter>:

After running the JAR archive, the malware seems to terminate its execution:

Dodgy eh?

Part 2 : Investigating the JAR

The archive has the following content:

Well, I need to spend some words on this JAR.

This archive is mainly based on two packages: squareroot.injector and com.sun.jna, the former allows handling PE file, the latter allows low level stuff in Java.
In addition it contains custom code as indicated in the picture above:

- green : Launcher.class
- red : dummy.exe,app.exe
- blue : method

If you take a look at the content of the EXEs, you can see a blob of data. They are obviously encrypted :]

Let’s proceed by taking a look at the code of Launcher.class:

It is referencing the data stuff and decrypting some of them in order to proceed with the rest of the code.
The following figure reports the method used to retrieve the real decryption method value:

Once the code is decrypted it will drop a temporary EXE in the %user_temp% directory.
Would you like to see its content? Sure, you can but you will find only a “normal” EXE, which has nothing malicious…

The point here is that the file actually dropped is not the malicious one. You need to figure out how to obtain such file.
Any ideas? Sure, let’s patch the Java class code in order to let the malicious JAR drop the real malicious EXE  for us :]

To do that, you need to drop somewhere on the disk the content of the malicious EXE in memory.
Here is my quick way:

I have edited the Launcher class in order to drop the in memory EXE in the %user_temp% directory.

Part 3 : The second EXE

By taking a quick look at the entrypoint of this dropped EXE, we can quickly see that the code is mainly the same as the main EXE.
So there is something wrong, no? Actually no, it is using the same dropping scheme, but this time it will drop a new JAR, like the previous one but with a different data section. A matrioska!

Part 4 : Lost?

By reading the analysis above, you can feel yourself a bit lost… I can understand. We are dealing with a sort of matrioska approach that is complicating a bit the analysis, but we like solving puzzle, no?

Here is a recap picture of the malware architecture:

Part 5 : The real Zeus

After retrieving the real executable by using the approach described in the section: “Investigating the JAR”, we will be eventually able to meet Zeus :]
I will not go into the analysis of this sample since it acts like a normal zeus, which connects to a .ru domain in order to download a config file and to proceed with the usual “divine” stuff.

Part 6 : A picture of JaZeus

Final Notes.

I want to thank swirl for the support during the analysis (and the cool image!) and wjm for pointing me to this sample.

I hope you have enjoyed the reading as much as I have enjoyed reversing this piece of malware.
See you in the next post ;]

posted in botnet, java, malware, reversing, zbot, Zeus by Donato Ferrante ( ratsoul )

8 Comments to "JaZeus: when Zeus meets Java"

  1. Giuseppe wrote:

    Great! Good job!

  2. Doppelganger wrote:

    Very interesting method, and, by the way, excellent analysis.

    Keep up the good work

  3. Donato Ferrante ( ratsoul ) wrote:

    Thanks :]

  4. cedric p. wrote:

    great analysis , but where the hell did you find those type of malware O_o”

  5. Donato Ferrante ( ratsoul ) wrote:

    Thanks cedric, I found the sample on: https://zeustracker.abuse.ch/

  6. Nunzio wrote:

    Great Donato, 10++ :)

  7. cap wrote:

    Why Zeus needs to use Java? Why not just run malicious exe directly, without all that complex Java stuff?

  8. Donato Ferrante ( ratsoul ) wrote:

    Thanks for the comments, Nunzio and cap.

    @cap, it is the same reason as why malware keeps changing the packers. In our case, the dropper looks like a file potentially clean, and if we combine injection started by a file potentially clean (in addition from a JAR) the AV detections will drop. How many AVs have a really good memory detection capability? One, two or none ;]

Copyright (c) 2010-2011 InREVERSE - All Right Reserved
Büyükçekmece Evden Eve Nakliyat Esenler Evden Eve Nakliyat Gaziosmanpasa Evden Eve Nakliyat Güngören Evden Eve Nakliyat Kadiköy Evden Eve Nakliyat Kartal Evden Eve Nakliyat Küçükçekmece Evden Eve Nakliyat Maltepe EvdenEve Nakliyat Sisli Evden Eve Nakliyat Tuzla Evden Eve Nakliyat Ümraniye Evden Eve Nakliyat Üsküdar Evden Eve Nakliyat Içerenköy Evden Eve Nakliyat Erenköy Nakliyat Etiler Evden Eve Nakliyat