Analysis of Kinsing Malware's Use of Rootkit
Several shell scripts accompany Kinsing. These shell scripts are responsible for downloading and installing, removing, and uninstalling various resource-intensive services and processes. This blog post focuses on the role of the rootkit component.
We last discussed the Kinsing malware in April 2020, when we analysed the Golang-based Linux agent targeting misconfigured Docker Daemon API ports to drop cryptocurrency miners.
With the constant evolution of shell scripts and Linux based malicious backdoors and agents, it’s not surprising that the creators of Kinsing have kept in step. In this entry, we discuss the malware variant’s current capabilities, including the addition of features intended to make it more difficult to detect in infected machines. Similar to how the Trident malware uses a rootkit to hide the cryptocurrency mining payload, Kinsing also adapted the method integrating user-mode rootkits that use library preloading.
Several shell scripts accompany the malware itself. These shell scripts are responsible for downloading and installing the Kinsing backdoor, miner, and rootkit, as well as removing and uninstalling various resource-intensive services and processes. These scripts are similar to those discussed in the entries mentioned above. This blog post will focus on the rootkit component.
The first step of the process involves the deployment of the shell script trying to remove the immutable file flag from /etc/ld.so.preload if it exists.
The /etc/ld.so.preload file preloads a list of paths to shared objects or libraries that will be loaded into every user-mode process on startup before any other shared library — including the C runtime library (libc.so). By default, this file is not present inside Linux distributions; therefore, it has to be created on purpose.
Next, the downloader downloads the rootkit into /etc/libsystem.so, after which a new /etc/ld.so.preload is created. The link to the rootkit is then added to the /etc/ld.so.preload file.
Note that removing from or writing files into the /etc/ directory is a privileged operation; therefore, it is highly recommended to follow the principle of least privilege and not run applications or containers under root permissions.
The Kinsing malware also works under lower privileges but without its advanced persistence and rootkit functions.
User-level persistence of the downloaded Kinsing malware is achieved by registering it as the system service called “bot.”
Another level of persistence is achieved via cron, where the installation script is repeatedly downloaded and executed.
The rootkit contains the list of hidden literals and the list of non-hooked symbols (native functions that will be hooked, but they need their original addresses to be resolved and saved for later use). These lists are encrypted by a single-byte XOR.
The functions hooked by the rootkit are as follows:
The rootkit implements the following functions:
This is used to determine if the attacker calls the process by checking the presence of the environment variable called SKL.
If the file names are kinsing (backdoor & worm process), kdevtmpfsi (cryptomining process), or lib_system.so (rootkit), it returns the code EPERM = Operation not permitted.
While looking into the /proc/ directory, the rootkit searches for the environment file in the directory of the process and variable SKL to decide if the said directory should be hidden or not.
Used to parse files in /proc/net/tcp or /proc/net/tcp6, which maintain the lists of the currently active TCP connections. It extracts remote IP addresses and compares them with hidden literals. If there is a match, information about the TCP connection is hidden from the listing.
If the attacker executes the process (SKL environment variable is set for the process calling readdir function), then readdir works with no restrictions.
If the current directory is /proc and the process name is kinsing or kdevtmpfsi, the directory item is omitted from the directory listing. If it is '.' or a hidden file (kinsing, kdevtmpfsi, lib_system.so), then it omits these files.
For other hooked functions, the process that the attacker runs is allowed to invoke all operations without limitation. For other processes (not run by attacker), it returns an ENOENT = No such file or directory error code if a hidden file is accessed.
Further searching revealed that the threat actor reuses the publicly available beurk rootkit, but with several custom modifications.
Kinsing is still highly active and continually evolving. Adding the rootkit component hides the presence of malicious components in the infected system. Reusing publicly available source codes presents a popular option for malicious actors, giving them an easier way to add new functions to their malware.
Indicators of Compromise (IOCs)
|Hash (SHA-256)||Detection name|
C&C IP addresses: