Understanding the Latest Version of Locky Ransomware

It is one of the most prevalent spammalware in the wild today: Locky ransomware. The Locky malware authors started their campaign last year but didn’t become very active until January 2016 – and they haven’t slowed down since.

Locky e-mails usually come in with an attached zip archive and once extracted may contain a document or JavaScript. The Locky ransomware we discovered included a JavaScript that will potentially download and run an executable. The executable is the focal point of this analysis and the latest version of the Locky ransomware.

The spam email sent by the malware authors.

Basic Infection Flow and File Hashes:

1582A0B6A04854C39F8392B061C52A7A – The .zip attachment

59D2E5827F0EFFE7569B2DAE633AFD1F – The JavaScript extracted from the .zip

F79C950FA3EFC3BB29A4F15AE05448F2 – The Locky executable downloaded by the Javascript

Basic infection and file hashes

Indications of Compromise:

It is fairly easy to find out if a machine is infected by Locky. The image below shows the desktop background of a compromised Windows XP machine.

Desktop of a Locky-infected computer

The files that have been encrypted by the ransomware are named with the extension “.locky” and their names start with the personal ID for the infected user – in this case “8B74B4AA40D51F4A,” an MD5 hash. There is also a text file named “_HELP_instructions.txt” that contains the same message displayed in the desktop background.

Locky files

Locky creates an encrypted user-specific registry key at HKCU\Software. The details about the registry values will be discussed later on in this post. The key created was “8W21gQe9WZ3tc.”

Encrypted user-specific key

Payment Instructions

The user is instructed to install TOR browser to access the payment webpage – shown below. The victim must have a bitcoin wallet to send 1.5 bitcoin to the specified bitcoin address.

Payment page for Locky ransomware

A Look at the JavaScript 59D2E5827F0EFFE7569B2DAE633AFD1F

The JavaScript is straightforward. The following lines are visible once opened in a text editor:

JavaScript 1

The Javascript downloads via GET commandfrom http://goldish[dot]dk/o2pds and executes it in %Temp%. The executable will not run properly if not located in a %Temp% folder.

In-Depth Analysis of the Executable F79C950FA3EFC3BB29A4F15AE05448F2

Just like other malware families such as Upatre, Dridex and Crypto, the real Locky executable is wrapped by some encryption routines to avoid signature-based detections. The last step of the unwrapping process is to decompress the executable by using RTLDecompressBuffer API. We’ve seen this same method before from Upatre and Necurs rootkit downloaders.

RTLDecompressBuffer API

The MD5 of the unwrapped Locky executable analyzed is F35D01F835FC637E0D9E66CD7E571C06.

The first step of the executable is to decrypt the following CnC Server IP addresses.

CnC Server IP addresses

The executable retrieves the Windows directory by the API GetWindowsDirectoryA. Then it will be used as a parameter for the API GetVolumeNameForVolumeMountPointA. This Function retrieves the volumeGUID path associated with the machine’s Windows folder.

Windows directory

This GUID will serve as the initial basis of the Locky ransomware for the unique ID of the user.

First, GUID be used by the executable for the API CryptHashData.

API CryptHashData

For The executable to obtain the unique ID – “8B74B4AA40D51F4A” – for the machine, it will use the API CryptGetHashParam to get the unique ID associated with the GUID. It is visible at the first 8 Bytes at the hex dump.

API CryptGetHashParam

This unique ID is correlated with the new registry key of this version of Locky. The ID will be converted by a checksum to string routine implemented by the executable to obtain a string that will be used as its registry key.

For this new version, these particular set of instructions explain why the new registry key is “8W21gQe9WZ3tc” instead of “Locky,” used before in the older versions.

New registry key

CnC Communication

The Locky executable sends a “POST” request to “http://<IP/Domain>/submit.php” by the following commands and parameters:

Commands

Parameters (Remove the <>)

&act=getkey&affid=

id=<>,&lang=<>,&corp=<>,&serv=<>,&os=<>,&sp=<>,&x64=<>

&act=gettext&lang=

id=<>

&act=stats&path=

id=<>,&encrypted=<>,&failed=<>,&length=<>

An example of parameters for Command &act=getkey&affid=: (Not Encrypted Form)

These commands will be sent to the CnC server in encrypted form via the API HttpSendRequestA. The executable also receives an encrypted reply via the API InternetReadFile.

CnC server commands

After sending the getkey command to the CnC, the executable will decrypt the encrypted message and getkey command it received the publicRSA key. The image below shows a part of the decryption routine. The public RSA key is at the ASCII dump.

Decryption routine

Saving The Public Key in the User’s Machine

The executable will encrypt the public RSA keyand its checksum will be converted to a string equivalent – just like how the registry key was created. It will be stored as a binary value in its registry key at HKCU\Software. The value name is “270CwQa9XuPIc7.”

Encrypting public RSA key

A Message to the User

Then it will send the CnC command “&act=gettext&lang=.” This will retrieve the Locky ransomware message equivalent to the desktop background image.

Locky ransomware message

Once again, just like the public RSA key, this message will be encrypted, stored to a binary value in the HKCU\software registry key created by the executable. The message is equivalent to the registry value “7CaY397p5R.”

Gathering the Drives, Network Resources and Files to Encrypt

Network Shares and Resources:

The executable used a routine consisting of APIs WNetOpenEnumW, WNetEnumResourcesW, WNetAddConnection2 and WNetCloseEnum to parse through these three types of resources:

#define RESOURCE_CONNECTED 1

#define RESOURCE_GLOBALNET 2

#define RESOURCE_REMEMBERED 3

The usage of NetResource Parsing Routine for different types of resources:

NetResource Parsing Routine

Upon enabling a shared folder for the machine under analysis, the image shows that the executable will connect to the shared folder so it can encrypt the files in the shared folder later on.

Encrypting files in the shared folder

The executable then uses the APIs GetLogicalDrives and GetDriveTypeW to gather the possible drives to encrypt. In this case, it obtained the “C:\” drive.

Encrypting the C:/ drive

The last step is to spawn the thread that will encrypt the files per folder in the drives and resources that were gathered.

Final step in the Locky ransomware process

Deleting the Shadow Copies to Prevent Data Restoration

The next step for the executable is to delete the shadow copies by running this command:

“vssadmin.exe Delete Shadows /All /Quiet”

Other Ransomwares, including Crypto, has used this same command.

The File Encryption Process – the Thread Spawned

The first step in this phase is to parse the directories and files of the machine. The executable allocates a memory space as a structured reference for the files to be encrypted.

White List Check

While parsing the directories of the machine, it will check the file name of each file against the following set of white list strings. File names that have one of the “ff.” strings will not be encrypted.

The Locky ransomware’s claim that it uses AES and RSA is basically true. It used Crypto APIs during the encryption process, including CryptGenRandom and CryptEncrypt. It also had two functions in this process that used the instructions “aesenc” and “aeskeygenassisst.”

API overview

Dissecting the Last 0x344 Bytes of an Encrypted Locky File

In the image below, the last 0x344 bytes are being written at the end of file. The first four bytes are hard coded by the executable. We believe this is some sort of an identifier for the Locky ransomware authors for the version that encrypted the user’s files.

Hard-coded 0x8956FE93

Writing to the file

The Next 0x10 bytes are obviously the unique ID of the user. The next 0x100 bytes are the output of the CryptEncrypt API. The last 0x230bytes are from the AESENC function mentioned from the encryption flow before.

Finalizing the Infection

The executable will generate the “_HELP_instructions.txt” file for every folder path where it encrypted a file. It will also generate an equivalent Bitmap image for the instructions and store it so it becomes the user’s desktop background.

The executable will then send another action – called “stats” – to the CnC server: id=8B74B4AA40D51F4A&act=stats&path=c%3A&encrypted=1&failed=0&length=5912

Path = the infected Drive “C:\”

Encrypted = True

Failed = false

Length = number of files

The last step is to create the last encrypted registry value. It is equivalent to the previous version “Completed = Yes.” This completes the details about the three encrypted registry values.

Last step of the encryption process

The analyzed executable also had the domain generation algorithm, which has been known to exist for the Locky ransomware since its existence last year. It will be used by the executable if it cannot receive a response from the initially decrypted IP addresses.

How to Mitigate

Using ThreatSecure products, it is possible to block the ransomware executable from downloading. The image below shows ThreatSecure Network detecting the malicious download via the GET procedure.

ThreatSecure in action

Prior to opening an e-mail attachment, the customer can use ThreatTrack’s dynamic malware analysis sandbox product – ThreatAnalyzer – to determine if the file is malicious. ThreatAnalyzer logs its output in a file named “analysis.xml.” By looking at this output, you can tell it has seen the executable’s ransomware behaviors (IoCs).

Stored and Encrypted Files to .locky:

The sandbox detects that the files were encrypted, and the “Help Instructions” text file was also generated.

Prior to file encryption, Locky enumerates the network resources of the machine, which can also be encrypted. ThreatAnalyzer was also able to see this behavior:

Locky enumerating network resources

As shown here, advanced threat defense products like those used here help avoid ransomware infection. The advanced solutions catch the emerging threat before it can do any damage.

What’s more, the sandbox capabilities of ThreatAnalyzer also showed that it can log indications of compromise and potential malicious activities once a user accidentally opens the attachment – one more way users are guarded against increasingly popular ransomware attacks.

ThreatTrack Security Labs is the power behind the malware analysis, detection and remediation technologies developed by ThreatTrack Security. From facilities in the United States and the Philippines, our team of cybersecurity professionals, malware researchers, engineers and software developers work around the clock to discover and combat Advanced Persistent Threats, targeted attacks, Zero-days and other sophisticated malware. The company develops advanced cybersecurity solutions that Expose, Analyze and Eliminate the latest malicious threats, including its ThreatSecure advanced threat detection and remediation platform, ThreatAnalyzer malware behavioral analysis sandbox, ThreatIQ real-time threat intelligence service, and VIPRE business antivirus endpoint protection. Learn more about ThreatTrack Security.