Everything started from a well edited Italian language email (given to me from a colleague of mine, thank you Luca!) reaching out many Italian companies. The Italian language email had a weird attachment: ordine_065.js
(it would be "Order Form" in English) which appeared "quite malicious" to me.
By editing the .js
attachment it becomes clear that it is not an "order form" but contrary it turns out to be a downloader. The following image shows the .JS content. Our reverse adventure is going to start: we are facing a first stage of infection.
|Stage 1: Downloader|
The romantic dropper (code on the previous image) downloads and executes a PE file (let's call it Second stage) from 22.214.171.124
. The IP address seems to be hosted by a telecommunication company who sells cloud services such as: dedicated servers, colocation systems, and so on located in Ukraine. The used language in the current stage perfectly fits the dropping website language.
Please keep in mind this language since later on, it would become a nice find.
By listing the http://126.96.36.199,
we might appreciate an nice malware "implant" where multiple files are in place, probably to serve multiple attack vectors (es: emails, or tag inclusions, or script inclusion into benevolent html files). My first analysis was on obf.txt (the following image shows a small piece of it) which woke up my curiosity.
|Lateral Analysis: obf.txt|
That piece of VB code, could be used to obfuscate VBScripts. Many pieces of code belonging to obf.txt are related to the Russian Script-Coding.com thread
published it on 2011. Another interesting file is the Certificate.js which shows the following code.
|Lateral Analysis: Certificate.js|
Once beautified it becomes easier to read:
|Lateral Analysis: Fresh IoC on Dropper 2|
Now, it's obvious that it tries to: (i) download stat.exe
from third party web sources, (ii) to rename the downloaded file using the Math.random().toString(36).substr(2, 9) + ".exe"
and to (iii) launch it by using the var VTmBaOw = new ActiveXObject("WScript.Shell");
This is super fun and interesting but I am getting faraway from my original attack path.
So, let's assume the downloaded file are the same (really they are not) and lets get back to our original Stage 1 where a romantic .JS dropper downloads the "set.tmp
" file and executes it (please refer to image Stage 1: Downloader).
The dropped file is: 00b42e2b18239585ed423e238705e501aa618dba
which is actually evading SandBoxes and AntiVirus engines. It is a PE file which has been implemented in a valid .NET compiled source. Let's call it Stage 2, since coming after the Stage 1 ;). Decompiling the "Second stage" some "ambiguous and oriental characters" appear as content in the "array" variable (please refer to the following code image).
|Stage 2: Oriental Characters in array|
By following those "interesting strings" ("interesting strings" by meaning to be faraway from the previous detected language) I landed on a "reflective function" which used a .NET Assembly.Load() to dynamically load the binary translation of the "array"-variable and an EntryPoin.Invoke() to dynamically run the binary. This is a well known .NET technique exploiting the .NET language ability to introspect its own runtime.
|Stage 2: Assembly.Load and EntryPoint.Invoke|
In order to get the dynamically generate binary "array"-variable I decided to patch the Sample code. The following picture shows how the .NET has been patched, in other words by simply forcing the control flow to saves the dynamically generated content on HD (the red breakpoint). In this specific case we are facing a third stage of infection composed by an additional PE file (Let's have a look to HexEditor for the 'MZ' string). Let's call it Stage 3.
|Stage 3: Decrypted PE|
In order to create the Stage 3, Stage 2 needed to decrypt the binary translation of "array" variable. Analysing the .NET code is not hard to figure out where Stage 2 decrypts the Stage 3. The Decryption loop has been implemented through a simple XOR-based encryption algorithm within a hardcoded key as shown in the following image.
|Stage 2: decryption key|
The decrypted new stage (named: Stage 3) happens to be an interpreted PE file as well ! It is built over Microsoft VisualBasic technology (Do you remember the Lateral Analysis ??) and it's hardy obfuscated (maybe from obf.txt ? ... of course !). The following image shows the Third Stage structure.
|Stage 3: Structure|
The structures highlights three main modules as follows:
1) Anti Module. Aim of such a module is to implement various evasion techniques in order to weaponize the sample and block execution on VMs.
2) Service. Aim of such a module is to launch a background service.
3) RunPe. Aim of such a module is to launch an additional encrypted PE file placed in the resource folder.
Let's try to investigare a little bit better what these modules do. The Anti Module tries to figure out if the analysed sample lands on a controlled (emulated and/or simulated) environment in order to change its behaviour. The following images shows some of the performed checks. The sample tries to identify SanBoxie, fiddler and wireshark in order to dynamically change its own behaviour.
|Stage 3: evasion checks|
The service module
tries to spawn a windows service and to disable many Windows features such as for example (but not limited to): EnableLUA, DisableCMD, DisableTaskMgr, etc... The following image shows some of the described actions.
|Stage 3: Disabling Windows "Protections"|
Finally the RunPE
modules decrypts a further encrypted and embedded resource an tries to run it. The following images show the decryption loop following by the decrypted payload.
|Stage 3: Decryption Loop|
|Stage 3: decrypted payload|
On line 253 the Third Stage decrypts the resource and executes it. In the above picture you might appreciate the decrypted sequence: 0x4D, 0x5A, 0x90 which happens to be an additional windows PE. Let's call it Stage: 4. The new stage appears to be a classic PE file written on C++, we'll need a debugger to get into it. By analysing its dynamic behaviour (thanks to IDA Pro) it has been easy to catch the dropped files and to understand how that Sample uses them. The following image shows two dropped files (.nls and .bat) being saved on the HardDrive after the Stage 4 call.
|Stage 4: dropping files (.nls and .bat)|
The resulting .bat
file tries to execute (through cmd.exe /c) %1 within the parameter %2 as shown in the next picture. If the file to be executed does not exist in HD it deletes the original file as well (itself).
|Stage 4: file execution|
%1 is an additional dropped PE File while %2 is a "random" value (key? unique id?).
|Stage 4: Interesting "keys" passed to the .bat file.|
Once the sample is run it performs external requests such the following ones, exfiltrating encrypted informations:
Interesting to observe the sample complexity and how it is currently spread over Italian organisations. Interesting (at least on my personal point of view) how False flag attacks are developed in order to confuse the attack attribution (which is nowadays a huge technical issue) as well. Unfortunately nowadays through the information I have it is not possible to attribute that attack, the dropper has Russian strings on it, one of the payload has "oriental characters" on it, but again I am not able to say the attack is the result of a "joint venture" from Russia and China or it's something hybrid or again it is borrowed or acquire from one to another, etc.. etc... For sure it's not as it appears :D ! Index Of Compromise
Following some of the most interesting Index Of Compromise.