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 !
|Stage 2: evaluated Javacript (obfuscated)|
|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 contextualised)
- 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 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:
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 he following time line.
|Detection Time Line (VirusTotal)|
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.
- e5c67daef2226a9e042837f6fad5b338d730e7d241ae0786d091895b2a1b8681 (Original)
- 97d585b6aff62fb4e43e7e6a5f816dcd7a14be11a88b109a9ba9e8cd4c456eb9 (_RandomDec..)
- 9da575dd2d5b7c1e9bab8b51a16cde457b3371c6dcdb0537356cf1497fa868f6 (Retreive1)
- 45bfe34aa3ef932f75101246eb53d032f5e7cf6d1f5b4e495334955a255f32e7 (Retreive2)
- 296a0ed2a3575e02ba22e74fd5f8740af4f72b629e4e50643ac0c156694a5f3c (.reg)
- 32d28c43af1afc977b96436b7f638fba15188e6120eeaefa1ad91fb82015fd80 (plugins)