JaZeus: when Zeus meets Java

Hello,

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