Interesting hidden threat since 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 wont ending on wrong a declarations 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.

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

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 have 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 wont work at all.

Manually substitution takes “forever” if you do not have a substitution framework which asks you for a string, it replace 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).

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.

We now have every decoding parameter, we just need to decrypt the classes by using the following data:

A Simple Java Decrypter has been developed following the original Malware code. Once run, the following code was decrypted. 

Here my favourite 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 reflect the old code. It is a defacto replica of the 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:

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.

It’s quite funny to see the attacker needed a new language script (he already needed Java, as 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 analyse 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 samples 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.

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 he following time line.

VT shows the first time it captured that hash (sha256): it was on 2016. But then the fist submission is on 2018-08-14 few days ago. In such a date (2018-08-14) only 6 out of 60 detected a suspicious (malicious) behaviour and triggered on red state. But what about the almost 2 years between December 2016 and August 2018 ? 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 a questions, hope you might find some.

*Actually not really an evasion technique, more likely a toolset mitigation.

You will not find Command and Controls (c2) and dropping url because: (i) dropping url/s was/were not found: the sample auto-extracts contents from itself. (ii) No C2 during the delivery stage. Of course AdWind/JRat does C2 but, as explained, the analyst did not followed on the analysis of AdWind/JRat since well-known malware.

  

hash: 

File Paths: