August 14, 2024

Authors: Rui Ataide, Hermes Bojaxhi

GuidePoint’s DFIR team is frequently called upon to respond to Ransomware incidents. While many such incidents have TTPs that are often shared by the security community, we wanted to contribute by sharing some less common TTPs that we have observed recently.

INC Ransomware Group

We recently observed this group use an open-source backup solution, Restic, for data exfiltration, which Huntress previously mentioned in this post. Restic is available here: https://github.com/restic/restic, and in our case, it used the server portion, too, which can be found here: https://github.com/restic/rest-server.

We also wanted to share some insight related to their encryptor, which, in our incidents, was named win.exe or windows.exe for Windows versions, and lin for Linux versions. The encryptor has a usage menu that describes its options.

In addition to adding the INC extension to the encrypted files, the encryptor also appends 80 bytes of data to the end of each encrypted file. This 80-byte footer is critical for the decryption process. Here is an example of this 80-byte footer appended to an encrypted PDF file.

• The first 32 bytes are a unique value per file and encryption run. This data is used in the encryption process and, therefore, is critical for decryption. If this data is missing, the file cannot be decrypted even if you have the correct decryptor.
• The next three bytes are the INC marker, which is used to ensure that the decryptor is processing a proper 80-byte footer and not some random data at the end of a file with INC extension.
• The last 16 bytes contain information about the encryption process.
  • 0x01000000 – This DWORD specifies the encryption mode used by the encryptor. The three modes are:
    • 0x00000000 – Fast (First, middle, and last blocks only)0x01000000 – Medium (Multiple blocks, details below)0x02000000 – Slow (Full file encryption)

    0x40420F00 – This DWORD specifies the block size that is encrypted. In this case, 0x000F4240 = 1,000,000 bytes.0x05000000 – This DWORD specifies the skip size during encryption. This value is multiplied by the Encryption Block Size. So, in this case, the encryptor has skipped 5 x 1,000,000 = 5,000,000 bytes. In an encrypted file, the first 1,000,0000 bytes will be encrypted, followed by 5,000,000 bytes of unencrypted data, and then another block of encrypted data, and so forth. During decryption, this value only matters if the Medium encryption mode was used. It is ignored for the Fast and Slow modes.

  • 0x02000000 – This DWORD specifies the number of encrypted blocks within the file. In this example, there will be 2 blocks of encrypted data (1,000,000 bytes each). The value of this field will depend on the size of the file and the encryption mode.

If you purchase a decryptor, it is mandatory that you make full backup copies of the encrypted data before proceeding with the decryption process. Doing so ensures that any mishaps with the decryption process do not irreversibly destroy your data and, therefore, any chances of successful decryption.

Looking at the footer of an encrypted file can inform you of your chances for recovery without a decryptor, as well as the chances of success for the decryptor. Here are a couple of scenarios:

1. A file shows signs of encryption, has the INC extension, but is missing the 80-byte footer at the end: In this case, you cannot decrypt this file even if you have the correct decryptor.
2. A VMDK file shows signs of encryption, has the INC extension, and the 80-byte footer shows that the Fast mode was used: In this case, there is a very good chance that you can recover most of the file system using forensics tools since only a small amount of data within the VMDK file is encrypted. You may not be able to boot the VM, but you will be able to extract most, if not all, files from the file system of the VMDK if no OS-level encryption was used.
3. A file has the INC extension, shows no signs of encryption, and has an 80-byte footer with NULL bytes: In this case, the encryption process failed halfway. You can simply remove the INC extension and remove the 80 bytes from the end of the file, and the file will be in its original state.
4. A file has one INC extension and shows signs of encryption, but after decryption the file is still encrypted and shows a new 80-byte footer at the end: This means the file was encrypted multiple times. In this case, you will need to add another INC extension and repeat this process as many times as these footers reappear.
   • We did run into an instance where we found three footers in a large (2.5TB) encrypted backup file, even though the file had only one extension (the fact that the first two footers are not encrypted by the subsequent encryption process is simply due to where the encrypted blocks fell within this large file).

In our experience, the decryption process was successful overall, with only a small number of random files being corrupted during the encryption process. Namely, the files were encrypted and had the .INC extension, but not the 80-byte footer. In these cases, decryption is not possible.

If you are considering purchasing a decryptor, the proof of decryption is typically done with small files. So, before purchasing a decryptor, you should also check your critical files (such as full or incremental backup files) or other large critical files (such as database files or VMDKs) to ensure that they have at least one 80-byte footer. Otherwise, decryption of these files will not be possible.

Rhysida Ransomware Group

In our recent incidents involving the Rhysida group, the predominant intrusion vector was Search Engine Optimization (SEO) poisoning, with themes such as downloading Microsoft Teams, which leads the user to a malicious Microsoft look-alike site that delivers a digitally signed dropper named Teams.exe. One such sample can be found here.

GuidePoint then observed several of the TTPs described by CISA here, such as the use of AnyDesk, NetSupport, extensive use of PowerShell, and living off the land tools. In addition to these TTPs, we saw this threat actor deploy a custom tool that appears to be related to SocksProxyGo as described by PRODAFT. Based on additional open-source intelligence (OSINT), we have observed that this tool has evolved since the above reference with samples using Go obfuscation and other techniques, including some of the latest versions that use C++ and possibly other languages, too.

Based on the knowledge acquired around this backdoor, GuidePoint performed some research to validate and obtain additional knowledge on this type of malware. Several instances of this malware were uncovered through VirusTotal threat hunting, some in recent weeks in relation to the writing of this post.

Most of the samples are DLL files, which have some interesting patterns in their naming convention. Some of these names (such as hematologists and subordinates) come from within the metadata of the samples rather than what the TA may have named them during the incident. Some of the scheduled tasks that were used for the persistence of these DLLs were also themed around words like “hematologists”.

Some of the recent submissions have names that mimic security vendor/product names on the metadata of these files. According to VirusTotal data, these are now also UPX packed and written in C++.

Some of the samples have high detection rates on VirusTotal by now. However, not all samples have high detection rates, such as file C64Proxy.dll submitted on August 1, 2024, with only 2/75 detections. Even these recent samples used C2 servers that were already known on the C2IntelFeeds mentioned below.

This Trojan also shows a common pattern in terms of network traffic activity as seen in the behavior section of the malware analysis in VT. This includes the use of OpenDNS DNS requests to detect the victim’s public IP, and connections to a path named “/ping” on their C2s.

From the endpoint perspective, a common behavior of this malware is for rundll32.exe to load the DLL and call the “Test” export function. The DLL is usually entrenched as a scheduled task. Furthermore, when the Trojan is loaded, it spawns a PowErsHELl.exe child process via rundll32.exe, which in turn launches nslookup.exe to obtain the victim’s public IP via the previously mentioned OpenDNS service.

While some of the earlier/older versions of these Trojans are written in the Go language, they also contain references to two additional open-source projects: go-cmd/Cmd and Invoke-SocksProxy. The most recent samples are either packed/obfuscated or not detected as Go-based binaries at all.

Another commonality between several of these files is the high number of randomly named export functions that seem to serve no purpose.

Finally, several C2 IPs are also listed on OSINT feeds/data as C2IntelFeeds.

Overall, we hope this additional information helps prevent the next ransomware attack and/or perform some additional validation before purchasing any decryptors.

Rhysida IOC Tables

Rhysida IP Addresses

Rhysida Hashes and Hosting Locations

Additional Rhysida Hashes

*** This is a Security Bloggers Network syndicated blog from The Guiding Point | GuidePoint Security authored by GuidePoint Security. Read the original post at: https://www.guidepointsecurity.com/blog/update-from-the-ransomware-trenches/