When Threat Actors Fly Under the Radar: Vatet, PyXie and Defray777

This post is also available in: 日本語 (Japanese)

Last, but Not Least: Defray777

Defray777 is an elusive family of ransomware also known as Ransom X and RansomExx. Although it has recently been covered in the news as a new family, it has been in use since at least 2018 and is responsible for a number of high-profile ransomware incidents -- as detailed in the articles we linked to.

Defray777 runs entirely in memory, which is why there have been so few publicly discussed samples to date. In several recent incidents, Defray777 was loaded into memory and executed by Cobalt Strike, which was delivered by the Vatet loader.

During our research, we discovered multiple decryptors for this ransomware family, going back as early as 2018. Reviewing decryptors from 2018 until present shows that there has been consistency in the ransomware’s encryption and decryption methodology, as well as the use of Themida for packing their decryptors. Table 10 shows a list of Defray777 decryptors discovered in AutoFocus, with a list of organizations that suffered ransomware attacks. This shows that Defray777 has been consistently active since 2018.

Table 10. Defray777 ransomware attacks listed by date and victim.

We have examined several recent Defray777 samples, including one sample that was obtained directly from memory during a recent incident. Our in-depth analysis resulted in the findings outlined below.

Decrypted Strings

The string decryption process is the same as we saw with PyXie. The following strings were decrypted from a recent Defray777 sample:

Table 11. Defray777 encrypted strings.

Prioritizing Defray777 on the Impacted System

While deep diving on a recovered Defray777 sample, we found that Defray777 exhibits the following notable characteristics regarding the prioritization of threads and processes:

• During execution, the ransomware uses SetProcessPriorityBoost to prioritize the threads of the Defray777 process.
• Defray777 additionally focuses on creating and prioritizing threads for encryption by calling SetThreadAffinityMask and SetThreadPriorityBoost.
• Defray777 uses multithreading to improve ransomware performance.

Killing “Undesirable” Processes

As part of the execution workflow, Defray777 creates threads that will be responsible for the killing of processes that the threat actors deem to be “undesirable.” The execution continues by getting a listing of processes using CreateToolhelp32Snapshot before iterating through all active processes (with the exception of itself) and killing all “undesirable” processes. Defray777 specifically targets process that can be opened with the desired access of SYNCHRONIZE | PROCESS_QUERY_INFORMATION | PROCESS_VM_WRITE | PROCESS_VM_READ | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD.

Defray777 excludes all processes that contain the system file path in their full image path. Additionally, the ransomware will exclude the following processes from being killed during execution:

Table 12. Excluded processes.

Stopping System Services

During execution, Defray777 stops the following services from running:

Table 13. Services stopped by Defray777.

File Encryption

Based on a recent Defray777 sample recovered from memory, the ransomware will get a listing of all logical drives on the system using a call to GetLogicalDriveStringsW before iterating through each drive to encrypt files using the following process:

• To begin, Defray777 checks for whether the processor feature PF_XMMI64_INSTRUCTIONS_AVAILABLE is present on the impacted system.
  • If enabled, Defray777 knows that SSE2 is supported and more complex mathematical operations are possible.
• Defray777 will also determine if the processor is capable of using AES-NI for improved encryption performance.
• As encryption begins, a ransom note will be created in each directory where files will be encrypted.
  • The name of the ransom note will vary. However, from our research, the ransom notes most commonly contain a combination of exclamation points, the string “README,” and a reference to the victim name.
  • Example: !!!_IMPACTED_Client_README_!!!.txt
• The file contents will be encrypted using an on-the-fly generated AES key that gets encrypted with RSA-4096 and stored in the file footer in a 512-byte block.
• The encrypted file will be renamed by appending an extension that consists of a unique victim identifier and a randomized eight-digit hexadecimal number.
  • Example: .v1ct1m-1bc461ac

Specifically, the encryption mechanism consists of the following steps:

• Dynamically generate a 32-byte AES key.
• Encrypt the file with AES-256 in ECB mode using 16-byte blocks.
• Encrypt the AES key with RSA-4096 and append the 0x200 byte cipher text to the end of the encrypted file.

Encryption Exclusions

During the encryption process, Defray777 aims to encrypt as many files as possible without impacting the system’s core functionality. To accomplish this, Defray777 uses a set of excluded folders, files and file extensions that will not be encrypted during execution.

Excluded Folders:

Table 14. Folders excluded from encryption by Defray777.

Excluded files:

Table 15. Files excluded from encryption by Defray777.

It is also important to note that Defray777 adds the name of the ransom note into the excluded files list.

Excluded extensions:

Table 16. Extensions excluded from encryption by Defray777.

Searching for Unmapped File Shares

During execution, Defray777 uses WNetOpenEnumW and WNetEnumResourceW to search for file shares that may contain files that could be encrypted. This tactic has been seen amongst other ransomware variants in the wild to encrypt files that are accessible via unmapped file shares.

Anti-Forensic Measures

After all files are encrypted on the system, Defray777, like many other ransomware variants, implements common anti-forensics measures to remove as much evidence of the intrusion as possible and make it extremely difficult for the system to be recovered without a backup. Although these commands are common amongst other ransomware variants, Defray777 runs commands post-encryption, which means that when security tools alert or take action against Defray777, the files have already been encrypted.

Commands executed by Defray777:

Table 17. Anti-forensic commands executed by Defray777.

Registry keys modified:

Table 18. Registry Keys Modified by Defray777.

Defray777’s Port to Linux

During the course of our research, we found that Defray777 ransomware has been ported over to Linux. Before Defray777, ransomware that impacted both Windows and Linux operating systems was limited to being written in Java or scripting languages such as Python. These ransomware variants would be considered cross-functional since they were written in a single language that must be installed and supported by both operating systems. Defray777’s port to Linux ensures that the ransomware has standalone executables for each platform with no external dependencies.

A ZIP archive was uploaded to a public malware repository on Oct. 17, 2020 that contained a Windows executable that was identified as a Defray777 decryptor. Additionally included in this ZIP archive was an ELF binary named decryptor64. Analysis of this binary determined it to be another Defray777 decryptor that had been ported to Linux.

Armed with the idea that there may be Linux versions of Defray777 in the wild, we began hunting in AutoFocus and quickly uncovered an ELF version of the ransomware encryptor.

Reviewing this sample further indicated that it was uploaded in August 2020. As of early October 2020, there appear to be zero detections by antivirus (AV) in VirusTotal for the Linux version of Defray777.

A deeper review of the Linux and Windows variants of Defray777 determined that the encryption and decryption processes used were nearly identical. In fact, by generating our own RSA key pair and modifying the binaries, we were able to confirm that the encryptors and decryptors for both operating systems were interchangeable.

Unlike the Windows versions, the developers didn’t seem to put any effort into protecting the Linux samples. To our surprise, the binaries we analyzed still had their symbols intact, which made reversing them quite a bit easier.

One of the biggest differences between the Windows and Linux variants is the logic that determines which files to encrypt. The Windows version will recurse the file system and encrypt anything that isn’t explicitly excluded. In contrast, the Linux variant will only encrypt directories specified in a command line argument.

Continue reading: Linking Vatet, PyXie and Defray777