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.
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!
Stage 2: evaluated Javacript (obfuscated)
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:
Resource (a.k.a package in where it will be contextualized)
Byte to be decrypted
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
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