Threat Alert: Kinsing Malware Attacks Targeting Container Environments

Lately we’ve been witnessing a rise in the number of attacks that target container environments. We’ve been tracking an organized attack campaign that targets misconfigured open Docker Daemon API ports. This persistent campaign has been going on for months, with thousands of attempts taking place nearly on a daily basis. These are the highest numbers we’ve seen in some time, far exceeding what we have witnessed to date. We therefore believe that these attacks are directed by actors with sufficient resources and the infrastructure needed to carry out and sustain such attacks, and that this is not an improvised endeavor.

Update (8/27/23) – Aqua Nautilus discovered a new campaign that exploits the Openfire vulnerability (CVE-2023-32315 to deploy Kinsing malware and a cryptominer.

The following graph shows the volume of attacks by day:

In this attack, the attackers exploit a misconfigured Docker API port to run an Ubuntu container with the kinsing malicious malware, which in turn runs a cryptominer and then attempts to spread the malware to other containers and hosts. Our analysis of this attack vector exposes the techniques used, starting with exploiting the open port, through evasion tactics and lateral movement, all the way up to the end-goal of deploying the cryptominer.

How the Attack is Initiated

Taking advantage of the unprotected open Docker API port, the attackers are able to instantiate an Ubuntu container with the following entry point:

We saw this entry point in every attack in this campaign, with the only change being the IP address that d.sh is downloaded from. We witnessed 3 IP addresses used in total–the one in the example above, 217.12.221.244 and 185.92.74.42

The command does the following:

• Update packages with apt-get update
• Install wget with apt-get
• Start the cron service.
• Download a shell script with the just installed wget
• Run the shell script and read indefinitely from /dev/null to keep the container alive and running

We can see that the wget program was required to download the cron shell script. The script would be later used in order to gain persistency within the container.

Defense Evasion and Persistence

The shell script d.sh, referred to from hereon as ‘the shell script’, contains more than 600 lines. We discovered that the shell script does the following:

1. Disables security measures and clears logs: echo SELINUX=disabled >/etc/selinux/config
2. Kills numerous applications, notably other malwares and cryptominers.
3. Deletes files related to other malwares/cryptominers, most of them from the /tmp directory
4. Kills running rival malicious Docker containers and deletes their image.
5. Downloads the ‘kinsing’ malware and runs it
6. Uses crontab to download and run the shell script every minute
7. Looks for other commands running in cron, and if ones were identified, deletes all cron jobs, including its own. We are not certain why the attackers chose to do so, but that is what the script executes:
   crontab -l | sed ‘/update.sh/d’ | crontab –

Running the Malware

Kinsing is a Linux agent, identified by Virus Total after we submitted it for analysis. From here on we’ll refer to the malware as kinsing.

A quick look at the malware’s strings reveals that it is a Golang-based Linux agent. It uses several Go libraries, including:

• go-resty – an HTTP and REST client library, used to communicate with a Command and Control (C&C) server.
• gopsutil – a process utility library, used for system and processes monitoring.
• osext – extension to the standard ‘os’ package, used to execute binaries.
• diskv – A disk-backed key-value store, for storage.

Running the malware in a controlled environment and monitoring it brought up more details about its malicious actions.

Communication with C&C servers

Before the malware proceeded to deploy its payload, it attempted to communicate with servers in Eastern Europe. It appears that there are dedicated servers for each function that the malware executes:

1. Attempts to establish a connection with the following IP address: 45.10.88.102. The attempts fail as the server does not respond.
2. Connects to 91.215.169.111, which appears to be the main C&C server. The malware communicates with that host over HTTP port 80, and sends small encrypted messages on regular intervals, every few seconds.
3. Connects to 217.12.221.244/spre.sh, which we presume stands for spread, as we will see in the next paragraph, to download a shell script used for lateral movement purposes.
4. Connects to 193.33.87.219 to download the cryptominer C&C communication.

Discovery and Lateral Movement

The spre.sh shell script that the malware downloads is used to laterally spread the malware across the container network.

In order to discover potential targets and locate the information it needs to authenticate against, the script passively collects data from /.ssh/config, .bash_history, /.ssh/known_hosts, and the likes. We did not identify any active scanning techniques used to identify additional targets.

Using the information gathered, the malware then attempts to connect to each host, using every possible user and key combination through SSH, in order to download the aforementioned shell script and run the malware on other hosts or containers in the network.

The actual shell script is named spr.sh this time around, but it is identical to the a d.sh shell script used earlier in the attack sequence

The following SSH command was used to spread it throughout the network:

We noticed a comment in the script for a 20 seconds sleep after every 20 SSH connection attempts, and their cleanup, possibly indicating that the attackers have some sense of evasion and were trying to hide their activities.

Spre.sh script

At the last stage of the attack the malware runs a cryptominer called kdevtmpfsi. The cryptominer was identified by Virus Total as a Bitcoin miner.

The cryptominer connects to a host with the 193.33.87.219 IP address using a log in request over HTTP, receives further instructions, and starts mining cryptocurrency.

Summary

This attack stands out as yet another example of the growing threat to cloud native environments. With deployments becoming larger and container use on the rise, attackers are upping their game and mounting more ambitious attacks, with an increasing level of sophistication.

Here is a summary of the attack components, mapping each component of the attack to the corresponding MITREAtt&ck tactics and techniques category:

We believe that DevSecOps teams must also up their game and become aware of the threats that are lurking in the cloud, and develop a security strategy to mitigate risks. Here’s a list of steps we’d consider making:

1. Identify all cloud resources and group them by some logical structure.
2. Review authorization and authentication policies, basic security policies, and adjust them according to the principle of least privilege.
3. Scan the images that you use, making sure you are familiar with them and their use, using minimal privileges such as avoiding root user and privileged mode. Use Trivy the Open Source vulnerability scanner.
4. Investigate logs, mostly around user actions, look for actions you can’t account for anomalies.
5. Form a security strategy where you can enforce your policies with ease, consider using cloud security tools that will widen your scope and reach within your cloud resources.