In part 2 of the blog, we continue to track the behaviour of the malware after process hollowing. Process hollowing is followed by:
- Victim identification
- Command Line Check and Process Enumeration
- Persistence Mechanisms
- File encryption
Read part 1 here.
Victim Identification
The final payload deployed after process hollowing tries to reach an API endpoint on the internet, to identify the geographical details of the victim.
To determine the location details the malware uses functions exported by “wininet.dll”:
- InternetOpenW()
- InternetOpenUrlW()
- InternetReadFile()
- InternetCloseHandle()
Step 1: The function InternetOpenW() is used for initialization of internet activity by employing “Microsoft Internet Explorer” as the user agent.
Step 2: The victim is identified by sending a GET request to the following url: https://api.2ip.ua/geo.json via InternetOpenUrlW() and the response from the api endpoint is stored in the memory.
Step 3: The function InternetReadFile() is used to store the server response in the process memory as shown below:
- The response is stored in memory:
- The same response is captured using a web browser by visiting the API shown in the image below, which has different parameters such as IP, country_code, region, latitude and longitude, zip code, and time zone.
- The country code is used to classify the victim from a list of countries stored in the malware to prevent the crypter from running on systems in whitelisted countries/ languages.
- The malware processes the response from the server and selects the “country_code” to check the parameter value against a predefined list of languages/countries.
- As shown in the image above, the whitelisted countries are :
- Russia
- Belarus
- Ukraine
- Azerbaijan
- Armenia
- Tajikistan
- Kazakhstan
- Kyrgyzstan
- Uzbekistan
- Syria
- If the “country_code” parameter matches any of the whitelisted country codes, the malware exits from the process and terminates itself.
Command Line Check and Process Enumeration
The behaviour of the malware depends on command line arguments.
- The GetCommandLineW function retrieves the command line arguments and the CommandLineToArgvW function allocates a contiguous memory for pointers to the argument strings.
- The malware resolves functions defined in psapi.dll that perform process related tasks for enumeration of processes running on the system.
- This behavior is observed in ransomware that deploy the next-stage malware loaders and malicious code for evasion. For which, the following functions are resolved:
- psapi.EnumProcesses
- psapi.EnumProcessModules
- psapi.GetModuleBaseNamew
- The ransomware opens each process running on the system via OpenProcess API and retrieves handles to each running process.
- In this manner the malware can later make connections to running processes. The EnumProcess API is called by each running process to get the process details.
Persistence Mechanism
By default, the initial run of the ransomware does not have any command-line arguments. Hence the control flow, after victim identification, is to gain persistence on the victim system.
Persistence through registry
-
- On a Windows machine following registry keys are frequently targeted by malware to gain persistence on the system:
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
- These registry keys can be made to point to a binary stored in the file system, such that each time the system boots up and a user logs in, the binary will get executed without any user interaction.
- In this case, the ransomware uses the Software\Microsoft\Windows\CurrentVersion\Run key to install the malware, on the victim system, at a specific location.
- As an initial step for persistence, the malware checks the “syshelper” key value in the Windows Registry in Software\Microsoft\Windows\CurrentVersion\Run to see if the malware is already installed.
- This registry enumeration and modification is done via the following set of Win32 APIs:
- RegOpenKeyExW
- RegQueryValueExW
- RegSetValueExW
- RegCloseKey
- The ransomware creates a new directory in C:\\Users\<user_name>\AppData\Local and copies the current malware image(binary) into it. The newly created directory has a name generated from a UUID.
- While analysing the sample, the following directory was created by the malware with a sample contained inside the directory: C:\\Users\<user_name>\AppData\Local\66245023-274c-4e81-a77c-e98336b3a3a7\<sample.exe>
- The malware sets the value for registry key Software\Microsoft\Windows\CurrentVersion\Run to “SysHelper,” which points to C:\\Users\<user_name>\AppData\Local\66245023-274c-4e81-a77c-e98336b3a3a7\<sample.exe> –Autostart.
- Now the ransomware has persistence on the victim system. Each time the system boots up, the <sample>.exe is executed by a command line argument –AutoStart
Execution of ICACLS
- Right after the registry modification, the malware uses the icacls.exe binary, present on Windows, to secure the C:\\Users\<user_name>\AppData\Local\66245023-274c-4e81-a77c-e98336b3a3a7 directory from getting deleted by the user.
- icacls.exe is a permission setting console application from Microsoft, for system administrators to manage files. The malware prepares the command line for the icacls as shown below:
- The icacls binary is executed via CreateProcessW() API with the above mentioned command line arguments.
- Break Down of Command Syntax:
icacls.exe <Target_directory> <Permission> <Security_identifier>:<Inheritance_settings> <Operations>
- Target directory: C:\\Users\<user_name>\AppData\Local\66245023-274c-4e81-a77c-e98336b3a3a7
- Permission: /deny
- Security_Identifier: *s-1-1-0 (world – A group of every user)
- Inheritance_settings: OI is object inherit / CI is container inherit
- Operations: DE is delete/ DC is delete child
Access control entries (ACEs) flagged only with “Object Inheritance” are applicable to files in a folder, but not subfolders within that folder. ACEs flagged only with “Container Inheritance” are applicable to subfolders of the folder but not files
icacls “C:\\Users\<user_name>\AppData\Local\6625023-274c-4e81-a77c-e98336b3a3a7” /deny *s-1-1-0:(OI)(CI)(DE,DC) |
This prevents users from deleting the created folder and its contents.
Persistence through scheduled task
- The ransomware creates a scheduled task that executes the copy of the final payload with a command line argument –Task.
- This is achieved using COM functionalities of the Windows platform which creates a task called “Time Trigger task”
Task Attributes
Attribute | Values |
Task Name | Time Trigger Task |
Frequency of execution | 5 minutes interval / “PT5M” |
Binary Path | C:\\Users\<user_name>\AppData\Local\66245023-274c-4e81-a77c-e98336b3a3a7\<sample>.exe –Task |
- Malware defined task and its properties can be viewed from Task Scheduler program on Windows
- After the scheduled task is set up, the malware executes itself with a new set of command line arguments as shown below:
“–Admin IsNotAutoStart IsNotTask”
- The malware uses the ShellExecuteExW API to execute malware images again, with new command line arguments, and exits the system.
- A newly created instance of the malware can be seen in the process listing with new command line arguments “–Admin IsNotAutoStart IsNotTask”
Parameter-based Behaviour
The behaviour of the malware is mainly governed by the command line arguments. The STOP/DJVU ransomware has two significant execution triggers:
- Initial Trigger
- Scheduled Task trigger
Initial trigger
- When the malware is deployed initially, without any command line arguments, it leads to respawning itself with the following command line arguments “–Admin IsNotAutoStart IsNotTask” .
- At this stage the ransomware downloads additional malware tools, such banking trojans, on to the victim system
Scheduled Task trigger
- When the ransomware is executed from a scheduled task with “–Task” command line argument, it starts encrypting the files on the victim system.