Understanding the Latest Version of Locky Ransomware

It is one of the most prevalent spam malware 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.

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

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.

 

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 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.”

 

 

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.

A Look at the JavaScript 59D2E5827F0EFFE7569B2DAE633AFD1F

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

The Javascript downloads via GET command from 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.

 

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.

 

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 volume GUID path associated with the machine’s Windows folder.

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.

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.

 

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.

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)

id=8B74B4AA40D51F4A&act=getkey&affid=1&lang=en&corp=0&serv=0&os=Windows+XP&sp=3&x64=0

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.

 

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

Saving The Public Key in the User’s Machine

The executable will encrypt the public RSA key and 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.”

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.

 

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:

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.

The executable then uses the APIs GetLogicalDrives and GetDriveTypeW to gather the possible drives to encrypt. In this case, it obtained 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.

 

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.

• @_HELP_instructions.bmp, _HELP_instructions.txt, _Locky_recover_instructions.bmp, _Locky_recover_instructions.txt, tmp, winnt, Application Data, AppData, Program Files (x86), Program Files, temp, thumbs.db, $Recycle.Bin, System Volume Information, Boot, Windows

Black List Check

The Locky executable also checks the extension of the file to be encrypted. If the file has one of the “ff.” extensions, it will be encrypted.

• .001, .002, .003, .004, .005, .006, .007, .008, .009, .010, .011, .123, .3dm, .3ds, .3g2, .3gp, .602, .7z, .ARC, .CSV, .DOC, .DOT, .MYD, .MYI, .NEF, .PAQ, .PPT, .RTF, .SQLITE3, .SQLITEDB, .XLS, .aes, .asc, .asf, .asm, .asp, .avi, .bak, .bat, .bmp, .brd, .cgm, .class, .cmd, .cpp, .crt, .cs, .csr, .db, .dbf, .dch, .dif, .dip, .djv, .djvu, .docb, .docm, .docx, .dotm, .dotx, .fla, .flv, .frm, .gif, .gpg, .gz, .hwp, .ibd, .jar, .java, .jpeg, .jpg, .js, .key, .lay, .lay6, .ldf, .m3u, .m4u, .max, .mdb, .mdf, .mid, .mkv, .mml, .mov, .mp3, .mp4, .mpeg, .mpg, .ms11, .ms11 (Security copy), .n64, .odb, .odg, .odp, .ods, .odt, .onetoc2, .otg, .otp, .ots, .ott, .p12, .pas, .pdf, .pem, .php, .pl, .png, .pot, .potm, .potx, .ppam, .pps, .ppsm, .ppsx, .pptm, .pptx, .psd, .pst, .qcow2, .rar, .raw, .rb, .sch, .sh, .sldm, .sldx, .slk, .sql, .stc, .std, .sti, .stw, .svg, .swf, .sxc, .sxd, .sxi, .sxm, .sxw, .tar, .tar.bz2, .tbk, .tgz, .tif, .tiff, .txt, .uop, .uot, .vb, .vbs, .vdi, .vmdk, .vmx, .vob, .wav, .wb2, .wk1, .wks, .wma, .wmv, .xlc, .xlm, .xlsb, .xlsm, .xlsx, .xlt, .xltm, .xltx, .xlw, .xml, .zip, wallet.dat (filename specific)

API and Function-Level Overview of the File Encryption Process:

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.”

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.

 

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 0x230 bytes 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.

 

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.

 

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.

Network capture of Communication to CnC via post command to the CnC Server IP:

An outgoing connection is being initiated by Locky.

 

Process capture of Vssadmin.exe execution, deleting all backups:

Setting an encrypted registry value “4Y0743Ngl” at HKCU\software:

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:

 

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.

The post Understanding the Latest Version of Locky Ransomware appeared first on ThreatTrack Security Labs Blog.