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 31.148.99.254. 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://31.148.99.254, 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 where dab00 published it on  2011. Another interesting file is the Certificate.js which shows the following code.

Lateral Analysis: Certificate.js

Quite an original technique to hide a Javascript File ! As you might see private and public keys are quoted by resulting a valid .js file which would be correctly interpreted by a js engine. Following this way, before getting into our real attack path represented by the set.tmp file, from Stage: 1 (ref. Image Stage: 1), the decision landed on performing some slow and intensive manual transformations in order to evaluate the result of GET “http://88.99.112.78/js/P8uph16W” (content in the following image). Certificate.js gets that data and evaluates it through the function: eval(“”+Cs+””)

Lateral Analysis: P8uph16W evaluated javascript

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:

GET /htue503dt/images/uAsMyeumP3uQ/LlAgNzHCWo8/XespJetlxPFFIY/VWK7lnAXnqTCYVX_2BL6O/vcjvx6b8nqcXQKN3/J6ga_2FN2zw6Dv6/r5EUJoPCeuwDIczvFL/kxAqCE1du/yzpHeaF3r0pY4KFUCyu0/jDoN_2BArkLgWaG/fFDxP.gif HTTP/1.1

POST /htue503dt/images/YtDKOb7fgj_2B10L/MN3zDY9V3IPW9vr/JSboSiHV4TAM_2BoCU/LocIRD_2B/MEDnB2QG_2Bf2dbtio8H/_2BLdLdN21RuRQj3xt2/SDWwjjE2JeHnPcsubnBWMG/NJUCRhlTnTa9c/5Dzpqg92/AypuGS6etix2MQvl1C8/V.bmp HTTP/1.1

Conclusions:

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 😀 ! 

Index Of Compromise:
Following some of the most interesting Index Of Compromise.

http://88.99.112.78/
http://31.148.99.254/
http://mezzelune.com/arch/stat.exe
http://online.allscapelawnservices.com/arch/stat.exe
http://quotidianoannunci.it/arch/stat.exe
9b8251c21cf500dcb757f68b8dc4164ebbcbf6431282f0b0e114c415f8d84ad0
6456cd84f81b613e35b75ff47f4ccd4d83ec8634b5dcdf77f915fe7380106b28
5ab04878b630d1e0598fb6f74570f653a6bd0753dad9ef55ecf467bee7e618e1

 4605dc8f1bc38075eacf526a1126636aa570fccbe78dca69781cc25edd1a1043

3fc092b52e6220713d2cb098c6d11a56575c241f
610df2672d7cae29e48118a27c4cb2a531e6399b
c304502aa7217399acc0162f41da00dc4add4105
magicians-blog.info
ozarkpatternconcrete.info
androidtutorials.info
executenet.pw
base.vuquoctrung.info/htue503dt
base.magicians-blog.info/htue503dt
base.ozarkpatternconcrete.info/htue503dt
base.androidtutorials.info/htue503dt
executenet.pw/htue503dt

Published by marcoramilli

Ethical Hacking, Advanced Targeted Attack Expert and Malware Evasion Expert