Road to RE, Ep1. Phobos Ransomware Analysis
Introduction
Hello and welcome to Episode 1 of my ‘Road to RE’ (Reverse Engineer) series. In this series I will be posting malware analysis/reverse engineering blogs during my pursuit of learning MA/RE. The hope is that these blogs will start out more basic and as I learn more and develop my skills they will begin to dive deeper into the samples analyzed! I hope you enjoy the first episode!
In today’s world, it is essential to comprehend ransomware to ensure security. By understanding the steps taken by ransomware to infiltrate a system and how encryption works, defenders can effectively combat ransomware of any complexity. The Phobos Ransomware variant, which has been operational since 2018, can generate ransom notes and perform standard data encryption. This report aims to analyze the default executable of Phobos ransomware to gain a more comprehensive understanding of its operation.
Overview
To facilitate comprehension and recognition in screenshots, the executable analyzed in this report was named “Ransomware.exe” and will be referred to as “Ransomware” throughout the document. Please note that some timestamps may be inaccurate due to several analysis passes on this particular executable, and there may be some discrepancies in matching PID numbers, although efforts were made to minimize them.
Static Analysis
Static Analysis is typically the first step in analyzing any malware. This process involves examining the static characteristics of the executable(s) to extract relevant information. During the analysis of the Ransomware executable, three different types of hashes were identified: MD5, SHA1, and SHA256
Hashes provide a straightforward method for determining whether a file is recognized malware or a new variant. Upon checking the SHA256 hash on VirusTotal, it is validated that the file is identified as ‘ransomware.phobos’, offering concrete proof of this malicious program’s capabilities.
Malware can reveal useful information through its static properties such as imported and exported API calls. PeStudio is a software tool that can extract this information, and in this report, it was utilized. Notably, several “blacklisted “ API calls were detected, which can be taken into account for future analysis. When PeStudio identifies a blacklisted API call this simply means that the API call can be used for malicious purposes, however most of these API calls can (and are primarily) used legitimately.
Finally, it’s worth noting that many malware samples contain hard-coded strings in both ASCII and Unicode forms. Although there aren’t many strings found in this particular executable, one UNC path was discovered during analysis.
With this fundamental information, it can be concluded that the analyzed file is a widely known Phobos ransomware, containing various API calls that require further investigation, and one Unicode string that may prove useful for advanced analysis techniques.
Dynamic Analysis
Once the basic properties of a malware executable are analyzed, it’s common to run the file on a system to observe its functionality and behavior. Several tools can be utilized to track the activity of the malware during runtime. In this report, Process Monitor was utilized. Upon executing on the test system, Phobos ransomware successfully encrypted all files and added an uncommon file extension, which resulted in the inability to interact with files.
After the encryption process, a ransom note was created, directing the victim to contact an email address hosted on onionmail.org. This note, named ‘info.hta’, was stored in the C:\ directory.
When examining the Process Monitor output of the executable, the activity of the ransomware can be observed as it creates processes, modifies registry entries, and generates files.
It is interesting to note that no network activity was observed, despite the presence of several networking APIs that were identified during the static analysis phase.
The malware executable was observed to create a child process with the same name.
Furthermore, these processes generated another Ransomware executable within the AppData directory of the user.
Static Code-Level Analysis
Analyzing the code structure and API calls within an executable can be done by diving deeper into executables through decompiling and debugging. Decompiling an executable allows malware analysts to investigate the code structure and API calls without having it actively running on the system. This report uses the open-source Ghidra tool for this purpose. Upon examining the API calls within the Ransomware file, additional API calls are identified. Of particular interest for this executable are the API calls related to file operations.
Despite the absence of networking activity during the dynamic analysis of the executable, multiple networking APIs are still visible in the decompiled code.
Upon analyzing the networking APIs, it is possible to observe several parameters associated with the APIs. The WinHttpOpen API, which creates a network connection, specifies the lpAccessName parameter as a label identified by Ghidra with a value of ‘000000000’. In addition, the WinHttpOpenRequest API sets one of its parameters to POST.
Despite the absence of network activity during the execution of the malware, the presence of these networking APIs suggests that there may have been networking checks in place that disabled this functionality when running in the controlled malware lab environment. Further analysis is required.
Dynamic Code-Level Analysis
For performing dynamic code-level analysis of malware, it is important to investigate the code-level behavior of the malware during runtime. For this purpose, x32dbg tool was used in this report, as the Ransomware file was identified as being of 32-bit architecture. Upon loading the Ransomware file into x32dbg, the first step was to investigate any API calls that were found. To proceed with this investigation, breakpoints were set on any API calls related to file operations, networking operations, process operations, or registry operations.
Moreover, x32dbg provides the ability to search for ASCII and/or Unicode strings in the running process, similar to static analysis tools. By examining the strings detected by x32dbg, various registry keys and executable names are visible, which may provide additional insights into the functionality of the executable.
Upon running the executable, the initial breakpoint encountered was the invocation of the RegOpenKeyExW API call. Examining the register values at this point reveals that the accessed registry key was ‘\CurrentVersion\Run’, which corresponds to the registry activity observed by Process Monitor.
As the program continued to run, it interacted with additional startup/autorun locations by modifying other registry keys.
The Ransomware file is observed placing the path to the executable as a value within these registry keys, indicating the installation of a persistence mechanism where the Ransomware file executes upon startup.
After the registry activities, the dynamic analysis stage revealed that the Ransomware file created a new Ransomware.exe file within the user’s AppData directory.
Using the CreateProcessW API, the malware generates a new process to execute the ‘cmd.exe’ program.
Examining the subsequent processes after the creation of the new process mentioned earlier, an API call can be observed with a register value of “netsh advfirewall set currentprofile state off\nnetsh firewall set opmode mode=disable\nexit\n”. This indicates that the malware is modifying the networking configuration on the compromised device.
After the networking settings manipulation, the malware creates another process using the ‘cmd.exe’ executable.
After this process, the malware proceeds to make another system modification, which involves the deletion of any Volume Shadow Copies found on the local system.
The Ransomware file appears to have shifted its focus towards its primary objective of encrypting the system at this stage. It initiated this process by calling the FindFirstFileW API, which searched multiple root directories, including C:\ and D:\.
Subsequently, the Ransomware proceeded to encrypt files by adding a ransom ID and email address extension to the end of each file after encryption. Further analysis is required to fully understand the encryption method.
The encryption process proceeded to encrypt critical areas of the system, including Program Files, user profiles, and any discovered partitions. After encrypting each file, the Ransomware appended its ransom ID and email address to the end of the filename.
After the encryption process was finished, the info.hta file was generated and presented. Subsequently, the executable entered into a state of low-activity or sleep mode, where many threads were suspended and the x32dbg CPU information seems to be only that of Windows calls. Further analysis is to be made to fully understand this activity. Nonetheless, no further actions were performed by the malware itself.
Conclusion
Having a comprehensive understanding of ransomware is crucial to fully comprehend its functionalities and the damage it can cause. Examining other ransomware variants is necessary, but even a fundamental comprehension of ransomware, like the Phobos executable described in this report, can enhance the readiness of organizations and defenders in coping with ransomware threats.
