Update from the Ransomware Trenches

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, then another block of encrypted data, and so forth. This value only matters during decryption 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 two blocks of encrypted data (1,000,000 bytes each). The value of this field will depend on the file size 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

109.176.207.22	Possible Rhysida Trojan IP (Unverified)
139.64.133.194	Possible Rhysida Trojan IP (Unverified)
159.100.6.103	Possible Rhysida Trojan IP (Unverified)
173.46.80.206	Possible Rhysida Trojan IP (Unverified)
185.216.144.51	Possible Rhysida Trojan IP (Unverified)
216.74.123.41	Possible Rhysida Trojan IP (Unverified)
37.59.205.5	Possible Rhysida Trojan IP (Unverified)
5.161.252.127	Possible Rhysida Trojan IP (Unverified)
51.68.216.13	Possible Rhysida Trojan IP (Unverified)
51.89.137.8	Possible Rhysida Trojan IP (Unverified)
57.128.166.214	Possible Rhysida Trojan IP (Unverified)
65.108.49.36	Possible Rhysida Trojan IP (Unverified)
78.47.60.67	Possible Rhysida Trojan IP (Unverified)
85.239.53.94	Possible Rhysida Trojan IP (Unverified)

Rhysida Hashes and Hosting Locations

048660468e44dbddb5631f288a19060ac41cb82daf2802de46713dd8ed372b71	“hxxp://173[.]46[.]80[.]206/ping”
22f5335e9a594e673f1d57fdd8bd0e771e900b90b3230f594c9b98f8f7e70033	“hxxp://google-static[.]work[.]gd/ping”
26e71d383a69a494ebb03d7e34ea5f3ba1465a97411084251509a68f32d41e13	“hxxp://216[.]74[.]123[.]41/ping”
367dcaa16a199ab8e9c8b837962c9c8ee3db36b94f56af09e34177d5a2160db7	“hxxp://107[.]175[.]32[.]226/ping”
3fd2155ed05bcb8167b2d967ff8f140db66c646dbcef0ed6dc9d3b6685bd60d8	“hxxp://139[.]64[.]133[.]194/ping”
40c325544cf7d41915f19c02a128c44e14cc4caafd47d0b12b59707e4b8ff4f8	“hxxp://173[.]46[.]80[.]206/ping”
422e5fe9265ff01e8bf2bf2d5b7de6faf358cc88da8c5ad71bac220983fc1345	“hxxp://216[.]74[.]123[.]41/ping”
6867e62933c94396e60754def16fe29d817a9671bf00c90e48d433a929b4c349	“hxxp://139[.]64[.]133[.]194/ping”
76cbcd2b69ab608685ebc243a4e0fc5a38e698a9f0a40e61338961ca12227ba1	“hxxp://172[.]96[.]189[.]249/ping”
78b42d4d051cb1f1c4e1f47e8390810c23ba0e24f8dc689b99b40996945abc87	“hxxp://108[.]62[.]141[.]161/ping”
7bff54dcaed42fbf825d0464b39106be6412822251cc7e68f12d1e8cccfc524e	“hxxp://23[.]227[.]198[.]234/ping”
960993e88b54f129eeae86860c400df1131333be6d2bbda271024985c8062dcb	“hxxp://23[.]227[.]198[.]234/ping”
9db2c7d2b32abd9408aad9ca0891d405396ec09583ae463798ffa33599196eb8	“hxxp://139[.]64[.]133[.]194/ping”
9f66708cb440a2c849457da724ae745263b94e9a30170568ed1a7004f0d405d6	“hxxp://135[.]125[.]216[.]24/ping”
ca5931d48e2a8a539fc84596fdf3394809ebdf07490a86df8c5648883ee594df	“hxxp://23[.]108[.]57[.]83/ping”
d8a9f37d2f3165e1ba74fda062af1402318e01705219769e46292090e35c15c3	“hxxp://135[.]125[.]216[.]24/ping”
e606db5a8dafe5765dab9d06832f2ef558cd43fe400dda1e120fabc67a7f948f	“hxxp://51[.]77[.]126[.]67/ping”
fbc17b0087710c808ab01d145209cb9ac1617168f552924b909ee5ce94ab7211	“hxxp://173[.]46[.]80[.]206/ping”
fd9e1f9284cdba556e9df2cb39f15bc38135b5a894d6bd271d8fd6882da5d42b	“hxxp://139[.]64[.]133[.]194/ping”

Additional Rhysida Hashes

048660468e44dbddb5631f288a19060ac41cb82daf2802de46713dd8ed372b71

22f5335e9a594e673f1d57fdd8bd0e771e900b90b3230f594c9b98f8f7e70033

26e71d383a69a494ebb03d7e34ea5f3ba1465a97411084251509a68f32d41e13

367dcaa16a199ab8e9c8b837962c9c8ee3db36b94f56af09e34177d5a2160db7

3fd2155ed05bcb8167b2d967ff8f140db66c646dbcef0ed6dc9d3b6685bd60d8

40c325544cf7d41915f19c02a128c44e14cc4caafd47d0b12b59707e4b8ff4f8

422e5fe9265ff01e8bf2bf2d5b7de6faf358cc88da8c5ad71bac220983fc1345

6867e62933c94396e60754def16fe29d817a9671bf00c90e48d433a929b4c349

76cbcd2b69ab608685ebc243a4e0fc5a38e698a9f0a40e61338961ca12227ba1

78b42d4d051cb1f1c4e1f47e8390810c23ba0e24f8dc689b99b40996945abc87

7bff54dcaed42fbf825d0464b39106be6412822251cc7e68f12d1e8cccfc524e

960993e88b54f129eeae86860c400df1131333be6d2bbda271024985c8062dcb

9db2c7d2b32abd9408aad9ca0891d405396ec09583ae463798ffa33599196eb8

9f66708cb440a2c849457da724ae745263b94e9a30170568ed1a7004f0d405d6

ca5931d48e2a8a539fc84596fdf3394809ebdf07490a86df8c5648883ee594df

d8a9f37d2f3165e1ba74fda062af1402318e01705219769e46292090e35c15c3

e606db5a8dafe5765dab9d06832f2ef558cd43fe400dda1e120fabc67a7f948f

fbc17b0087710c808ab01d145209cb9ac1617168f552924b909ee5ce94ab7211

fd9e1f9284cdba556e9df2cb39f15bc38135b5a894d6bd271d8fd6882da5d42b