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 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.
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 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:
- file Favicon.ico is opened as a zip archive
- lines 16-22 open the file as input stream
- lines 29-38 extract the files and pass them to be saved and executed
- 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:
- Take screenshots and send them to the master
- Show prompts and alerts to the user
- Open a web browser in the url which the master orders
- Control mouse and keyboard
- Use the infected victim as a tool in DDOSing
- Download and execute jar files
- 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.
The adwind file decoder source can be seen in pastebin. To use it, dl the source code as decoder.java, compile with
After compiling it, you can decode .adwind files with it. The syntax is:
java decoder key filename [filename2] [filename3...]