New Strain of Sotdas Malware Discovered

Introduction 

There are numerous malicious codes that are currently active on smart devices, such as Ddosf, Dofloo, Gafgyt, MrBlack, Persirai, Sotdas, Tsunami, Triddy, Mirai, Moose, and Satori, among others. These malicious codes and their variants can intrude into and control smart devices through Telnet, SSH, and other remote management services weak password vulnerabilities, operating system vulnerabilities, Web and other application vulnerabilities, and brute force password cracking.  

We will delve into the latest variant of the Sotdas malware, which boasts a range of innovative features and advanced defense evasion techniques. The family of Sotdas written in C++ has been active since many years and it has been characterized by the presence of the strings ‘g_nIsStopDDOS’, ‘DOSSTAT’ or ‘# chkconfi g: 2345 77 37’.  The malware is potentially used to gather information about a compromised system, run in the background undetected, and execute malicious actions. These techniques include setting up a daemon process, creating an init script, monitoring system resources, and gathering language information. 

Executive Summary

The Sotdas malware possesses several capabilities that make it a significant threat in the cyber landscape. 

1. Persistence: It can establish persistence on compromised systems by creating startup entries and copying itself to system directories.  
2. Information gathering: Sotdas can gather valuable system information, such as CPU and memory details, network interface information, and CPU utilization. 
3. Defense evasion: Sotdas exhibits advanced defense evasion techniques by setting up a daemon process, using /proc to determine the absolute path of its executable, and utilizing system V runlevel configuration. 
4. DNS Tunneling: Sotdas employs DNS tunneling for communication with its command and control (C&C) server, utilizing custom DNS query messages and encoding the payload within DNS record. 

Analysis of the sample: 

A. Setting up a Daemon Process and Using /proc to Determine the Absolute Path of the Executable

This Sotdas code written in C++ programming language appears to be setting up a daemon process in Linux using the daemon() function and then passing a string to esi which might be a key or configuration value for the daemonized process. The daemon function allows the malware to run continuously in the background even after the user logs out or the system is rebooted. 

In this case, the code sets nochdir to 1, which means the daemon process will not change its working directory to /, and sets noclose to 0, which means the standard input/output/error streams will be redirected to /dev/null. This is a common pattern in malware to hide its output from the user. 

After setting up the daemon, the code calls the signal() function to register a signal handler for the SIGTERM signal (signal number 0Dh). This allows the process to handle the signal gracefully and perform any necessary cleanup before terminating. 

In Linux, /proc is a virtual filesystem that provides information about running processes and system resources. The /proc/self directory refers to the current process, while /proc/self/exe is a symbolic link to the executable file of the current process. 

In the given code snippet, the readlink() system call is used to read the contents of the /proc/self/exe symbolic link into a buffer pointed to by the path variable. This is done in order to determine the absolute path of the executable file of the current process. 

Knowing the absolute path of the executable file can be useful in many situations, such as for identifying the location of the binary on disk, for determining the working directory of the process, or for accessing other files that are located in the same directory as the executable. 

B. Setting up System V runlevel 

The malware is attempting to create a file containing this shell script and then execute it. The first line specifies that the script should be interpreted by the Bash shell. The second line sets up the daemon to run on runlevels 2, 3, 4, and 5, with a start priority of 77 and a stop priority of 37. The third line provides a description of the daemon process. The fourth line sets up the daemon to run in the background using the setsid command.  

C. Setting Up Init script and Symlink 

the malware code starts by generating a random string of 16 characters, which will be used as a filename for a file that will be created later. The string “rm -f %s” creates a command that will remove any existing file with the same name as the generated filename. The command is executed using the system() function. The code then creates a new file with the generated filename using the fwrite() function. 

The malware code appears to be searching for a specific string (“fsb0h`nfnpc”) in the file system, possibly to identify a specific system to infect. If the string is found, the code executes the following command: “echo yes|cp -p %s %s”, where the first “%s” is the name of the file created earlier and the second “%s” is a path where the file should be copied. The code then waits for 2 seconds using the sleep() function. The code sets the permissions of the copied file to 777 using the “chmod 777 %s” command. 

It then creates a symbolic link to the copied file in several directories under "/etc/rc*.d/", which appear to be startup directories for different runlevels in the system. The malware creates symbolic links in the /etc/rc2.d, /etc/rc3.d, /etc/rc4.d, and /etc/rc5.d directories, as well as starting a service using the “service” command and an init.d script.  

Later, starts a service using sprintf() to create a command string with the format “service %s start”, where “vin`nh” is the argument to be started. 

D. Parsing /proc/net/dev to Extract Network Interface Information

The snapshot describes the parsing of /proc/net/dev: 

• grep “\beth” /proc/net/dev: Filters the output of /proc/net/dev to only include lines that contain the word “eth”. This will typically include the network usage statistics for Ethernet interfaces. 
• cut -d “:” -f 2: Uses the cut command to extract the second field of each line, using a colon as the delimiter. This will remove the interface name from the output. 
• awk ‘{print $27}’: Uses the awk command to extract the 27th field of each line and print it to the console. This will typically be the number of bytes received on the Ethernet interface. 

By parsing the output of /proc/net/dev, the malware could extract information about the network interfaces on the compromised system and the amount of data being transmitted and received on those interfaces. This information could be useful for monitoring the user’s internet activity. 

E. Monitoring CPU Utilization  

top -bn 1 | grep Cpu | cut -d "," -f 1 | cut -d ":" -f 2

The malware runs the top command to print out a snapshot of the current system resource usage, including CPU utilization. This can be useful for monitoring system performance. The malware can ensure that it does not consume too many resources, which could alert the user or system administrator.  

F. System Information Gathering Commands for Malware: CPU and Memory

grep “processor” /proc/cpuinfo | sort -u | wc -l 

This command will output the number of logical CPU cores in the system. It could potentially be used by malware to gather information about the system’s hardware configuration or to optimize its own resource usage based on the number of available CPU cores 

grep “cpu MHz” /proc/cpuinfo | cut -d “:” -f 2 

This command will output the clock speed (in megahertz) for each logical CPU core in the system. However, it could potentially be used by malware to gather information about the system’s hardware configuration or to optimize its own resource usage based on the available CPU clock speeds. 

grep “MemTotal” /proc/meminfo | cut -d “:” -f 2 

This command will output the total amount of physical memory installed in the system, in kilobytes. Gathering system information such as CPU and memory details can help the malware identify the capabilities of the target system, which could inform its behavior and actions. 

G. Network Analysis 

The Sotdas malware payload made a DNS query for the domain “a77jdsadsa98wqefav.sockt.best”. The query is for an A record (type A, class IN) and is directed to the DNS server at ns0.centralnic.net. 

The DNS query message is encoded in the payload of the packet, starting at byte offset 42. The message is a standard DNS query message with a single question section. The question section contains the hostname and the query type and class. However, the payload of the DNS query contains a long string of random characters, which is not typical for a legitimate DNS query.  

The payload uses a custom implementation of DNS tunneling and sends across the output to the C2 server via DNS query in the form of A records in multiple blocks of queries, where the A record values consists of the encoded command output. The size of a DNS record is limited, so a typical communication between the payload and the C&C server consists of a series of DNS requests and replies, with the command or file transmitted in chunks. To keep track of such a pseudo-connection, both client- and server-side requests have embedded type and transmission ID. 

H. Eliminating Traces 

The malware performs a series of commands related to removing files. It starts by pushing the rbx register onto the stack and then sets eax to 0. The function then uses the sprintf function to create several commands that remove files: 

m command for deleting malware traces 

• rm -f /etc/rc2.d/S77%s 
• rm -f /etc/rc3.d/S77%s 
• rm -f /etc/rc4.d/S77%s 
• rm -f /etc/rc5.d/S77%s 
• rm -f /etc/init.d/%s 
• rm -f %s 

The %s in each command appears to be a placeholder that is later replaced with the string “vinnh”. After creating each command with sprintf, the function uses the system` function to execute the command. Finally, the function cleans up the stack and returns. 

Conclusion 

Once Sotdas malware has achieved persistence and gathered information about the system’s CPU and memory. The malware can use this information to optimize its own resource usage and to start cryptomining. The malware could potentially use all available CPU resources to maximize its mining performance, while also monitoring the system’s CPU utilization to avoid detection. 

Once the malware has established a cryptomining operation, it can continue to monitor the system’s CPU utilization to ensure that it remains undetected and to adjust its resource usage as needed. It may also periodically check the system’s memory usage to ensure that it has enough available memory to continue mining.  

Detections

1. Qualys Multivector EDR can easily scan and detect Sotdas malware since the platform is armed with advanced detections.  

2. Sotdas malware copies itself to directories under init.d and rc.d to establish persistence

3. Sotdas deleted its files and components from a compromised host using rm command

Hashes

• MD5: 31d5a627bcc63682c43e6e8c785c4d57 
• SHA-1: 019baa5eeec142d143fce17694c47bc40ce3122d 
• SHA-256: f7a8eb6dda1d15bead43d94df0bcfdd2a7dccab0eb06c89e5e85034561f60563 
• File name: .iamgood 

Domain 

• sockt.best 

Directories

• /etc/rc2.d/  
• /etc/rc3.d/  
• /etc/rc4.d/ 
• /etc/rc5.d/
• /etc/init.d 
• /tmp/ 

MITRE ATT&CK Techniques

• T1037.004 – Boot or Logon Initialization Scripts: RC Scripts
• T1543.002 – Create or Modify System Process: Systemd Service 
• T1036 – Masquerading: Match Legitimate Name or Location 
• T1070.004 – Indicator Removal: File Deletion 
• T1222 – File and Directory Permissions Modification 
• T1564.001 – Hide Artifacts: Hidden Files and Directories 
• T1082 – System Information Discovery 
• T1057 – Process Discovery 
• T1071.004 – Application Layer Protocol: DNS