MBSDトップページ > MBSD Blog > Understanding internal structure of the SNAKE(EKANS) ransomware

Understanding internal structure of the SNAKE(EKANS) ransomware

Cyber Intelligence Group
Takashi Yoshikawa, Kei Sugawara

The news has been running around the world that Honda has been suffered by cyber attacks in the past few days.
In this article, we analyze the sample (*) of SNAKE ransomware that was uploaded to VirusTotal, and would like to share the information we found through our analysis. Although some information has already been published outside Japan, it seems that there are little information available in Japanese, so I would appreciate it if you could use it as a reference.

※ Hash value : d4da69e424241c291c173c8b3756639c654432706e7def5025a649730868c4a1

We do not know if this sample is related to the cyber attack against Honda. Please note that this article only describes analysis results of the sample with the above hash value.

■ Specimen

First of all, the sample in question was uploaded from Japan to VirusTotal around June 8th as follows.

Fig. 1 - Uploaded to VirusTotal from Japan

SNAKE ransomware, also known as EKANS(SNAKE reverse reading), is a new ransomware that emerged in December 2019.

SNAKE body was developed in the GO-language, a relatively new open-source development language developed by google about a decade ago, and compiled into the EXE-format. One of the backgrounds created in the GO language is that it can be developed on multiple platforms, which is considered to be an advantage of the developer.

The following illustration shows the strings inside malware, that indicates that it was developed in the GO language with an account name of Admin3 has been developed in Windows environment.

Fig. 2 - SNAKE was developed in GO language on Windows platform

(note) PE files developed in GO have fixed compilation date and time value of 1970/1/1 because Time Date Stamp is set to 0x0.

Fig. 3 - A PE-file developed in GO language includes fixed Time Date Stamp

When SNAKE is started, it registers a mutex called "EKANS" to the system.
This prevents the activation of other EKANS while SNAKE is already in operation, preventing unintentional multiple infections of SNAKE in the same PC.

Fig. 4 - Registering the mutex "EKANS" to prevent multiple infections

Next, the following specific-domain name resolution is checked as a unique behavior of this particular SNAKE:

In addition, check if name resolution for the above domain is equal to the following IP address, if not, terminate the operation, if it is equal, continue the operation.

In other words, this specimen is a ransomware specially built for a unique set of name resolution and IP address.
As we've said in our previous blogs, targeted ransomware in recent years tends to create behaviors tailored to the target, so even seemingly the same type of ransomware often vary in motion.

Incidentally, at the time of the survey, 170[.]108[.]71[.]15 can be reverse-looked up as the following host name:

Fig. 5 - Checking specific IP address

Following discusses more detail around name resolution.

Following shows the behavior of SNAKE in case name resolution failed to match to the name of the relevant domain.
(SNAKE behavior is shown in time order from top to bottom in the following picture)

The part with red frame is a process resolving the name of the domain. In case the domain cannot be resolved, errors are returned to GetAddrInfoW, and SNAKE stops working and terminates. In another words, it does not work on PCs that cannot resolve MDS[.]HONDA[.]COM.

Fig. 6 - Immediately finished when name resolution fails

On the other hand, If you run SNAKE in a spoofed environment so that 170[.]108[.]71[.]15 is responded against MDS[.]HONDA[.]COM name resolution, a successful (=ERROR_SUCCESS) reply is returned and SNAKE continues to operate afterwards, as follows:
In other words, this ransomware is made to work only in the particular environment in which 170[.]108[.]71[.]15 is responded against MDS[.]HONDA[.]COM name resolution.

Fig. 7 - Operation continues when name resolution is possible for a specific IP address

These approaches make it impossible to grasp the behavior of this specimen in an automated analysis environment or an immediate inspection environment where the name resolution fails, and thus it could be one of the effective analysis/survey jamming.

■ Activities in environments where name resolution is available

Once SNAKE realizes it is a good operating environment (that is, an environment where name resolution stated above is succeeded), now SNAKE changes Windows firewall settings.
Specifically, following command is passed to netsh.exe (network tool, comes with Windows):

Netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound

This will block all incoming and outgoing connections for all profiles that do not match the ingress and egress rules using Windows firewall function.

Fig. 8 - Modifying Windows firewall settings

Then enable the firewall configuration by passing the following command to netsh.exe:

Netsh advfirewall set allprofiles state on

Fig. 9 - Enabling Windows firewall settings

As a result, all communications that do not match the firewall's existing rules are blocked, making many applications unable to communicate. This mechanism, which uses legitimate Windows firewalls to block network communication during encryption, is a unique phenomenon of this ransomware.

Then, attempt to stop multiple services, such as system or security system.

Fig. 10 - Attempts to stop various services

In addition, multiple legitimate processes are forcibly terminated, which may interfere with encryption and recovery activities.

Fig. 11 - Forcibly terminates various legitimate processes

■ Encryption process

After the environment settings are ready, encryption of the files that is the main process of the ransomware begins.
File encryption takes all drives available in the system and encrypts them in order from the beginning of the drive.
The following image shows how the encryption process begins, and it is searching to encrypt the files in Recycle.Bin (Trash folder) found at the beginning of the C drive. After that, the accessible files contained in each folder of the PC are encrypted one after the other.

Fig. 12 - Flow of file encryption (portion)

The following file extensions (portion) for encryption are pre-determined.

Fig. 13 - Extensions of the file to be encrypted (part)

SNAKE does not handle multiple-process encryption, such as MegaCortex and LockerGoga, but uses a single process to encrypt files.

Fig. 14 - SNAKE encrypting files

During the encryption process, Windows system folders (such as system-based files and Windows folders) are excluded from encryption, and Windows remains operational even when infected with SNAKE. However, as described above, various services and processes are stopped, and many programs including EXE files are also encrypted, so that the system of the terminal that has been infected to this specimen will be totally unstable.

Fig. 15 - Files that SNAKE excludes from encryption (portion)

Common ransomware often changes or adds encrypted file extensions to a particular string (for example, .locked), but all files encrypted by SNAKE are appended with a random string at the end of the original extension.

Fig. 16 - Comparing before and after SNAKE encryption

A footer is added to the end of SNAKE encrypted file, including the original file name and the AES key encrypted with the RSA public key, and a "EKANS" marker is added to the last 5 bytes to indicate that the file was encrypted with SNAKE.

Fig. 17 - SNAKE added data to the end of an encrypted file

Fig. 18 - Comparing before and after SNAKE. "EKANS" marker added at the end of the encrypted file

Encrypted file is shown in below, and you can determine if it is a SNAKE encrypted file by looking at the last 5 bytes of the file.

Fig. 19 - Structure of end of file, encrypted by SNAKE

The RSA public key included in the ransomware is shown below.


The file operation during encryption is implemented in the following flow. Even if it is developed in GO language, from Windows API point of view, it is the same file manipulation flow found in the normal ransomware, that is eventually utilizing WriteFile and ReadFile.

Fig. 20 - Details of file operations when encrypting a single file

Note that SNAKE does not take the recent encryption trend found in the other ransomware (encrypt a file, then change its file extension, and repeat again and again on other files). SNAKE first encrypts all files (without changing file extensions). Once all encryptions are done, it changes all file extensions at a time. For the hacker, there are benefits in this method. Since the file extension is not changed while the ransomware is being encrypted, it is difficult for the user to notice that the file is encrypted halfway, because the behavior is similar to the normal renaming process. As a result, it is possible to escape without being detected by the behavior detection (encrypt a file, then change its file extension, and repeat again and again on other files) .

Fig. 21 - Renaming all files at once after they have been encrypted

When all encryption are completed, SNAKE disables all firewalls with the following command:

Netsh advfirewall set allprofiles state off

Fig. 22 - Disabling the firewall after the encryption process

In other words, SNAKE performs a series of tasks, such as blocking network communications from being sent to and from Windows firewall prior to encrypting files, preventing recovery activities and monitoring across the network during file encryption, and after file encryption is complete, breaking those blocks.

■ Special behavior in domain controllers

A unique feature of this specimen is that it specially works when the work environment is a domain controller.

Typical ransomware basically creates threatening letter after encryption. However, this SNAKE does not create any threatening letter on infected user PC or server, although it does encrypt files.

However, if it determines that the infected environment is a domain controller, it does not encrypt any files. Instead, it creates threatening letters on Windows desktop of Public User and under the root directory of C drive (C:¥).

Fig. 23 - Create a threatening letter only on domain controller

■ How to detect domain controllers

In this section, I will explain more in detail about the mechanism of identifying domain controllers.

First, SNAKE uses WMI queries to refer the domain role value.

Fig. 24 - Checking the domain role value with WMI Query

The domain role value is defined by the following number, and the domain role value for the domain controller is "4" or "5".

Fig. 25 – Definition of the domain role value

SNAKE checks whether the domain role value is less than or equal to 3, and encrypts the file if it is less than or equal to 3, but does not create threatening letter. On the other hand, if it is not less than 3, it does not encrypt the file and creates threatening letters.
The following example compares the behavior of SNAKE in a non-domain controller server (StandaloneServer) and domain controller (Primary domain controller) environment.

Fig. 26 – How to identify domain role

The following is the process by which SNAKE branches its behavior depending on the domain role value.

Fig. 27 - Branch by domain role value

If SNAKE identifies it is a domain controller, then it obtains the path to Windows desktop of Public User.

Fig. 28 - Get Public desktop path

Then, layouts the threatening letter into memory as follows, and creates threatening letters on Windows desktop of Public User and under the root directory of C drive (C:¥).

Fig. 29 – Threatening letter layout in SNAKE memory

Other behaviors, such as horizontal expansion and file theft, have not been confirmed at the present time.

Since Windows firewall operation by netsh requires administrator’s privileges/system privileges, and there is no behavior requiring privilege promotion when SNAKE is executed with user privileges, this specimen may have been developed under the assumption that it is executed with administrator’s privileges/system privileges from the beginning.

Also, because of nature of a ransomware, one of the most important goal is to show the target a threatening letter with the contact information, but this specimen does not create a threatening letter if it is a user terminal or general server, so the ransomware's purpose (getting a ransom money) cannot be achieved without doing so (unless it is a wiper with destructive purpose).
Considering this, the behavior of creating threatening letter only on domain controllers and presenting threatening letter to system administrators suggests that they have been developed under the assumption that they can intrude into domain controllers.

In view of this situation, one of the possibilities for the infection route of this specimen to general user terminals is the distribution of this specimen to each terminal via the domain controller with the supervisor authority/system authority, rather than by a user's double click.

The results of the analysis described above show that the following symptom occurs on the terminal that has been infected to this specimen.

Fig. 30 - Symptoms of the infected PC by this SNAKE

■ Summary

As mentioned at the beginning, we do not have any information other than this specimen, so there is no evidence that this specimen was actually used in Honda's cyber attack. The fact is that, the specimen analyzed this time has been developed so that it works only on terminals under the environment that can resolve (MDS[.]HONDA[.]COM) to specific IP address (170[.]108[.]71[.]15).

As mentioned in previous blog posts, targeted ransomware in recent years tends to be sent after tuning the behavior according to the attack target organization. As a general intrusion route for targeted ransomware, intrusion routes aimed at RDP, VNC, etc. may be targeted. Therefore, I recommend that you re-check RDP and other services have not been exposed to the Internet.