Executive Summary

• SentinelLabs has observed the first Linux variant of Cl0p ransomware.
• The ELF executable contains a flawed encryption algorithm making it possible to decrypt locked files without paying the ransom.
• SentinelLabs has published a free decryptor for this variant here.

Background

SentinelLabs observed the first ELF variant of Cl0p (also known as Clop) ransomware variant targeting Linux systems on the 26th of December 2022. The new variant is similar to the Windows variant, using the same encryption method and similar process logic.

The mentioned sample appears to be part of a bigger attack that possibly occurred around the 24th of December against a University in Colombia (sample1, sample2, sample3, sample4, sample5). On the 5th of January the cybercrime group leaked victim’s data on their onion page.

ELF Technical Analysis

The ELF Cl0p variant is developed in a similar logic to the Windows variant, though it contains small differences mostly attributed to OS differences such as API calls. It appears to be in its initial development phases as some functionalities present in the Windows versions do not currently exist in this new Linux version.

A reason for this could be that the threat actor has not needed to dedicate time and resources to improve obfuscation or evasiveness due to the fact that it is currently undetected by all 64 security engines on VirusTotal. SentinelOne Singularity detects Cl0p ransomware on both Linux and Windows devices.

Initially, the ransomware creates a new process by calling fork and exits the parent-process. The child-process sets its file mode creation mask to any permission (read, write, execute) by calling umask(0). It then calls setsid, creates a session and sets the process group ID. It tries to access root by changing the working directory to “/” (chdir(“/”)). Once the permissions are set, the ransomware proceeds encrypting other directories.

Targeted Folders & Files

While the Windows versions contain a hashing algorithm in order to avoid encrypting specific folders and files, such functionality was not observed in the Linux variant. The ELF variant targets specific folders, subfolders and all files/types.

The discovered ELF sample targets files contained in the following directories for encryption, though we do not exclude the possibility of future versions including more directories.

Folder	Description
/opt	Contains subdirectories for optional software packages
/u01	Oracle Directory, mount point used for the Oracle software only.
/u02	Oracle Directory, used for the database files.
/u03	Oracle Directory, used for the database files.
/u04	Oracle Directory, used for the database files.
/home	Contains the home directory of each user.
/root	Contains the home directory of the root user.

Encryption Flaw

Windows versions of Cl0p ransomware use a Mersenne Twister PRNG (MT19937) to generate a 0x75 bytes size RC4 key for each file. This key is then validated (checks if the first five bytes are NULL) and used for file encryption. Then, by using the RSA public key, it encrypts the generated RC4 key and stores it to $filename.$clop_extension. Victims who pay the ransom demand receive a decryptor which decrypts the generated Cl0p file using the RSA private key, retrieves the generated RC4 key, and then decrypts the encrypted file.

This core functionality is missing in the Linux variant. Instead, we discovered a flawed ransomware-encryption logic which makes it possible to retrieve the original files without paying for a decryptor.

The Linux variant contains a hardcoded RC4 “master-key” which, during the execution of the main function, is copied into the global variable szKeyKey.

Sample’s RC4 “master-key”:

Jfkdskfku2ir32y7432uroduw8y7318i9018urewfdsZ2Oaifwuieh~~cudsffdsd

During the file encryption phase, the ransomware – similar to the Windows version – generates a 0x75 bytes size RC4 key, with the use of a lookup table and a PRNG byte. This generated RC4 key is used to encrypt the mappedAddress and write it back to the file.

Then by using the RC4 “master-key” the ransomware encrypts the generated RC4 key and stores it to $filename.$clop_extension. By using a symmetric algorithm (second RC4) to “encrypt” the file’s RC4 key, we were able to take advantage of this flaw and decrypt Cl0p-ELF encrypted files.

Cl0p-ELF Decryption Logic:

1. Retrieve RC4 “master-key”.
2. Read all $filename.$clop_extension.
3. Decrypt with RC4 using the RC4 “master-key”, the generated RC4 key.
4. Decrypt $filename with RC4 using the generated RC4 key.
5. Write decrypted to $filename.

We packed all this logic into the following Python script.

Cl0p File-Key Creation Flaw

The 0x75 bytes size PRNG RC4 key is encrypted with RC4 using the RC4 “master-key”. The encrypted RC4 output is 0x75 bytes size, though writes 0x100 bytes into the created Cl0p key $filename.$clop_extension. This results in writing memory data to the file and more specifically stack variables.

This flaw provides some information regarding the file before encryption. This includes:

• File fstat64 result
  • total size, in bytes, file size (st_size)
  • time of last status change, exact time of file encryption (st_ctime)
  • and more forensics information regarding the file before the encryption.
• Size of buffer for file encryption (with check of >= 0x5f5e100 )
• RC4 “master-key” size
• RC4 PRNG key size

struct  clopelfkeyfile  {
	byte encr_rc4key[117]; // encrypted RC4 PRNG key, size 0x75 bytes
	stat fdstat; // stat(fd, &fdstat), size 0x58 bytes
	long fdid; // file node unique id, size 0x8 bytes
	int fd; // file descriptor, size 0x4 bytes
	int fdmappedaddr; // file mapped address, size 0x4 bytes
	off_t fdsize; // file size, size 0x8 bytes
	int rc4_msize; // RC4 "master-key" size, size 0x4 bytes
	long rc4_fsize; // RC4 PRNG key size, size 0x8 bytes
	int fdnameaddr; // filename string address, size 0x4 bytes
	int frameaddr; // frame pointer address, size 0x4 bytes
	int retaddr; // function return address, size 0x4 bytes
	byte fdpathaddr[3]; // part of filepath strings address, size 0x3 bytes
}

Developed Functions & Names

In ELF binaries the .symtab, Symbol Table Section, holds information needed to locate and relocate a program’s symbolic definitions and references, allowing us to retrieve function and global variable names.

Function Name	Description
do_heartbeat(void)	Main function which starts the encryption of various folders.
find(char *,char const*)	Multiple calls of this function are done by do_heartbeat; this function takes as parameter 1) the starting folder to encrypt (example, “/opt”) 2) regex of files to encrypt (example, “*.*”) and performs a recursive search from the starting folder until encrypts the “matching” regex files.
CreateRadMe(char *)	This function takes as parameter the folder to create the ransom note.
EncrFile(char *)	Encrypts given filepath.
existsFile(char *)	Checks if File exists, or if the process has the permissions to open.
_rc4Full(void const*,ushort,void *,ulong)	Wrapper function to _rc4Init and _rc4, which is used to encrypt a buffer with a given key.
Createkey(char *,uchar *)	Creates and writes into “%s.C_I_0P” the encrypted buffer.

Global Variable	Description
szKeyKey	Global variable of 0x64 bytes size, initialized during main function, containing RC4 “master-key” which encrypts the “randomly” generated 0x75 bytes size RC4 key.

Differences to Windows Variant

Rather than simply port the Windows version of Cl0p directly, the authors have chosen to build bespoke Linux payloads.  We understand this to be the primary reason for the lack of feature parity between the new Linux version and the far more established Windows variant.

SentinelLabs expects future versions of the Linux variant to start eliminating those differences and for each updated functionality to be applied in both variants simultaneously.

Some of the differences worth highlighting are detailed below:

Differences	Description
Files/Folders exclusions	The Windows variant contains a hashing algorithm which excludes specific folders and files from encryption. This functionality was not observed in the Linux variant.
Extension exclusions	The Windows variant contains a hardcoded list of extensions to exclude from encryption.  This functionality was not observed in the Linux variant.
Different methods of Reading/Writing depending on file size.	The Windows variant, depending on the size of the file, will choose different methods of reading a file and writing the encrypted buffer. Small files are ignored, medium-sized files will make use of ReadFile/WriteFile, large files will use CreateFileMappingW/MapViewOfFile/UnmapViewOfFile. The Linux variant encrypts all the files using mmap64/munmap. Both variants only encrypt the first 0x5f5e100 bytes of large files.
Ransom Note Decryption	The Windows variant stores the encrypted ransom note as a resource and decrypts it with a simple XOR algorithm. The Linux variant stores the note as plain text in “.rodata”.
Drive enumeration	The Windows variant initially enumerates through drives in order to “find” the starting point to recursively encrypt the folders. The Linux variant contains hardcoded “starting” folders.
RC4 default Key	Once the Windows variant generates a 0x75 size PRNG RC4 Key, it will check if the first 5 bytes are NULL; if so, it uses the default key for encryption. The Linux version does not perform this validation and does not contain a default RC4 key in case the first 5 bytes of the PRNG RC4 are NULL.
Command Line Parameters	The Windows variant can be executed in three ways: 1) without parameters encrypting all local and network drives, 2) with “runrun” parameter encrypting only network drives, 3) with a file as parameter which contains the folders to be encrypted (observed temp.ocx/temp.dat). The Linux variant does not accept command line parameters and recursively encrypts the specified hardcoded folders.
RC4 Key Encryption	The Windows variant encrypts the generated RC4 key responsible for the file encryption using the asymmetric algorithm RSA and a public key. In the Linux variant, the generated RC4 key is encrypted with a RC4 “master-key” (flawed logic).

Ransom Notes

The Linux variant of Clop ransomware drops a ransom note on victim machines with a .txt format.

This differs somewhat from the Windows .rtf ransom note, although both use the email addresses unlock@support-mult[.]com and unlock@rsv-box[.]com as ways for victims to contact the attackers.

Conclusion

Over the last twelve months or so we have continued to observe the increased targeting of multiple platforms by individual ransomware operators or variants. The discovery of an ELF-variant of Cl0p adds to the growing list of the likes of Hive, Qilin, Snake, Smaug, Qyick and numerous others.

We know that Cl0p operations have shown little if no slow-down since the disruption in June 2021. While the Linux-flavored variation of Cl0p is, at this time, in its infancy, its development and the almost ubiquitous use of Linux in servers and cloud workloads suggests that defenders should expect to see more Linux-targeted ransomware campaigns going forward.

SentinelLabs continues to monitor the activity associated with Cl0p. SentinelOne Singularity protects against malicious artifacts and behaviors associated with Cl0p attacks including the ELF variant described in this post.

Indicators of Compromise

IOC Type	IOC Value
SHA1 ELF Cl0p	46b02cc186b85e11c3d59790c3a0bfd2ae1f82a5
SHA1 Win Cl0p	40b7b386c2c6944a6571c6dcfb23aaae026e8e82
SHA1 Win Cl0p	4fa2b95b7cde72ff81554cfbddc31bbf77530d4d
SHA1 Win Cl0p	a1a628cca993f9455d22ca2c248ddca7e743683e
SHA1 Win Cl0p	a6e940b1bd92864b742fbd5ed9b2ef763d788ea7
SHA1 Win Cl0p	ac71b646b0237b487c08478736b58f208a98eebf
SHA1 ELF Cl0p Note	ba5c5b5cbd6abdf64131722240703fb585ee8b56
SHA1 Win Cl0p Note	77ea0fd635a37194efc1f3e0f5012a4704992b0e
ELF Ransom Note	README_C_I_0P.TXT
Win Ransom Note	!_READ_ME.RTF
Cl0p Ransom Extension	.C_I_0P
Cl0p Contact Email	unlock[@]support-mult.com
Cl0p Contact Email	unlock[@]rsv-box.com
Cl0p Onion Leak Page	hxxp[:]//santat7kpllt6iyvqbr7q4amdv6dzrh6paatvyrzl7ry3zm72zigf4ad[.]onion
Cl0p Onion Chat Page	hxxp[:]//6v4q5w7di74grj2vtmikzgx2tnq5eagyg2cubpcnqrvvee2ijpmprzqd[.]onion

YARA Rule

rule ClopELF
{
    meta:
        author = "@Tera0017/@SentinelLabs"
        description = "Temp Clop ELF variant yara rule based on $hash"
        reference = "https://s1.ai/Clop-ELF”
        hash = "09d6dab9b70a74f61c41eaa485b37de9a40c86b6d2eae7413db11b4e6a8256ef"
    strings:
        $code1 = {C7 45 ?? 00 E1 F5 05}
        $code2 = {81 7D ?? 00 E1 F5 05}
        $code3 = {C7 44 24 ?? 75 00 00 00}
        $code4 = {C7 44 24 ?? 80 01 00 00}
        $code5 = {C7 00 2E [3] C7 40 04}
        $code6 = {25 00 F0 00 00 3D 00 40 00 00}
        $code7 = {C7 44 24 04 [4] C7 04 24 [4] E8 [4] C7 04 24 FF FF FF FF E8 [4] C9 C3}
    condition:
        uint32(0) == 0x464c457f and all of them
}

Threat Intel Analyst: Antonis Terefos (@Tera0017)
Data Scientist: Anne Postma (@A_Postma)

1. Introduction

TA505 is a sophisticated and innovative threat actor, with plenty of cybercrime experience, that engages in targeted attacks across multiple sectors and geographies for financial gain. Over time, TA505 evolved from a lesser partner to a mature, self-subsisting and versatile crime operation with a broad spectrum of targets. Throughout the years the group heavily relied on third party services and tooling to support its fraudulent activities, however, the group now mostly operates independently from initial infection until monetization.

Throughout 2019, TA505 changed tactics and adopted a proven simple, although effective, attack strategy: encrypt a corporate network with ransomware, more specifically the Clop ransomware strain, and demand a ransom in Bitcoin to obtain the decryption key. Targets are selected in an opportunistic fashion and TA505 currently operates a broad attack arsenal of both in-house developed and publicly available tooling to exploit its victims. In the Netherlands, TA505 is notorious for their involvement on the Maastricht University incident in December 2019. 

To obtain a foothold within targeted networks, TA505 heavily relies on two pieces of malware: Get2/GetandGo and SDBbot. Get2/GetandGo functions as a simple loader responsible for gathering system information, C&C beaconing and command execution. SDBbot is the main remote access tool, written in C++ and downloaded by Get2/GetandGo, composed of three components: an installer, a loader and the RAT.

During the period March to June 2020, Fox-IT didn’t spot as many campaigns in which TA505 distributed their proven first stage malware. In early June 2020 however, TA505 continued to push their flavored GetandGo-SDBbot campaigns thereby slightly adjusting their chain of infection, now leveraging HTML redirects. In the meantime – and in line with other targeted ransomware gangs – TA505 started to operate a data leak platform dubbed “CL0P^_- LEAKS” on which stolen corporate data of non-paying victims is publicly disclosed.

The research outlined in this blog is focused around obtained Get2/GetandGo and SDBbot samples. We unpacked the captured samples and organized them within their related campaign. This resulted in providing us an accurate view on the working schedule of the TA505 group during the past year.

2. Infection Chain and Tooling

As mentioned above, the Threat Actor uses private as well as public tooling to get access, infect the network and drop Clop ransomware.

2.1. Email – XLS – GetandGo

1. The victim receives an HTML attachment. This file contains a link to a malicious website. Once the file is opened in a browser, it redirects to this compromised URL.

2. This compromised URL redirects again to the XLS file download page, which is operated by the actor.

3. From this URL the victim downloads the XLS file, frequently the language of the website can indicate the country targeted.

4. Once the XLS is downloaded and triggered, GetandGo is executed, communicates with the C&C and downloads SDBbot.

2.2. SDBbot Infection Process

1. GetandGo executes the “ReflectiveLoader” export of SDBbot.

2. SDBbot contains of three modules. The Installer, Loader, RAT module.

3.Initially the Installer module is executed, creates a Registry BLOB containing the Loader code and the RAT module.

4. The Loader module is dropped into disk and persistence is maintained via this module.

5. The Loader module, reads the Registry Blob and loads the Loader code. This loader code is executed and Loads the RAT module which is again executed in memory.

6. The RAT module communicates with the C&C and awaits commands from the administrator.

2.3. TA505 Infection Chain

Once SDBbot has obtained persistence, the actor uses this RAT in order to grab information from the machine, prepare the environment and download the next payloads. At this stage, also the operator might kill the bot if it is determined that the victim is not interesting to them.

For further infection of victims and access of administrator accounts, FOX-IT has also observed Tinymet and Cobalt Strike frequently being used.

3. TA505 Packer

To evade antivirus security products and frustrate malware reverse engineering, malware operators leverage encryption and compression via executable packing to protect their malicious code. Malware packers are essentially software programs that either encrypt or compress the original malware binary, thus making it unreadable until it’s placed in memory.

In general, malware packers consist of two components:
• A packed buffer, the actual malicious code
• An “unpacking stub” responsible for unpacking and executing the packed buffer

TA505 also works with a custom packer, however their packer contains two buffers. The initial stub decrypts the first buffer which acts as another unpacking stub. The second unpacking stub subsequently unpacks the second buffer that contains the malicious executable. In addition to their custom packer, TA505 often packs their malware with a second or even a third layer of UPX (a publicly available open-source executable packer).

Below we represent an overview of the TA505 packing routines seen by Fox-IT. In total we can differentiate four different packing routines based on the packing layers and the number of observed samples.

		X64	X86
1	UPX(TA505 Custom Packer(UPX(Malicious Binary)))	0%	0.5%
2	UPX(TA505 Custom Packer(Malicious Binary))	13.7%	0%
3	TA505 Custom Packer(UPX(Malicious Binary))	0%	98.64%
4	TA505 Custom Packer(Malicious Binary)	86.3%	0.86%

To aid our research, a Fox-IT analyst wrote a program dubbed “TAFOF Unpacker” to statically unpack samples packed with the custom TA505 packer.

We observed that the TA505 packed samples had a different Compilation Timestamp than the unpacked samples, and they were correlating correctly with the Campaign Timestamp. Furthermore, samples belonging to the same campaign used the same XOR-Key to unpack the actual malware.

4. Data Research

Over the course of approximately a year, Fox-IT was able to collect TA505 initial XLS samples. Each XLS file contained two embedded DLLs: a x64 and a x86 version of the Get2/GetandGo loader.

Both DLLs are packed with the same packer. However, the XOR-key to decrypt the buffer is different. We have “named” the campaigns we identified based on the combination of those XOR-Keys: x86-XOR-Key:x64-XOR-Key (e.g. campaign 0X50F1:0X1218). All of the timestamps related to the captured samples were converted to UTC. For hashes that existed on VirusTotal we used those timestamps as first seen; for the remainder, the Fox-IT Malware Lab was used.

Find below an overview on the descriptive statistics of both datasets:

4.1. Dataset 1, Working Hours and Workflow routine

During this period, we collected all the XLS files matching our TA505-GetandGo Yara rule and we unpacked them with TAFOF Unpacker. We observed that the compilation timestamps of the packed samples were different from the unpacked ones. Furthermore, the unpacked one was clearly indicating the malspam campaign date.

For the Dataset 1, we used the VirusTotal first seen timestamp as an estimation of when the campaign took place.

In the following graph we plotted all 81 campaigns (XOR-key combinations), and ordered them chronologically based on the C&C domain registration time.

What we noticed was, that we see relatively short orange/yellow/light green patches: meaning that the domain was registered shortly before they compiled the malware, and a few hours/days the first sample of this campaign was found on VirusTotal.

As seen by the graph, it seems clear the workflow followed most of the times by the group: Registering the C&C, compiling the malware and shortly after, releasing the malspam campaign.

As seen on the 37% of the campaigns, the first seen sample and compilation timestamp are observed within 12 hours, while 79% of the campaigns are discovered after 1 day of the compilation timestamp and 91.3% within 2 days.

We can also observe the long vacations taken during the Christmas/New Year period (20th December 2019 until 13th of January 2020), another indication of Russian Cybercrime groups.

The group mostly works on Mondays, Wednesdays and Thursdays, less frequently Tuesdays, Fridays and Sundays (mostly preparing for Monday campaign). As for the time, earliest is usually 6 AM UTC and latest 10 PM UTC. Those time schedules give us once again a small indication about the time zone where the actor is operating from.

4.2. Dataset 2, Working Hours and Workflow routine

For the Dataset 2, we used as a source the first seen date of the InTELL Malware Lab. This dataset contains samples obtained after their time off. In this research we combined SDBbot data as well, which is the next stage payload of Get2. Furthermore, for this second dataset we managed to collect TA505 malspam emails from actual targets/victims indicating the country targeted from the email’s language.

From the above graph we can clearly behold, that multiple GetandGo campaigns were downloading the “same SDBbot” (same C&C). This information makes even more clear the actual use of the short lifespan of a GetandGo C&C, which is to miss the link with the SDBbot C&C (as happened for this research on the 24^th of June). This allows the group for a longer lifespan of the SDBbot C&C, avoiding being easily detected.

The working days are the same since they restarted after their long time off, although now we see a small difference on the working hours, starting as early as 5 AM UTC until 11 PM UTC. This small 1 hour difference from the earliest working time might indicate that the group started “working from home” like the rest of the world during these pandemic times. However as both periods are in respectively winter and summer time, it could also be related to daylight savings time. This combined with the prior knowledge that the group is communicating in Russian language this points specifically to Ukraine being the only majority Russian speaking country with DST, but this would be speculation by itself.

The time information does point however to a likely Eastern European presence of the group, and not all members have to be necessarily in one country.

When we plotted also the SDBbot compilation timestamps we observed that GetandGo is more of a morning/day work for the group as they need to target victims during their working schedule, but SDBbot is performed mostly during the evening, as they don’t need to hurry as much in this case.

5. Dransom Time

“Dransom time, is the period from when a malicious attack enters the network until the ransomware is released.”

Once the initial access is achieved, the group is getting its hands on SDBbot and starts moving laterally in order to obtain root/admin access to the victim company/organization. This process can vary from target to target as well as the duration from initial access (GetandGo) to ransomware (Clop).

The differences on the Dransom time manifests that the group is capable of staying undetected for long periods of time (more than 2 months), as well as getting root access as fast as their time allows (3 days).

* There are definitely more extreme Dransom times accomplished by this group, but the above are some of the ones we encountered and managed to obtain.

6. Working Schedule

With the above data at hand, we were able to accurately estimate the work focus of the group at specific days and times during the past year.

The below week dates are some examples of this data, plotted in a weekly schedule (time in UTC).

* Each color represents a different campaign.

6.1. Week 42, 14-20 of October 2019

During this week, the group released six different campaigns targeting various geographical regions. We observe the group preparing two Monday campaigns on Sunday. And as for Tuesday, they managed to achieve the initial infection at Maastricht University.

On Wednesday, the group performed two campaigns targeting different regions, although this time they used the same C&C domain and the only difference was the URL path (f1610/f1611).

6.2. Week 43, 21-27 of October 2019

Throughout week 43, the group performed three campaigns. First campaign was released on Monday and was partially prepared on Sunday.

As for Wednesday, the group prepared and released a campaign on the same day, which resulted on the initial infection of Antwerp University. For the next three to four days, the group managed to get administrator access, and released Clop ransomware on Saturday of the same week.

6.3. Week 51, 16-22 of December 2019

Week 51 was the last week before their ~20 days “vacation” period where Fox-IT didn’t observe any new campaigns. Last campaign of this week was observed on Thursday.

During those days of “vacations”, the group was mainly off, although they were spotted activating Clop ransomware at Maastricht University and encrypting their network after more than two months since the initial access (week 42).

6.4. Week 2, 6-12 of January 2020

While on week 2 the group didn’t release any campaigns, they were observed preparing the first campaign since their “vacations” on late Sunday, to be later released on Monday of the 3^rd week.

7. Conclusion

The extreme Dransom times demonstrate a highly sophisticated and capable threat actor, able to stay under the radar for long periods of time, as well as quickly achieving administrator access when possible. Their working schedule manifests a well-organized and well-structured group with high motivation, working in a criminal enterprise full days starting early and finishing late at night when needed. The hourly timing information does suggest that the actors are in Eastern Europe and mostly working along a fairly set schedule, with a reasonable possibility that the group resides in Ukraine as the only majority Russian speaking country observing daylight savings time. Since their MO switched after the introduction of Clop ransomware in early 2019, TA505 has been an important threat to all kind of organizations in various sectors across the world.