We have recently received two samples of Locky maldoc (malicious document) ransomware from a healthcare institution. Ransomware is a devastating piece of malware that encrypts important files on an infected computer and demands ransom to decrypt the files. We will examine two samples.
Both samples arrived via email and were not detected by spam filters or antivirus when saved to the computer.
While analyzing the Word documents, it was discovered that the file format was actually a .mht Web Archive or a single file web page, and not an OLE Word document. If you take a .mht file and rename it as .doc Word will treat it the same.
The simplest way to convert it to an OLE document is to open it in Word and save it as a Word document.
Open the file in Word
Save as .doc
Now we can analyze the document again. For this we used OLE Dump, a great tool for analyzing and extracting data from OLE files.
Streams with an uppercase ‘M’ are the more interesting VBA Macros.
I started by looking at stream 11: ./oledump.py –s 11 –v
As expected the script is obfuscated, but while reviewing the script one line stood out.
This line means there is more data in UserForm1.textbox 1and 2, but the data in textbox1 is base64 encoded. This time I look for any objects that contain UserForm1.
I reviewed stream 10 first since it was the largest and turns out it does contain the data we are looking for.
The value of textbox1 is base64 encoded and textbox2 is in plain text and does contain the URL for the payload. At this point I could just stop and go grab the payload and analyze it, but me being me, I want to see what the reset of the scripts are doing.
I tried to decode the base64 value I pulled with oledump but there was an issue with the value that was returned. So I went ahead and removed the VBA password from the document with a hex editor and pulled the value from Word. Below are the steps I followed.
Search for DPB in a hex editor and change it to DPX then save the document.
Open the document in Word, go to the Developer tab and press the Visual Basic button. Hit ‘Yes’ on the dialog box pertaining to the invalid key ‘DPX’ and hit ok on the next box.
Now the Visual Basic designer will open, under the project tree right click the project and open the properties. On the Protection tab un-check ‘Lock project for viewing’ and press Ok. Hit the save button in the Visual Basic designer and close, then save and close the document.
Now reopen the document select the Developer tab and press Macros. In the Macros list select the macro you wish to view and press Edit.
Now you have full access to the scripts and forms.
From here I was able to pull the base64 encoded value from textbox1 and did notice there was a difference. You can copy this value to linux and use base64 –decode but in this instance I just used www.base64decode.org.
After some deofuscation of the script I ended up with the following:
After some additional deobfuscation on the VBA macro I combined the 3 parts to reveal full script and the actions performed.
1. VBA macro creates file %temp%\arra.bat
2. Writes decodes and writes value of textbox1 and textbox2 to arra.bat
3. Executes %temp%\arra.bat
3.1. Arra.bat in turn creates %tmp%\dasdee.vbs
3.2. Echo’s the script contents to the dasdee.vbs script
3.3. Executes dasdee.vbs using cscript
3.3.1. dasdee.vbs performs a GET request to the http address passed in parameter %0% and saves the response to the location in parameter %1%
3.4. The bat file then executes the file save by the vbs script, deletes the vbs scripts and deletes itself.
Between the two samples the above steps did not change, the only differences were the number of UserForm1 textboxes and the URL. The Word document VBA macro obfuscation was also different but the base64 encoded script was the same in both samples.
Now that we have the URL for the PE file we can go and download it. One thing to note that sometimes to download the file you will need to match the Agent string in the script. For these samples this wasn’t required.
I started testing by changing the network for the VM so it was contained on its own network and blocked all outbound requests except for DNS on the perimeter firewall.
Sample1 was an older sample and I only saw DNS queries for what appeared to be DGA domains Command and Control servers(C&C).
I went ahead and removed the access restriction on the firewall and watched the POST requests. Only one of the DGA C&C hosts was still accessible and the one that did accepted the POST request closed the connection.
Since no response was received from the C&C Server, Locky just continued to the send POST requests and never proceeded beyond that point and did not encrypt any files.
Sample2, a newer sample, immediately tried to access a list of hardcoded IP addresses and sent a POST request. Once communication was established the malware only communicated with that host.
Reviewing the HTTP traffic from Sample1 and 2 I noticed the contents of the first POST request from the victim were encrypted but also that between the two samples the values were the same. This means that the network traffic is encrypted with a static value or at least the POST request is.
Once communication is established with the C&C server an RSA encryption key is transferred to the victim and stored in the ‘pubkey’ value of registry key ‘HKCU\Software\Locky’.
Now that Locky has the encryption key the below steps occur.
1. Delete Volume Shadow copies
2. Add startup registry keys
3. Output intructions.txt/.bmp
4. Encrypt Files
Some additional notes regarding Locky.
The file extension for encrypted files is always “.locky”
When files are encrypted the file is renamed as such, the first 16 characters of the filename is the value stored in the ‘id’ value of registry key ‘HKCU\Software\Locky’ and the second set of 16 characters are randomly generated.
Locky creates the registry key ‘HKCU\Software\Locky’ and sets the following values:
If Locky is executed from outside of %TEMP%, it copies itself to %TEMP% as svchost.exe and removes the original file.
I also fired up the debugger to see if I could recover the value used to encrypt the HTTP traffic. Unfortunately I wasn’t able to locate this value but I did locate some other interesting data.
Static IP address list to communicate to the C&C servers:
22.214.171.124 - PS Internet Company LLC Network, Kazakhstan
126.96.36.199 - Petersburg Internet Network ltd., Russian Federation
188.8.131.52 - Webhost LLC Dmitrii Podelko, Russian Federation
184.108.40.206 - UASERVERS NETWORK, Ukraine
HTTP Request Properties:
This is a list of OS ‘s that are targeted by the malware:
VSS Admin command:
Locky is a relatively new player to the ransomware scene but it appears to be on par with functionality of current ransomware families. Also with the amount of data that appears to be reported to the C&C servers, if filenames are reported in either the ‘path’ or ‘encrypted’ HTTP properties and those filenames contain PHI, an infection could be considered a breach.
If any new details are discovered we will updated this post.
Stevens, Didier, Oledump.py
January, 2015, http://blog.didierstevens.com/programs/oledump-py/