Threat Research Report Team

Cyclops Ransomware and Stealer Combo: Exploring a Dual Threat

Written by Uptycs Threat Research | Jun 5, 2023 12:00:00 PM

In our ongoing efforts to monitor and identify emerging threats on the dark web, the Uptycs threat research team has recently uncovered a new and alarming threat. Last time, we came across the notorious RTM Locker ransomware. This time we’ve stumbled upon a new actor known as the Cyclops threat group. 

The Cyclops group is particularly proud of having created ransomware capable of infecting all three major platforms: Windows, Linux, and macOS. In an unprecedented move, it has also shared a separate binary specifically geared to steal sensitive data, such as an infected computer name and a number of processes. The latter targets specific files in both Windows and Linux.

Threat Attribution

Uptycs threat intelligence actively monitors the dark web, where we recently encountered a new ransomware-as-a-service (RaaS) provider. In addition to offering ransomware services, this entity also supplies a separate binary for stealing purposes. 

The threat actor behind this RaaS promotes its offering on forums. There it requests a share of profits from those engaging in malicious activities using its malware.

Fig. 1 - Cyclops admin post

 

The threat developer provides a separate panel to facilitate distribution of its ransomware for the aforementioned three operating systems. 

 

Within the same panel are distinct binaries available for the ancillary stealer component that is tailored specifically for Linux and Windows.

Fig. 2 - Cyclops admin panel

 

Acting as a sort of bank, the website includes a financial section, offering a Cyclops attacker the ability to initiate a withdrawal of paid-up ransom amounts.

Fig. 3 - Cyclops payment panel

 

The threat developers are able to promptly address real-time issues and to provide rewards for valuable suggestions.

Ransomware Binary Analysis

Windows

After extracting the downloaded archive file obtained from the panel, Uptycs discovered the presence of the builder binary and a readme.txt file. Additionally, the threat actor has privately shared a builder ID for creating a ransom payload named locker.exe. 

Fig. 4 - Generating ransom payload

 

This payload is specifically designed to infect both local and networked machines. The accompanying text file contains payload execution instructions—both with and without command line arguments.

Fig. 5 - Ransom payload execution command line

 

The Cyclops ransomware payload is a compiled executable binary specifically aimed for x64-bit architecture using the VC++ compiler.

The payload scans and identifies processes running on victims’ machines, immediately terminating any process that could hinder encryption of targeted files it intends to hold hostage.

 

Such processes include:

xfssvccon.exe synctime.exe ocomm.exe excel.exe
wordpad.exe steam.exe ocautoupds.exe

svc.exe

visio.exe sql.exe notepad.exe dbeng50.exe
thunderbird.exe powerpnt.exe mspub.exe dbsnmp.exe
tbirdconfig.exe outlook.exe msaccess.exe agntsvc.exe
thebat.exe onenote.exe vmms.exe TeamViewer.exe
vmwp.exe oracle.exe vc.exe Mydesktopservice.exe
ig.exe ocssd.exe firefox.exe sqbcoreservice.exe

Fig. 6 - Termination process list

 

The payload uses the GetLogicalDriveStrings API to retrieve system logical drive information.

Fig. 7 - Get logical drive information

 

After obtaining drive letters, it enumerates the folders and drops a ransom note file named, How To Restore Your Files.txt on the disk. Before encrypting any given file, the payload checks if its file extension matches a predefined list (figure 8). If not, the file gets encrypted and a .CYCLOPS extension is appended, e.g., LICENSE.txt.CYCLOPS.

Fig. 8 - Exclude file extension list

 

An attacker obtains shadow copy details from a victim system by executing a SELECT * FROM Win32_ShadowCopy query. Query output includes information such as each shadow copy ID, creation time, volume name, and other relevant details.

Next the payload initiates deletion of a specific shadow copy identified by its ID; it does so by executing the Windows Management Instrumentation command line (WMIC) utility via a command prompt.

Delete shadow copy command

cmd.exe /c C:\Windows\System32\wbem\WMIC.exe shadow copy where "ID='{<ID>}'" delete

Ransom note

 

The ransom note message points to an Onion site where a victim can visit to potentially recover their encrypted files.


Fig. 9 - Ransom note

Linux

The Linux binary is a Golang-compiled file, where its function names are stripped to make reverse engineering difficult. It’s CGO-based, where the source code is written in C and built on Golang. 

On executing the sample, it provides options to encrypt files in a specific path, virtual machines, or enable verbose output as shown in Figure 10.

Fig. 10 - Linux ransomware arguments

Excluded encryption files and folders

 

Files present in /proc and /boot are not encrypted. Rather, it encrypts files having extensions .vmcx, .vmdk, .vmem, .vmrs, .vmsd, .vmsn, .txt, .csv ,.lock, .pdb, .csv and many others.

And it drops a ransom note in every folder it encrypts.

Fig. 11 - Linux ransomware note

 

After encrypting all the files it then generates a report of statistics related to found files, encrypted files, encrypted error files, time, et al.

Fig. 12 - Report of Cyclops ransomware (Linux) after encryption

Encryption Logic of Windows and Linux

The encryption is complex; all functions statically implemented using a combination of asymmetric and symmetric encryptions. Here is a look at the encryption procedure.

  • There is a call to CryptAcquireContext to acquire the handle of a particular key container within CSP.
  • Cryptgenrandom is then called to fill a buffer with a cryptographically random 32 bytes, the handle obtained in step1 being  passed as a parameter. (In Linux, the crypto_rand_batched Golang library highlighted in figure 14 is used to generate 32 random bytes.)

Fig. 13 - Random number generation in Windows

Fig. 14 - Random number generation in Linux



  • The random bytes are used as a private key during the ECDH algorithm on Curve25519.
  • The private key is now used to generate the public key through Curve25519, which is appended at the end of the encrypted file.
  • A shared key/session key in ECDH is now generated through Curve25519, using the private key from step 2 and the attacker's public key hardcoded in the file. In Windows, Curve25519 encryption is statically  implemented, making reverse engineering difficult. Golang library Curve25519 is used in Linux.

Fig. 15 - Curve25519 implementation in Windows


Fig. 16 - Curve25519 ECDH public key (Windows)

Fig. 17 - Curve25519 call in Linux

 

  • The generated shared/session key SHA512 hash is calculated and used during symmetric encryption. It’s statically implemented, with all file constants being hardcoded.

Fig. 18 - SHA512 implementation in Windows

  • The CRC32 of the SHA512 hash is computed and appended at the end of the encrypted file. The CRC32 function is also statically implemented with all constants contained within the file.

Fig. 19 - Hardcoded CRC32 constants in Windows file


  • The symmetric encryption used here is HC-256 (a stream cipher). It takes the first 32 bytes of generated SHA512 as a key and the next 32 bytes of generated 512 as the initialization vector (IV). Figure 20 shows how the key and IV are expanded to a 2560-word (0xA00) array.

Fig. 20 - HC-256 algorithm implementation in Windows


  • Linux symmetric encryption uses ChaCha, where the key and IV are derived from the generated shared/session key SHA512 hash.

Fig. 21 - ChaCha implementation in Linux

 

  • After encryption in both Windows and Linux using the public key, CRC32 and a file marker are appended to the end of the file. Used to identify if the file has already been encrypted (so as not to repeat encryption), the Linux file marker is 00ABCDEF, whereas in Windows it’s 000000000000000000000000.

Linux:

Fig. 22 - Encrypted file contents in Linux

Windows:

Fig. 23 - Encrypted file contents in Windows

 

macOS

The hash is a Golang-compiled file (same as the Linux variant) and is in the form of a mach-O binary (figure 24).

Fig. 24 - mach-0 binary information

 

On executing our sample, it provided options to encrypt files in a specific path, virtual machines, or enable verbose output (figure 25).

Fig. 25 - Ransom execution command

 

The option chosen for ransom execution places encrypted files in a designated folder, accompanied by ransom note (How to Restore Your Files.txt) (figure 26).

Fig. 26 - Ransom encrypted folder

 

Stealer Binary

Windows stealer

This stealer can be downloaded from the aforementioned master Cyclops panel (figure 2). After extracting the downloaded archive file, we obtained two files: stealer.exe and config.json.

The stealer is an executable binary for x64 systems that extracts system information from targeted machines.

 

OS details Computer name Number of processes Logon server

Following that, the stealer reads its config.json file located in the same directory as its execution. It contains a list of filenames along with corresponding extensions and sizes.

Fig. 27 - Config.json file

 

Next the stealer scrutinizes the \system32 directory for the existence of unidentified files, (characterized by randomly generated and excessively long filenames).

Fig. 28 - Checking for random files in \system32 folder

 

The stealer then enumerates directories and checks for the presence of targeted files and specific file extensions. If any matches are found, it creates a new, password-protected zip file (zip file name-n.zip) that includes an exact copy of the identified file along with its corresponding folder tree structure. The data is then exfiltrated to the attacker’s server.

Fig. 29 - Collected victim files in temp folder

 

The zip file name-n.zip contains illicitly obtained files from victims’ machines.

Fig. 30 - Inside a zip file

 

Linux stealer

This stealer is also obtained from the master Cyclops panel (figure 2). Upon extracting the archive file obtained from the panel, we again discovered two files: stealer.linux and config.json. This stealer functionality is similar to the Windows stealer, with both being Golang-compiled. It starts by reading config.json located in the same directory as its execution. This file contains a filename list along with their corresponding extensions and sizes.

Fig. 31 - Configuration file - Linux

 

The stealer enumerates directories and checks for the presence of targeted files and specific file extensions mentioned in the JSON file. If matches are found, it creates a new, password-protected zip file (zip file name-n.zip) that includes an exact copy of the identified file along with its corresponding folder tree structure inside a /tmp directory.

 

It then uploads the zip files:

 

https[:]//api[.]bayfiles[.]com/upload

https[:]//api[.]anonfiles[.]com/upload

 

The Uptycs team is still working on the stealer component and will be updating our blog as we get more information.

 

Similarities with Babuk and Lockbit ransomware

  • Cyclops ransomware encryption logic shares similarities with Babuk ransomware. Like Cyclops, the latter also used Curve25519 and HC-256 for Windows encryption. And again like Cyclops, Babuk uses the combination of Curve25519 and ChaCha.
  • Executable strings are encoded and stored as a stack string in the Cyclops ransomware. To use these strings, they’re dynamically decoded through computations that involve addition, subtraction, shifting, XORing, et al. Such encoding was similarly observed in Lockbit v2.

Fig. 32 - Stack string obfuscation in Cyclops ransomware

 

Fig. 33 - Stack string obfuscation in Lockbit v2 ransomware

 

Uptycs Detection

Given that our platform is armed with YARA process scanning and advanced detections, Uptycs XDR clients can easily scan for Linux and Macintosh ransomware.

Fig. 34 - Uptycs detection - macOS/Linux

 

Not to be left out, the Uptycs product is also equipped with specialized alert detection for Windows ransomware.

Fig. 35 - Uptycs detection - Windows

Query to scan for malicious stealers

The following query scans a temporary location to identify a stealer. However, there is no guarantee that a stealer will be present in the sample location shown. Therefore, you should scan any suspicious files based on your own system location.

Query – Windows:

select * from yara where count > 0 and path like 'C:\Users\%\AppData\Local\Temp\%%' and rule = 'rule Uptycs_Infostealer_Cyclops_windows

{

meta:

     malware_name = "Infostealer"

     description = "Infostealers are malwares that can steal credentials from browsers, FTP clients, email clients etc from victim machines."

     author = "Uptycs Inc"

     version = "1"



strings:    

     $string_0 = {0F B6 B4 18 EA 01 00 00 40 C0 EE 04 40 0F B6 F6 48 8D 3D ?? ?? ?? 00 0F B6 34 37 0F 1F 00 48 81 FA 0B 02 00 00 0F 83 ?? ?? 00 00}

     $string_1 = {44 0F B6 84 18 EA 01 00 00 41 83 E0 0F 41 0F B6 3C 38 48 81 FE 0B 02 00 00 72 95}

     $string_2 = {FF D0 48 81 C4 50 01 00 00 59}

     $string_3 = "GetSystemInfo" ascii wide

     $string_4 = "GetProcessAffinityMask" ascii wide

     $string_5 = "GetEnvironmentStrings" ascii wide

     $string_6 = "GetConsoleMode" ascii wide

     $string_7 = "math.Vr8NUS" ascii wide

     $string_8 = "json:\"status\"" ascii wide



condition:

     all of them

}'

 

Query - Linux:

select * from yara where count > 0 and path like '/tmp' and rule = 'rule Uptycs_Infostealer_Cyclops 
{
 meta:
 malware_name = "Infostealer"
 description = "Infostealers are malwares that can steal credentials from browsers, FTP clients, email clients etc from victim machines."
 author = "Uptycs Inc"
 version = "1"


                // All are moving patterns


 strings:
 $Infostealer_Cyclops_0 = {48 81 EC B0 00 00 00 48 89 AC 24 A8 00 00 00 48 8D AC 24 A8 00 00 00 48 BA 2F 70 DC 38 93 99 77 CB 48 89 54 24 6C 48 BA D8 1F 8E E2 21 03 59 E8 48 89 54 24 74 48 BA 21 03 59 E8 CB 81 2D E4 48 89 54 24 78 48 BA E6 FC 0D 2D D9 82 66 1D 48 89 94 24 80 00 00 00}
 $Infostealer_Cyclops_1 = {48 BA 46 87 69 74 E3 8F F8 08 48 89 94 24 88 00 00 00 48 BA 73 62 58 40 B0 D3 FC 18 48 89 94 24 90 00 00 00 48 BA 57 FA 61 40 F0 D4 0D 2B 48 89 94 24 98 00 00 00 48 BA 36 0F 3B 23 74 94 3E B3 48 89 94 24 A0 00 00 00 44 0F 11}
 $Infostealer_Cyclops_2 = {48 BA 64 42 44 53 31 6E 75 39 48 89 54 24 34 48 BA 2D 6F 3E 20 2C 2C 39 72 48 89 54 24 3C 48 BA 2C 2C 39 72 65 00 37 46}
 $Infostealer_Cyclops_3 = {48 BA 6D 75 73 71 7A 6F 4C 20 48 89 54 24 1E 48 BA 73 6F 6F 20 72 6F 47 7F 48 89 54 24 26 48 BA 04 01 0F 01 05 08 05 03}
 $Infostealer_Cyclops_4 = {49 3B 66 10 0F 86 EC 00 00 00 48 83 EC 50 48 89 6C 24 48 48 8D 6C 24 48 48 BA 73 54 74 75 63 74 75 7F 48 89 54 24 30 48 BA DF 20 6E F2 65 64 01 EB 48 89 54 24 38 48 BA CF 6C FE 49 06 CB F7 3C 48 89 54 24 40 48 BA 08 02 15 17 08 01 0F 01 48}




 condition:
 all of ($Infostealer_Cyclops*)
}’

 

Conclusion & Precautions

  • Promoting user awareness and education is crucial in preventing successful attacks. Users should exercise caution when handling email attachments, visiting suspicious websites, or downloading files from untrusted sources. Implementing robust email filtering and providing education on phishing techniques can effectively mitigate such risks.
  • Perform regular backups of critical data to mitigate the impact of ransomware attacks. Your backups should be securely stored and periodically tested to ensure data integrity and availability.
  • Regularly updating your security software and conducting system scans can help detect and prevent such threats.
  • Transmission of stolen data to an attacker's server highlights the importance of network monitoring and intrusion detection systems (IDS). Organizations should invest in robust network security measures to identify and block suspicious outbound traffic.
  • Organizations should prioritize implementing multi-factor authentication (MFA) for critical systems and sensitive data access. MFA adds an extra layer of security, making it more challenging for attackers to gain unauthorized access by requiring additional authentication factors.