Malware researcher reverse engineered a threat that went undetected for at least 2 years
20.8.18 securityaffairs Virus

The popular malware researchers Marco Ramilli has analyzed a malware that remained under the radar for more than two years.
Today I’d like to share the following reverse engineering path since it ended up to be more complex respect what I thought. The full path took me about hours work and the sample covers many obfuscation steps and implementation languages.
During the analysis time, only really few Antivirus (6 out of 60) were able to “detect” the sample. Actually, none really detected it, but some AVs triggered “generic unwanted software” signature, without being able to really figure it out. As usually, I am not going to show you who was able to detect it compared to the one who wasn’t, since I won’t ending on wrong a declaration such as (for example): “Marco said that X is better than Y”. Anyway, having the hash file I believe it would be enough to search for such information.

AntiVirus Coverage

The Sample (SHA256: e5c67daef2226a9e042837f6fad5b338d730e7d241ae0786d091895b2a1b8681) presents itself as a JAR file. The first thought that you might have as an experienced malware reverse engineer would be: “Ok, another bytecode reversing night, easy.. just put focus and debug on it…”. BUT surprisingly when you decompile the sample you read the following class!

Stage1: JAR invoking JavaScript
A Java Method that invokes (through evals) an embedded “Javascript” file ! This is totally interesting stuff :D. Let’s follow up on stages and see where it goes. The extracted Javascript (stage 2) looks like the following image. The “OOoo00” obfuscation technique has been used. Personally I do not like this obfuscation technique it’s harder to reverse respect to different obfuscation techniques, even the CTR-F takes confused on substrings, but we need to figure out what it does, so let’s try to manually substitute every string and watch-out for matching substrings (in order words %s/OOoo00/varName/g won’t work at all.

Stage 2: evaluated Javacript (obfuscated)
Manually substitution takes “forever” if you do not have a substitution framework which asks you for a string, it replaces such string (and not a substring) and eventually represents the new beautified JavaScript. After many substitutions (I really have no idea how many :D) you land on a quite readable JavaScript as the following one (click on it to make it bigger).

Stage 2: Manually Deobfuscated JavaScript
What is interesting (at least in my personal point of view) is the way the attacker (ab)used the JS-JVM integration. JavaScript takes the Java context by meaning it might use Java functions calling contextual java classes. In this stage the JavaScript is loading an encrypted content from the original JAR, using a KEY decrypts such a content and finally loads it (Dynamic Class Loader) on memory in order to fire it up as a new Java code.
The used encryption algorithm is AES and everything we need to decrypt is in this file, so let’s build up a simple python script to print our decryption parameters. The following image shows the decoding script made to easily reconstruct AES-KEY and surrounded parameters. NB: The written python code is not for production, is not protected and full of imprecisions. I made it up just for decode AES key and such, so don’t judge it, take it as a known weak but working dirty code.

Python Script to Decode AES-KEY

We now have every decoding parameter, we just need to decrypt the classes by using the following data:
ClassName
Resource (a.k.a package in where it will be contextualized)
Byte to be decrypted
Secret Key
Byte Length to be decrypted
A Simple Java Decrypter has been developed following the original Malware code. Once run, the following code was decrypted.

Stage 3 Decrypted JavaClass
Here my favorite point. As you might appreciate from the previous image we are facing a new stage (Stage 3). What is interesting about this new stage is in the way it reflects the old code. It is a defacto replica of Stage 2. We have new classes to be decrypted (red tag on the image), the same algorithm (orange label on the image), a new KEY (this time is not derived by algorithm as was in Stage 2 but simply in clear text, orange tag on the image) and the same reflective technique in which attacker dynamically loads memory decrypted content on Java.loader and uses it to decrypt again a further step, and after that it replies the code again and again. There is an interesting difference although, this stage builds up a new in-memory stage (let’s call Stage 4) by adding static GZIpped contents at the end of encrypted section (light blue tag on image). By using that technique the attacker can reach as many decryption stages as he desires.
At the end of the decryption loop (which took a while, really ) the sample saves (or drops from itself, if you wish) an additional file placed in AppData – Local – Temp named: _ARandomDecimalNumber.class. This .class is actually a JAR file carrying a whole function set. The final stage before ending up runs the following command:
java -jar _ARandomDecimalNumber.class
The execution of such a command drops on local HardDrive (AppData-Local-Temp) three new files named: RetrieveRandomNumber.vbs (2x) and RandomName.reg. The following image represents a simple ‘cat’ command on the just dropped files.

On Final Stage VBS Run Files
It’s quite funny to see the attacker needed a new language script (he already needed Java, as the original entry point, Javascript as payload decrypt and now he is using VBS ! ) to query WMI in order to retrieve installed AntiVirus and Installed Firewall information. Significative the choice to use a .reg file to enumerate tons of security tools that have been widely used by analysts to analyze Malware. The attacker enumerates 571 possible analysis tools that should not be present on the target machine (Victim). Brave, but not neat at all (on my personal point of view). The sample does not evade the system but it forces the System Kill of such a process independently if they are installed or not, just like Brute force Killing process. The sample enters in a big loop where it launches 571 sigKill one for each enumerated (.reg) analysis program. It copies through xcopy.exe the entire Java VM into AppData-Roaming-Oracle and by changing local environment classpath uses it to perform the following actions. It finally drops and executes another payload called “plugins”.
The following image shows plugins and initial new stage JAR stage.

Final Droppe Files (_RandomDec and plugins)
At a first sight experienced Malware reverser engineer would notice that the original sample finally drops a AdWind/JRat Malware having as a main target to steal files and personal information from victims. While the AdWind/JRat is not interesting per-se since widely analysed, this new way to deliver AdWind/JRat, it is definitely fascinating me. The attacker mixed up Obfuscation Techniques, Decryption Techniques, File–less abilities, Multi Language Stages and Evasions* Techniques in order to deliver this AdWind/JRat version. Multiple programming styles have been found during the analysis path. Each Stage belonging with specific programming language is atomic by meaning that could be run separately and each following stage could easily consume its outputs. All these indicators make me believe the original Sample has been built by using Malware builder, which BTW, perfectly fits the AdWind philosophy to run as a service platform.
A final consideration is about timing. Checking the VirusTotal details (remembering that only 6 on 60 AV were able to say the original JAR was malicious or unwanted) you might notice the following timeline.

Detection Time Line (VirusTotal)
VT shows the first time it captured that hash (sha256): it was in 2016. But then the first submission is on 18-08-14 a few days ago. In such a date (18-08-14) only 6 out of 60 detected a suspicious (malicious) behavior and triggered on red state. But what about the almost 2 years between December 2016 and August 18? If we assume the Malware is 2 years old, was it silent until now (until my submission)? Have we had technology two years ago to detect such a threat? Or could it be a targeted attack that took almost 2 years before being deployed?
I currently have no answers to such questions, hope you might find some.
*Actually not really an evasion technique, more likely a toolset mitigation.
Further details on the malware, including the IoCs are reported in the original analysis published by Marco Ramilli