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
- 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|
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 2018-08-14 a few days ago. In such a date (2018-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 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 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
About the author: Marco Ramilli, Founder of Yoroi
I am a computer security scientist with an intensive hacking background. I do have a MD in computer engineering and a PhD on computer security from University of Bologna. During my PhD program I worked for US Government (@ National Institute of Standards and Technology, Security Division) where I did intensive researches in Malware evasion techniques and penetration testing of electronic voting systems.
I do have experience on security testing since I have been performing penetration testing on several US electronic voting systems. I’ve also been encharged of testing uVote voting system from the Italian Minister of homeland security. I met Palantir Technologies where I was introduced to the Intelligence Ecosystem. I decided to amplify my cyber security experiences by diving into SCADA security issues with some of the most biggest industrial aglomerates in Italy. I finally decided to found Yoroi: an innovative Managed Cyber Security Service Provider developing some of the most amazing cyber security defence center I’ve ever experienced ! Now I technically lead Yoroi defending our customers strongly believing in: Defence Belongs To Humans
The post Malware researcher reverse engineered a threat that went undetected for at least 2 years appeared first on Security Affairs.