Dissecting Java Malware

Word of warning

When handling malware, be extra careful and preferable do your examination on a device that you can easily erase or restore to previous state. Try not to run any malware on your computer, even with decompilers if you are not absolutely sure what you are doing.

Some background

Some time ago, there were a couple of suspicious links posted to the hackthis.co.uk forums. All the text-book features of probable malware were there:

• The poster signs in and posts links to several applications
• The poster doesn't answer any questions
• The poster didn't log in again to the forum

The above reasons made me doubt the legitimacy of the files and decided to investigate further. Natural first stop was the virustotal.com website, but it didn't give any positive results, or in other words: no viruses detected. I almost wished that they would've given some results, but now I had to look into the file myself.

Some more background

For those of you, who don't know much about Java, I'll say that it's not compiled to machine language, but instead to Java Bytecode, which is then executed by the Java Virtual Machine. You need a JVM built for your operating system, but with it, you should be able to run pretty much any Java application.

Since the Java isn't compiled to machine language, it is a lot easier to decompile, even to the source code. You could even do it by hand, if you knew the Java bytecode instructions and the structure of a java class. This is tedious work at best and there are good tools to use instead; such as jad, java decompiler and many others.

So now you know about decompiling .class files to source code. Just another point before we continue: the .jar files are basically .zip files that - when executed - are first unzipped and then the java class, which is defined as the main class within the META-INF folder (which too lies inside the jar package) is executed.

Start the work

Since the application was SQLi-Checker.jar we first unzip the folder:

If we had more than one class file now, we should check the META-INF folder for the main class. Now we can just decompile Principal.class with jad (yea, it's a bit outdated, but usually works well enough) and change the extension of the generated file from jad to java (just to get the code hilighting to work):

Then just open the java file with your favourite editor. What we see is some (badly) obfuscated code. You can take a look at the obfuscated source code in this pastebin entry: http://pastebin.com/aRPpF9jc

If we simply rename the variables, using search-replace, we can make this code more easily readable. To get started, I renamed variables based on their types, for example:

ZipEntry kjasdjasndasdjansdnkqpwokdlassldkmkxvv;
→ ZipEntry zipEntry;

If we work through the whole file like this and also assign reasonable names to the methods, we get something like the code in this paste.

If you know any Java, it's pretty easy to say what the code does. And if you don't, here's a brief explanation:

1. file Favicon.ico is opened as a zip archive
• lines 16-22 open the file as input stream
2. files are extracted and saved as temp files
• lines 29-38 extract the files and pass them to be saved and executed
3. execute the extracted files
• the method executeFile, starting from line 55

So, the Favicon.ico is a zip file? Lets see:

2 files extracted... I'll cut some corners here and just say that the actual malware was in the 1java_tool.jar and the 0SQLi-Checker.exe was a legit application, written in C#. C#, like other .net languages, can too be decompiled, one such tool is dotPeek by Jetbrains. If you have this malware file somewhere, it's a good practice to check out the insides of the exe too.

Again I unzipped the jar file and revealed even more files. Felt like opening the russian matryoshka dolls :p

This time, a lot more files were extracted, and by checking the Manifest.mf file, we can find out that it's the Adwind.class, which is executed.

There were lots of files with the extension adwind, such as the Principal.adwind in the file listing above and I had no idea what they were. Even the file utility couldn't identify them:

Let's continue with what we know and perhaps we find out what kind of files they are.

Then I decompiled the Adwind.class and again looked at the source code. I won't go into too much detail here, but it basically instantiated a custom class loader (which was under the extras folder), passed the contents of the file ID as a decryption key and the string "Principal". After that it executed what ever the class loader returned.

The natural step for me was to then check the class loader, which too was a Java class. Again I fired up Jad and read the code.

Then did the same for the Constante -class, which was referenced from the classloader. More specifically it's method Constantino, which I found to be a decryptor or decoder. With it I managed to write a decoder of my own to decode all the adwind -files to normal Java classes, which I could then investigate with Jad.

What still remained was the config.xml -file, which was also encoded similarily as the adwind files. Only difference was that the key was hard coded in one of the encoded Java classes. From that config file, it was obvious that this was a Adwind RAT v2.0 (it said so, right in the config :p)

The config file also told where the RAT will try to contact and in what port is the master server listening to connections.

This post is already long enough, so I'll just briefly explain some of the functionality of the RAT here. It can:

1. Take screenshots and send them to the master
2. Show prompts and alerts to the user
3. Open a web browser in the url which the master orders
4. Control mouse and keyboard
5. Use the infected victim as a tool in DDOSing
6. Download and execute jar files
7. Update itself.

There probably was even more functionalities, but that's how far I went. Bascially, if it can download any jar file, it can do anything that can be accomplished with Java.

Resources

The adwind file decoder source can be seen in pastebin. To use it, dl the source code as decoder.java, compile with

javac decoder.java

After compiling it, you can decode .adwind files with it. The syntax is:

java decoder key filename  [filename2] [filename3...]

Planting code in memory - How to bypass Windows logon prompt

Recently I was asked to demonstrate the well known DMA attack. I thought that I had to look for PoC codes and hack them to suit my purposes. How wrong was I?It turns out, that I was really wrong...

First something about the DMA. The technique is used to allow external devices to access the RAM directly, bypassing much of the limiting controls posed by for example the operating systems. This makes DMA-enabled interfaces much faster than if the data would first be passed to the operating system for possible sanitation and using its memory management. DMA enabled interfaces are FireWire, ThunderBolt, Express Card, PCI and PCI Express.

Next the rig: I had 2 laptops, each equipped with Express Card slots, so I purchased 2 FireWire cards for EC and a Cable to connect the 2 cards. The total cost was around 70 EUR.

The target was a Windows 7, with all the available security updates installed and also with a commercial Anti-Virus solution installed. Also the hard disk was encrypted, so the usual cold boot attacks were out of the question.

For attacking I made a clean install of Ubuntu on the other laptop. I will not go into details about what I installed, but I only installed the dependencies for Inception. Once I had Inception installed and the FireWire cards working on the Ubuntu laptop, I was ready to go.

First, I fired up both machines and interconnected them via the FireWire cable. Windows was nice enough to notice me that "a new device has been found" sound when I plugged in the EC Card. I also confirmed that Ubuntu correctly identified it with lspci. Time to fire up the Inception. I first ran it with the probe -flag (-p):

Cool! Everything is working and the Inception even tells me that I'm currently connected to a Microsoft device. Time to test if inception really delivers what is promised. I again fire up inception and follow the instructions on the screen:

Time to wait while the Inception scans the victims memory for the msv1_0.dll, which handles the password checking function. This can take some time, because the target can nowadays have lots and lots of memory... Luckily Inception displays a progress bar, so you can tell that it hasn't hanged:

Once the dll has been found in the memory, Inception will overwrite it to accept any password. After maybe 2 minutes the dll is found and patched:

Patching successful, eh? Time to go to the Windows box and log in with an empty password. Yes! We are in: Local admin permissions aquired!

Naturally there are some limitations for this attack:

1. You are able to log in only local accounts or those domain accounts whose credentials are cached locally
2. OS X Lion disables DMA when no  user is logged in and the FileVault is enabled. You can still use Inception for privilege escalation if the user is logged in up to OS X version 10.7.2 
3. If DMA is off, then naturally this won't work. In Windows this can be done by disabling the SPB-2 driver

In conclusion: The DMA attack works and is no longer just a theoretical attack vector. The physical security should be taken care of and again: services (and in this case drivers) which are not needed, should be disabled to reduce the attack surface.