An attack campaign dubbed Kinsing that targets cloud-native environments to deploy cryptocurrency mining malware is still going strong after five years, according to a research report by cloud security firm Aqua Security
The threat actors behind the operation compromise publicly facing servers by exploiting remote code execution vulnerabilities and misconfigurations in 75 web applications and container systems such as Docker and Kubernetes.
While Kinsing is not a new attack campaign and security companies have written many detailed analyses about its malware payloads over the past few years, it remains a very active threat against organizations with daily probes for vulnerable applications using an ever-growing list of exploits.
The report found that the number of Kinsing probes against the company’s honeypots has ranged from a few to hundreds per day and that the attackers behind it added five new exploits to their arsenal in just the past three months.
“These attacks varied across specific software types, suggesting that the Kinsing threat actor is continually shifting targets, focusing on particular applications at different times,” the Aqua researchers said. “When new vulnerabilities are disclosed, they naturally become a priority, but they may also gain increased attention months later.”
The Kinsing attack chain employs infection scripts
The modus operandi of the Kinsing attackers hasn’t changed too much in the past five years, which is a testament that it continues to provide an acceptable success rate.
In general terms, after exploiting a vulnerability or misconfiguration, the attackers execute a series of infection scripts that prepare the environment, eliminate competing malware, and deploy a cryptomining program and the Kinsing trojan which is used for remote control. These are usually accompanied by a rootkit that’s meant to hide the files and processes of the other components.
It’s worth noting that Kinsing targets both Windows and Linux/Unix servers so it has different scripts and binaries for both platforms. There are also the exploits that can be left behind as artifacts on the compromised servers.
Aqua breaks down these initial scripts into Type I and Type II. Type I scripts seem to be older and written for sh, the Bourne shell present on Unix systems, while Type II are written for bash (Bourne again shell), a newer version of sh that has an extended set of capabilities. On Windows, researchers have also seen PowerShell scripts being used in some situations.
The number of these scripts varies and their purpose is different. Some look for competing infections to remove them, some perform tasks meant to evade detection, and others are used to set up the next stages of the attack, which involve downloading binaries from so-called download servers that the attackers set up.
12 binaries are dropped with variations of the name Kinsing
The researchers have identified 12 binaries that are dropped during various attacks at different stages. Those with variations of the name “kinsing,” such as kinsing2 or kinsing_aarch64 and one called b, are all variants of the Kingsing malware. Those called xmrig.exe, kdevtmpfsl, x, x2, x_arm, and x2_arm are variants of XMRig, an open-source cryptocurrency mining program configured to mine Monero.
Kinsing samples
“In our work, we tested our database to understand how many samples of Kinsing we had,” the researchers said. “We found 1,550 distinct binaries that bear the name kinsing or kinsing%%%%% (when % is a random digit or letter).”
The good news is that five binaries have been used in over 90% of attacks, with the top sample being seen in over 60% of attacks and the second one in nearly 30%. This could make detection easier to implement.
The Kinsing malware communicates with a command-and-control server that has remained unchanged over the past few years. It will check with the server for new “tasks” provided by the attackers, it will execute them on the system and then provide back the results. It will also set up a SOCKS5 proxy server locally and will periodically check if the XMRig process is running.
The Kinsing rootkit component
Another payload dropped on the system is a rootkit called lib_system.so that is installed in the /etc/libsystem.so directory. The attackers then modify the /etc/ld.so.preload file, which lists the order of libraries loaded into the kernel at reboot to ensure that their rootkit is loaded as early as possible.
The rootkit then hooks various kernel functions in order to hide processes, directories, files and network connections based on a hardcoded list from security and system monitoring tools.
“By hooking these functions, the Kinsing rootkit can effectively control how the operating system interacts with files, directories, and file information,” the researchers said. “This allows the rootkit to hide its presence and the presence of other malware, manipulate file operations and maintain persistence on the infected system. Such manipulations can be very challenging to detect and remove.”
Kinsing targets a long list of applications
Aqua’s report contains a long list of targeted applications for which attackers have exploits or known misconfigurations. Around 70 are open-source software and seven are proprietary. Forty-two can be described as runtime applications, nine are database applications, eight are related to cloud infrastructure, one to code management, one is a CI/CD platform, and one is a security-related application.
The list includes popular technologies like insecure Docker API and Kubernetes deployments, containerd, php, Jenkins, GitLab, Citrix, Magento, Apache Hadoop, the Apache web server, Laravel, Redis, WordPress, PostgreSQL, MongoDB, Atlassian Confluence, Apache Kafka, Apache ActiveMQ, Flink, WeaveScope and many more.
Detection and prevention of Kinsing malware
The Aqua researchers advise organizations to keep themselves up to date with the latest threat intelligence on Kinsing published by security companies as well as with the indicators of compromise, like the ones included in their report.
In addition, companies should regularly update and patch their systems and applications, audit configurations for exposed services, and follow container security best practices and implement container monitoring.
It’s also valuable to deploy monitoring tools that can detect anomalous behaviors such as continuous high CPU and memory usage, unexpected drops in system performance, unusual processes and process names appearing on the system, unexpected outbound network connections and traffic and unexpected changes to files and directories.