Threat Research
Stay on top of the latest threat research, information on in-the-wild cyber attacks and cyber operations from Juniper Threat Labs.
Juniper Employee , Juniper Employee Juniper Employee
Threat Research
Container Malware: Miners Go Docker Hunting In The Cloud
Nov 15, 2018

 

Authors:  Anoop Saldanha, Alex Burt, Abhijit Mohanta

 

docker_sad.png

 

 

 

The advent of microservices has led to us witnessing containers take the cloud by storm. But, this boom in the container-cloud relationship is exposing security issues that are inviting malware into the party as well.

 

Juniper Threat Labs recently discovered an infection in the wild that hunts for misconfigured publicly exposed Docker services in the cloud and infects them with containers that run Monero miners.

 

Infection Entry

 

Docker provides REST APIs for management of its service, including the ability to create and start/stop containers. By default, Docker only enables Unix socket access to its REST APIs. To enable remote access to the Docker service’s REST APIs, one has to configure Docker to listen on TCP ports. The conventional ports used by Docker are 2375 and 2376 which, when enabled, would by default provide unencrypted and unauthenticated access to the docker REST APIs.

 

The infection we discovered spreads across hosts using misconfigured or loosely configured Docker services that expose its REST Management APIs through open and unauthenticated TCP ports 2375 and 2376 on the internet. Each new infection continues to spread the infection to other new hosts by scanning for the presence of other misconfigured Docker hosts on the network, effectively making it a worming capability.

 

A general overview of the infection is provided in the diagram below.

 

infection_overview_0X.png

 

The entire infection chain is largely script based and lives off the land, making use of well-known, system-provided utilities to spread the infection and carry out its activities. Some of the system utilities that it uses are Docker, Wget, cURL, Bash, iproute2, MASSCAN, apt-get, yum, up2date, pacman, dpkg-query, systemd, etc.

 

Below is a screenshot of a Docker host instance being infected through its REST APIs on its daemon service’s default port 2375.

 

infection_01.png

 

As seen above, the Docker daemon is requested to start a container and execute certain commands. The commands executed inside the container include instructions to download a script called “auto.sh” that is hosted on a remote server using “wget”.

 

The script “auto.sh” is the start point and platform for the infection. It bootstraps the container execution environment for the infection and also acts as a base to run other scripts to further scan for other Docker hosts and spread the infection.

 

The anatomy of the code flow is briefly described by the below diagram.

 

infection_00.png

 

 

Bootstrapping


In the first stage of the entry script, “auto.sh”, it checks for the presence of certain packages: cURL, iproute2, openssh-server, openssh-clients and MASSCAN. If the packages are not found, it downloads and installs them using either apt-get, yum, up2date or pacman.

 

infection_02.png

 

In the second stage of the “auto.sh” script, it creates new users and sets up SSH Access for these new users.

 

infection_03_01.pnginfection_03_02.png

 

 

Mining

 

In the third stage of the “auto.sh” script, it downloads MoneroOcean’s Monero miner bash script hosted on Pastebin and executes it. The downloaded script is pretty much the stock version straight from MoneroOcean’s Github account. It download’s XMRig’s miner from the Github account and runs it as a systemd service.

 

infection_04.png

 

 

Discovery: Port Scanning for NEW Docker Hosts to Infect

 

In the fourth stage of the auto.sh script, it uses masscan to port-scan the network subnets connected to the infected host. It scans for hosts running docker daemon with open TCP ports 2375 and 2376, and dumps to a local file, local.txt, the list of new host IP addresses to infect.  Masscan is a publicly available port scanner tool.

 

infection_05.ping.png

 

 

Spreading The Infection

 

In this stage it first downloads two more scripts, test3.sh and test.sh, both of which are primarily tasked to spread the infection.

 

infection_06.png

 

Auto.sh spawns the script test3.sh, passing it to local.txt (previous section) as the input. “test3.sh” loops through each IP address in local.txt and spawns test.sh feeding it each IP address as the argument. “test.sh” utilizes Docker’s very own client tool to connect to the remote host’s Docker service to spread the infection to the IP address passed to it as the argument, thereby expanding its infection footprint.

 

infection_07.png

 

 

There’s More

 

Going back to the infection scripts, they are hosted on a remote server identified by IP address 42.159.203.16.  The contents of this server shown below.

 

infection_server.png

 

The contents of this server shows all the script files as well as the presence of three more files: xm, it’s config file data.cfg and it’s corresponding systemd file xm.service.


“xm” is an ELF linux binary, identified as a CoinMiner in VirusTotal by other AV vendors.

 

vt_elf.png

 

 

The data.cfg config file fed to xm miner binary holds the same Wallet address used as a part of this infection - 4Aotje6mGNPRcDQeqS7iUwRLGJhLLgJvfbS6Dju5peSACbVXTFhnds53xuoqif3JEcfbdjiW27xuAJiiKeiCGbuoACrutNE

 

Please note that this above ELF binary is not downloaded as a part of this infection and that  MoneroOcean’s Monero Miner script in this infection directly downloads Xmrig from Github and runs it to mine Monero.

 

Juniper Networks Sky ATP detects it as a cryptominer:

 

skyatp_detection_docker_monero.png

 

IOCs

 

42.159.203.16

d2880de55b232d26740c1ba0d0621ac44066fd4be250c05ecccf5479f972fa01

b33b66aa3e482e1a02344f7499e6a42ac9447d26efa286f16c63d8b5b5987fe0

d21d49a0fffe5d5c1446492ffb0c96b0d31286454b6092b7fb3a104b8c29b660

 

Conclusion

 

Cloud and containers are growing exponentially, but the exposure of services to the public internet has shown us that tons of services are misconfigured or loosely configured, leaving them vulnerable to be exploited by malicious parties.

 

In the same realm, misconfigured Docker services on the cloud are inviting cryptominers to utilize the vast computing resources of the cloud. But, it doesn’t have to stop there for these malicious actors. Apart from the availability of the massive computing power, the short-lived nature of containers means malicious parties can use containers to create temporary and effective attack points in their infection chain. Imagine a botnet that brings up containers running their bot on-demand, runs a DDoS and then shuts down the container, thereby reducing the footprint of its presence.

 

Correctly configuring network-facing services, instilling authenticated access to exposed ports and opening TCP ports only if necessary can alleviate some of these concerns.

 

 

 

 

 

 

 

 

 

 

Top Kudoed Authors