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.
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.
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.
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.
Cl0p-ELF Decryption Logic:
Retrieve RC4 “master-key”.
Read all $filename.$clop_extension.
Decrypt with RC4 using the RC4 “master-key”, the generated RC4 key.
Decrypt $filename with RC4 using the generated RC4 key.
Write decrypted to $filename.