HackDig : Dig high-quality web security articles for hacker

False Flag Attack on Multi Stage Delivery of Malware to Italian Organisations

2017-06-16 09:20

Researchers at the security firm Yoroi have discovered a False Flag Attack on Multi-Stage Delivery of Malware to Italian Organisations.

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 a 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 far away from my original attack path.

So, let’s assume the downloaded file are the same (really they are not) and let’s 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 hardly obfuscated (maybe from obf.txt ? … of course !). The following image shows the Third Stage structure.

 
Stage 3: Structure
The structure highlights three main modules as follows:
  1. Anti Module. The aim of such a module is to implement various evasion techniques in order to weaponize the sample and block execution on VMs.
  2. Service. The aim of such a module is to launch a background service.
  3. RunPe. The aim of such a module is to launch an additional encrypted PE file placed in the resource folder.
Let’s try to investigate a little bit better what these modules do. The Anti Module tries to figure out if the analyzed 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 <p><hr/></p>
     <p>Source: <a  href=lmth.ylati-kcatta-galf-eslaf/erawlam/40106/sserpdrow/oc.sriaffaytiruces

Read:186 | Comments:0 | Tags:Breaking News Cyber Crime Hacking Malware

“False Flag Attack on Multi Stage Delivery of Malware to Italian Organisations”0 Comments

Submit A Comment

Name:

Email:

Blog :

Verification Code: