In this article, we will perform a simple analysis of the WannaCry ransomware given to CS Ranger candidates as homework in Hell Week. The purpose of this article is not to be a detailed analysis of WannaCry, but to inform trainees and of course you about some of the methods and strategies used during malware analysis.
Basic Static Analysis
What I call basic static analysis is the analysis phase that takes place without running the application or code inspection. In this step, information such as signatures, strings, imports, header and section information on the file is collected and ideas are formed about what the malware is doing. The information obtained with basic static and dynamic analysis can greatly facilitate our work in advanced stages of analysis (advanced static and advanced dynamic analysis) by showing us a direction.
With the VirusTotal scan, information about what kind of malware is and which malicious family variant is it can be obtained.
The results such as Trojan, Generic, Heur, are a general nomenclature resulting from a heuristic scan of AV software, but they do not contain useful information about the malware family, therefore it should be ignored.
In other results, we see names such as Ransomware and WannaCrypt. These are more specific names than the ones we just mentioned, and they are more reliable results because they are likely to result from a signature match. In light of this information, it is possible to say that the sample we have is a Ransomware (ransomware) malware called WannaCrypt.
These keywords obtained can be researched on the internet to learn about the ransomware operation and may even obtain a detailed analysis report of WannaCrypt. Information obtained from them can be used to guide the further stages of the analysis. However, it should be noted that malware developers also know these methods and they can add fake signatures to the malware to mislead and distract you.
Another way to obtain information about malware is to search the hash values of its sections on the Internet. Harmful variants are caused by changing and reusing the code of an existing malware. Therefore, even if the hash values of the .text section in which the codes are included, sometimes the data used in the program does not change, so sections such as the .rdata, .data, .rsrc have hash values remain the same. These hashes can be researched from the Internet to find harmful variants that use the same section.
Another information that can be obtained from the screenshot above is the Entropy of the sections. The fact that a data has high entropy means that there are no repetitions or very little in that data. Both data encryption and data compression algorithms disrupt repetitions in the data and, consequently, increase the entropy of the data. Therefore, it is possible to say that a section with high entropy contains encrypted or compressed data. In our sample we have the .rsrc section that has a very high entropy value like 8.00, so we can say that this section is compressed or encrypted.
The Resources section contains a ZIP archive with the name “XIA”. It is clear that this is why the .rsrc section has high entropy.
By examining the libraries and functions used by malwares, an idea of what the pest is doing can be formed. Further stages of the analysis can be guided by this information. For example, functions related to a work done by the pest (for the ransomware example, these may be encryption functions) can be traced in its code and all the details of how the pest did it can be revealed.
In this section the imported DLL and the functions in them will be discussed separately.
ADVAPI32.dll: Includes functions related to service/process creation, file permissions, data encryption, etc.
REGISTRY RELATED IMPORTS
The inclusion of functions related to registry modification could be sign of a persistence technique commonly used by malware.
SERVICE MANAGEMENT RELATED IMPORTS
The functions of service creation can be a sign that the pest will try to hide from the user by creating services that will work in the background. It is also another common persistence technique used by malware.
KERNEL32.dll: It is one of the libraries of WinAPI, which is an OS/application interface.
FILESYSTEM RELATED IMPORTS
Using functions related to file/directory operations is also expected from a ransomware and is parallel to our previous findings.
PROCESS RELATED IMPORTS
The above functions are used by multithreaded applications to ensure threads work synchronously. In accordance with this information, it is possible to say that the pest will create new processes.
RESOURCES SECTION RELATED IMPORTS
The presence of these functions means that the pest uses the Resources (.rsrc) section. In the “PE Sections” section of the article, we mentioned that the entropy of this section is very high.
MEMORY/MODULE RELATED IMPORTS
The functions related to module loading and memory management are often used together during Dynamic DLL loading process. Some of these functions are also used by pests during unpacking or process injection.
SYSTEM INFORMATION RELATED IMPORTS
The functions here, as the name suggests, provide information about the system. It has been seen that ransomware uses system information to produce “ClientID” or “PRNG Seed”. That could be the point here.
MSVCRT.dll: One of the C runtime libraries. Apart from these, some of the functions that are of interest are as follows.
CRYPTO RELATED IMPORTS
These functions are PRNG and PRNG Seed functions. During encryption operations, these functions were found to be used to generate keys. We just mentioned that the pest collects system information (computer name, bios history). The inclusion of these functions strengthens the likelihood that the pest used this information as PRNG Seed.
COMMANDLINE RELATED IMPORTS
The above functions indicate that the pest takes arguments through the command line.
The readable strings in the executable file can be examined to get a better idea of the malware. Some of these strings belong to the variables used in the program.
Here are some of the strings that interest us in sample;
ZIP RELATED STRINGS
inflate 1.1.3 Copyright 1995-1998 Mark Adler
– unzip 0.15 Copyright 1998 Gilles Vollant
These strings give us an idea of the compression algorithm used in the pest. They are most likely associated with the Resources section of the pest.
WANACRY! , WanaCrypt0r , WNcry@2ol7
The strings here are unique strings that can be used to create signatures to identify the pest.
COMMAND RELATED STRINGS
cmd.exe /c “%s”
icacls . /grant Everyone:F /T /C /Q
attrib +h .
These strings show us that the pest runs a number of commands through “cmd.exe”. The commands here allow to change the permissions and properties of a file/directory. Given that the pest is of the ransomware type, it is understood that the pest uses these commands to provide full access to all files in the directory in which it is located.
EXECUTABLE FILE RELATED STRINGS
taskdl.exe , taskse.exe , tasksche.exe
The names of some executable files were found among the strings. For what purpose these names will be used will be more clearly understood later.
Crypto Analyzer (KANAL)
Based on our previous findings, we can say that the pest performs compression/encryption operations in many stages. More detailed information about the compression/encryption operations used can be ubtained with the “KANAL” tool. “KANAL”, a plug-in for static analysis tool called PEiD, is a tool that allows us to detect signatures for cryptographic operations on the executable file.
All of the detected algorithms are as follows;
ADLER32 :: 000056B0 :: 004056B0
CRC32 :: 0000D054 :: 0040D054
CryptDecrypt [Name] :: 0000F0D0 :: 0040F0D0
CryptEncrypt [Name] :: 0000F0E0 :: 0040F0E0
CryptGenKey [Name] :: 0000F0C4 :: 0040F0C4
RIJNDAEL [S] [char] :: 000089FC :: 004089FC
RIJNDAEL [S-inv] [char] :: 00008AFC :: 00408AFC
ZIP2 encryption :: 00006830 :: 00406830
ZLIB deflate [long] :: 0000CE6C :: 0040CE6C
It is clear that ADLER32, CRC32, ZIP2 encryption and ZLIB deflate algorithms are used for the archive in the Resources section. We also understand that this archive is encrypted. Based on the remaining algorithm names, we can say that the malicious may have used AES to encrypt the files.
Basic Static Analysis Results
• This malware is a Ransomware called WannaCry.
• It contains a harmful, encrypted ZIP archive and it is most likely unpacked during runtime.
• Malware could be adding itself to Registry to ensure persistence in the system.
• Malware could be creating one or more services during its operation to ensure persistence or evade AntiVirus systems.
• Malware may initiate new processes during operation.
• Malware could be dynamically importing DLL files.
• Malware may collect information about the system in which it works, and with a high probability will use this information as PRNG Seed.
• Malware could be taking arguments through the command line.
• Malware may change file/directory permissions through “cmd.exe” commands.
• Malware could be using AES encryption algorithm to encrypt files
Although the findings obtained by basic static analysis give us an idea of what the pest is doing, there is no certainty. The goal here is to produce as many hypotheses as possible. These hypotheses are essentially clues that will guide us later in the analysis. At the later stages of the analysis, some of these hypotheses will be confirmed, some of them will be falsified. Perhaps even unforeseen findings will appear. Therefore, it is necessary to always be skeptical about the results of basic analysis and bring additional verification.
Advanced Static Analysis
It is possible to learn what a malware does by using basic static and dynamic analysis methods. For Incident Response an in-depth analysis with source code review may be required. At this point, the Xref and Naming features of the IDA Pro tool greatly facilitates the process of source code analysis.
Another way to facilitate code analysis is to examine the places where suspicious functions and strings are used directly in the program. We can direct our research based on the information we have obtained earlier. This way, instead of playing Marco Polo between tens of thousands of lines of code, we’ll be doing more targeted reviews. When it comes to reverse code engineering, there are many rabbit holes which one may follow. The key to success at this phase is finding the ones which are worth following down.
Some of the findings that occur during code analysis are below. If you are not familiar with reverse engineering please try to match portions of code with their descriptions.
The work that this sample does when it starts to work, respectively;
• Learn which directory it’s working in
• Generating an alphanumeric string of 11-18 characters long (Gen_Rand_Str)
• to see if argc is equal to 2
If the number of arguments given when running the program is two;
• Check for an argument of “TaskStart”
• Try to grant read/write permissions to one of the following directories, if available (Where_to_Reside)
• Copy yourself with the name “tasksche.exe”
• Start “tasksche.exe” as system service (launch_tasksche)
• End “taskche.exe” service if Mutex “MsWinZonesCacheCounterMutexA” exists (Close_Srv_If_CounterMutex)
Persistence, Load_Config, Export and unzip XIA
Add yourself to the registry for persistence
• Export the encrypted archive “XIA” in Resources (Export_XIA)
Note: We see that the archive password is WNcry@2ol7.
• Load the config file “c.wnry”
• Hide all files in current directory (Cmd_exe)
• Give full authorization for all files in current directory (Cmd_exe)
• Get addresses of functions related to file/directory and encryption
Note: Dynamic Module Loading is a method that is often used by malware to make the analysis harder.
Three BitCoin Wallet addresses are found in this function.
It appears that the pest is doing read/write operations from the file “c.wnry”, which is extracted from the archive within the malware. This file is considered to be a configuration file of the malware.
When we extract the “c.wnry” file from the archive, it contains five .onion addresses.
These are most likely addresses of ransomware’s C&C servers. Another file in XIA is an archive named “s.wnry” which contains a TOR client.
In accordance with this information, it is possible to say that the pest communicates with C&C servers via TOR.
Load t.wnry Encrypted DLL
It is seen that the pest reads the encrypted file named “t.wnry”, which is extracted from the archive, and then decrypts it into a Class.
As a verification phase at the beginning of the installation, the malware is looking for string “WANACRY!” at the beginning of the file. As a countermeasure, this string can be used as a signature.
Run TaskStart Method
After the class is loaded, it appears that the pest searched for a method called “TaskStart” in this class and then called it. As it can be understood from here, the file “t.wnry” is an encrypted DLL.
When the encrypted archive in the.rsrc section of the malware is opened, a number of files are found in it.
• Msg directory: folder with ransom messages to be displayed to the user.
• b.wnry: The image that will be put on the user’s background.
• c.wnry: Configuration file with C&C addresses of the pest.
• r.wnry: FAQ file for users.
• s.wnry: The archive with TOR client in it.
• t.wnry: Encrypted DLL library File.
Apart from these, there are three executable files named taskdl.exe, taskse.exe, u.wnry.
Further Steps to Extract the DLL
During dynamic analysis, we can put a breakpoint to the point the Class is decrypted and loaded, dump the memory area in which Class is located and obtain the original version of this file.
Findings of Advanced Static Analysis
• Copy yourself and create service with the name “tasksche.exe”.
• Modify Registry to maintain persistence.
• Extract the encrypted archive from Resources.
• Hide extracted files and grant full permissions to the directory.
• Read and update the configuration file.
o Get the .onion addresses to communicate with C&C servers.
o Write to the file the Bitcoin wallet addresses where the payments will be received.
• Read, decode and load an encrypted DLL file into Class.
• Call the “TaskStart” method from this Class.
At the end of this article, we learn that the file we have is a Dropper for Ransomware called WannaCry. Encrypted DLL and other executable files in the file can also be analysed with the methods we use here, and this research can be further expanded to gain more knowledge about the malware.
If we look at the analysis process, first of all we infer hypotheses by examining the static information on the executable file such as strings, sections, signatures, imported dll and functions. We then used this information to guide our research during the code review. While reviewing the code, we confirmed some of the hypotheses we made about the malware in the previous stage. In addition, we have obtained critical information about the internal structure of the malware and the methods it uses and unique strings that can be used as signature and IoC to protect against this pest, such as c&c addresses.