Introduction

In a recent incident response case, we discovered a new and notable ransomware family in active use by the attackers, which we named “Ymir”. The artifact has interesting features for evading detection, including a large set of operations performed in memory with the help of the malloc, memmove and memcmp function calls.

In the case we analyzed, the attacker was able to gain access to the system via PowerShell remote control commands. After that, they installed multiple tools for malicious actions, such as Process Hacker and Advanced IP Scanner. Eventually, after reducing system security, the adversary ran Ymir to achieve their goals.

In this post, we provide a detailed analysis of the Ymir ransomware, as well the tactics, techniques and procedures (TTPs) employed by the attackers.

Analysis

Static analysis

Our analysis began with a basic inspection of the artifact. We started by analyzing its properties, such as the file type, and relevant strings and capabilities, as shown in the table and images below.

Although the binary does not raise suspicions of being packed, as its entropy is not high enough, the presence of API calls to functions like malloc, memmove and memcmp indicates that it can allocate memory to insert malicious code.

The binary also suspiciously imports functions, such as CryptAcquireContextA, CryptReleaseContext, CryptGenRandom, TerminateProcess and WinExec, from operating system libraries. These API calls are typically found in various ransomware samples.

Even though most of the sample information is unpacked in memory during runtime, we were able to find some useful indicators in the binary strings, including the ransom note filename and contents in a PDF file, encryption extension, PowerShell commands, and some hashes used by the encryption algorithms, as shown in the following images.

The attacker used the MinGW compiler, a native Windows port of the GNU Compiler Collection (GCC).

The following table shows other useful string indicators we found in the course of our analysis.

One interesting fact is that the PDF creation date was August 31, 2024, which matches the binary compilation timestamp (2024-08-31), as shown in the image below.

Static analysis also shows that the PDF used as the ransom note is present in the .data section of the binary. The information hardcoded in this kind of file is very useful for creating detection rules and indicators of compromise.

After reaching the main function, the malware executes another function with calls to other functions to get system information. To streamline our analysis, we renamed this function to Get_System_Information:

The artifact gathers system information by using the API calls listed below.

• GetSystemTimeAsFileTime: retrieves the current system date and time.
• GetCurrentProcessId: gets the current process identifier (PID).
• GetCurrentThreadId: retrieves the identifier of the calling thread.
• GetTickCount: gets the amount of time that the system has been running for in milliseconds. This is used for detecting that the artifact is being debugged.
• QueryPerformanceCounter: retrieves the current value of the performance counter, which can be used for time-interval measurements.

The malware also contains some execution restrictions which are activated when certain parameters are set. For example, the --path parameter disables self-delete, allowing the attacker to reuse the binary for other directories.

While reverse-engineering the sample, we found that it borrowed code from functions related to CryptoPP, an open-source cryptographic library written in C++.

The malware also has a hardcoded list of file name extensions to exclude from encryption.

Dynamic analysis

While running the ransomware, we spotted hundreds of calls to the memmove function. After analyzing the data, we found that it loaded small pieces of instructions into memory for performing malicious functions. The following image shows a fragment of the malware loading environment variables after calling memmove.

The malware constantly uses the memmove function while enumerating subdirectories and files inside the affected system, so they can be encrypted later.

It also uses memmove to load strings that contain locations in the victim’s filesystem and are used for comparing with common directory names during runtime.

The sample uses the RtlCopyMemory function from the ntdll.dll library to load additional libraries, such as CRYPTSP.dll, rsaenh.dll, bcrypt.dll and kernelbase.dll.

The artifact uses the stream cipher ChaCha20 algorithm to encrypt files, appending the extension .6C5oy2dVr6 to each encrypted file.

Additionally, it copies the PDF contents from the .data section and uses the _write and _fsopen functions to generate a ransom note in PDF format within every directory in the affected system.

The ransom note informs the victim about what happened to the affected system and instructs them to contact the attackers for a deal. Although the note mentions that the attackers have stolen the data from the affected machine, the malware does not have any network capabilities for data exfiltration. This leads us to believe that the adversaries would steal data with other means once they obtained access to the computer, such as through HTTP, FTP or cloud storage uploads.

We spotted one odd string, a comment written in the Lingala language. This language is used in the Democratic Republic of the Congo, Republic of the Congo, Angola and the Central African Republic.

Another interesting fact is that the sample searches for PowerShell in each subdirectory as it repeatedly calls the RtlCopyMemory function. Once PowerShell is located, the malware uses it for deleting itself. In our investigation, we copied powershell.exe into our Desktop folder, so it was used for deleting the sample.

The following diagram shows a summary of the sample’s execution. Note that the only child process created was powershell.exe — the malware creates a PowerShell instance even if it finds one in the system. Subsequently, PowerShell calls conhost.exe, which is used for running services in the background.

The malware calls PowerShell with the cmdlet Start-Sleep to wait 5 seconds, and finally, uses the Remove-Item command to delete itself from the machine, as shown in the image below.

YARA rule

Based on our analysis of the sample, we developed the following YARA rule for detecting the threat in real time. The rule considers the file type, relevant strings and library function imports.

Telemetry

Using the above rule, we were able to query threat intelligence portals and find a similar sample originating from Pakistan. We believe that the attacker used a VPN network or Tor to hide their IP. The artifact we discovered looks like a test binary sent by the attacker to check if it would be detected by security vendors. The sample receives a --path parameter from the command line, which specifies the directory to be encrypted. However, it neither encrypts the files nor generates a ransom note.

What caught our attention was that this test version of the executable, similarly to the full-featured sample, did not delete itself when executed with the --path parameter, which made sense, since the adversary might want to select certain directories during the attack.

By comparing the two detections, we concluded that the final sample with the fully enabled encryption features, unlike the test variant, had extended functionality implemented in additional strings. These included the extension appended to the name of the encrypted files ( .6C5oy2dVr6) and the information present in the PDF file generated as a ransom note.

At the time of our research, 12 security vendors including Kaspersky detected the threat.

The ransomware incident

In addition to analyzing the malware, we managed to investigate an incident in Colombia where the Ymir sample was obtained. Our forensic analysis revealed that crucial evidence had been lost through the attacker’s efforts to cover their tracks. We at Kaspersky GERT were able to identify that two days before the ransomware deployment, a new RustyStealer threat was detected on multiple systems, allowing the attackers to control the machines, send commands, and gather information from compromised infrastructure. Malicious activity was detected on a domain controller shortly after, including compromised access on behalf of legitimate users, including one with high privileges. The initial RustyStealer sample was a PE file compiled with Rust and deployed to Windows\Temp under the name AudioDriver2.0.exe.

This sample, named Trojan.Win32.Sheller.ey by Kaspersky, has the ability of gathering information about the file system. This sample has obfuscated content for obstructing analysis and includes shared modules indicating that the artifact can invoke functions from APIs, such as native Windows DLLs.

This sample also connects to the C2 server 74.50.84[.]181 on port 443, detected by Kaspersky as a host for malicious files since August 2024.

The attackers compromised the domain controller and used it to continue infiltrating systems in the targeted infrastructure. They abused compromised credentials gathered by the stealer to hop between systems using WinRM and PowerShell remote control capabilities, and then executed a set of two scripts that were confirmed to be a part of the proxy malware threat SystemBC.

Both scripts use PowerShell to establish a covert channel to the IP address 94.158.244[.]69 on port 443. Based on the strings from the scripts we were able to obtain, we implemented Yara rules for identifying other samples and C2 servers configured with the same codification and spotted in the wild.

One of these scripts was spotted in multiple systems, collected as a script block for PowerShell that included a different approach and a different C2 system (5.255.117[.]134 on port 80). It was probably used to exfiltrate information from the infrastructure according to the following hardcoded functions and their instructions.

• GetServerByFilename,
• SendFile,
• SearchRoot.

The script establishes communication with the C2 server and sends information, including a specific key that allows the attacker to identify the affected company.

The SearchRoot function contains a loop that searches for all files that are included in the requested folder and checks for a specific filter: the malware only uploads files with a size greater than 40 KB that were created after a specified date.

The script is Base64 encoded and passed to the following command for execution.

According to our GERT analysis, at the time of the research, there was a service configured at this IP address (5.255.117[.]134) for uploading files that were collected with the SystemBC scripts.

At the same time, multiple creations and executions of the well-known programs Advanced IP Scanner and Process Hacker were alerted on several systems.

• advanced_ip_scanner.exe;
• processhacker-2.39-setup.exe.

Finally, two days after the initial RustyStealer intrusion, attackers deployed the Ymir ransomware by executing remote connections and uploading the payload. Some traces of the execution were detected, in particular those associated with the PowerShell self-destruct script. Also, a part of the ransom note was configured in the registry key field legalnoticecaption, located in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, which invites the user to look for additional details in the ransom note, named “INCIDENT_REPORT.pdf”:

Conclusion

A link between malware stealer botnets acting as access brokers and the ransomware execution is evident. The Ymir development represents a threat to all types of companies and confirms the existence of emerging groups that can impact business and organizations with a configurable, robust and well-developed malware. We have seen initial access brokers invade an organization and ensure persistence. Ymir was deployed to the targeted system shortly after. This new ransomware family was configured in a secure scheme, making it impossible to decrypt the files from the targeted system. The group behind this threat has not presented a dedicated leak site or any additional information yet, but we will continue monitoring their activity. Alerts were triggered two days prior to the ransomware incident, and the lack of action on the critical system warnings allowed the attackers to launch the ransomware. This highlights the need for improved response strategies beyond relying solely on endpoint protection platforms (EPP).

Kaspersky products detect this new threat as Trojan-Ransom.Win64.Ymir.gen.

Tactics, techniques and procedures

Below are the Ymir TTPs identified from our malware analysis.

RustyStealer TTPs:

Indicators of Compromise

File Hashes
3648359ebae8ce7cacae1e631103659f5a8c630e
fe6de75d6042de714c28c0a3c0816b37e0fa4bb3
f954d1b1d13a5e4f62f108c9965707a2aa2a3c89 (INCIDENT_REPORT.pdf)
5ee1befc69d120976a60a97d3254e9eb
5384d704fadf229d08eab696404cbba6
39df773139f505657d11749804953be5
8287d54c83db03b8adcdf1409f5d1c9abb1693ac8d000b5ae75b3a296cb3061c
51ffc0b7358b7611492ef458fdf9b97f121e49e70f86a6b53b93ed923b707a03
b087e1309f3eab6302d7503079af1ad6af06d70a932f7a6ae1421b942048e28a

IPs
74.50.84[.]181:443
94.158.244[.]69:443
5.255.117[.]134:80
85.239.61[.]60