When Malware Abused Docker
When Malware Abused Docker
A round-up of malware incidents involving Docker and what organizations can do to protect themselves.
Join the DZone community and get the full member experience.Join For Free
Malware actors are increasingly setting their sights on Docker. Docker, as a PaaS platform, enables OS, firmware, and apps to run within a container. This enclosed environment benefits developers when they’re looking to try out code. However, it also grants nefarious individuals a way to spawn a malware infection within an organization.
It’s therefore no surprise that malicious actors have abused Docker containers over the past several years. Here are just a few malware incidents that stand out.
In October 2018, Trend Micro observed digital attackers capitalizing on Docker API ports that were open to external access. The malicious actors abused those API ports to create containers and run commands on the compromised Docker instances. Through this chain of commands, the attackers ran the script “auto.sh.”
This asset turned out to be a new Monero crypto-mining malware that Trend Micro detected as “Coinminer.SH.MALXMR.ATNE.” After gaining persistence, the script established its dominance over the infected machine by killing any other Monero-mining processes. It the scanned the network for open ports 2375/TCP and 2376/TCP, both of which are employed by the Docker engine daemon (dockerd). The malware then spread throughout the network to broaden the scope of its infection.
Trend Micro examined the logs of its honeypots in March 2019. Set up to detect attacks targeting the container platform, the honeypots registered attack attempts that capitalized on the exposed Docker Control API. Specifically, the malicious actors created their Docker host environment and leveraged a command to deploy a container remotely.
They then found an image and deployed it to the victim’s Docker host. Not only that, but the attack chain also involved the abuse of the ngrok tool. This attack enabled malicious actors to dynamically create URLs for when two payloads reached an exposed host. The first payload leveraged in this campaign was “Coinminer.SH.MALXMR.ATNO,” a cryptocurrency miner that connected the infected machine to a mining pool. The second payload was “TrojanSpy.SH.ZNETMAP.A,” a solution which helped the malware scan the network for new targets.
AESDDoS Botnet Malware
Later in the spring of 2019, Trend Micro detected another attack type that abused a Docker API misconfiguration — external access to API ports. This error helped facilitate the efforts of malicious actors to scan for entry points on ports that communicate with the Docker daemon. Upon discovering an open port, the digital attackers used it to establish a connection for running containers. They then used Docker.exe to deploy AESDDoS botnet malware. This threat empowered a malicious attacker to launch multiple types of distributed denial-of-service (DDoS) attacks including SYN, UDP and TCP flood campaigns.
Graboid Cryptojacking Worm
Palo Alto Networks’ Unit 42 researchers spotted a new cryptojacking worm called “Graboid” in October 2019. At the time of discovery, Graboid was the first crypojacking worm that spread to more than 2,000 unsecured Docker hosts using the Docker Engine (Community Edition). The attack began when nefarious individuals established an initial foothold through unsecured Docker daemons.
It’s then that the campaign’s command-and-control (C&C) servers downloaded Graboid for the purpose of mining for Monero. This malware also periodically sought out new hosts from its C&C in order to choose new targets. In their analysis, Unit 42 witnessed Graboid chose three targets at each iteration and cycled its mining activity across them. This behavior might have constituted n evasion technique or a self-sustaining tactic, but it could just as well have been a design flaw.
News of this article’s final malware incident emerged in early April 2020. As reported by the State of Security, the attack started when an attacker exploited an unprotected Docker API port to run a Ubuntu container. Those responsible for creating the container incorporated a shell script “d.sh” into their command.
This script subsequently disabled security measures, cleared logs, and killed processes spawned by other malware. After terminating rival malicious Docker containers, the script finally loaded its payload: Kinsing, a Golang-based Linux agent. This threat attempted to spread laterally throughout the network so that it could increase the reach of “kdevtmpfsi,” a second-stage payload used for conducting cryptomining activity.
How to Defend Against Docker-Based Malware Incidents
Organizations can take several steps to defend themselves against a Docker-based malware incident, such as the events described above. According to StackRox, organizations can begin by ensuring that they’re running the most updated version of Docker. Organizations risk leaving themselves exposed to security vulnerabilities if they’re not diligent in this regard. If that’s the case, a malicious actor could abuse one of those security flaws to gain access to an organization’s Docker environment and thereby expose its sensitive information.
Next, organizations need to appoint only trusted users to the Docker group and prevent containers from acquiring new privileges. Doing so will help organizations to lock down control of their Docker environment by deterring users from controlling the Docker daemon and from conducting privilege escalation attacks inside the network. In doing so, they’ll help to ensure that only trusted users can access their Docker environments.
Finally, they need to secure their container images. Organizations can do this by using base images that don’t include unnecessary software packages. Towards that end, organizations need to know where their base images are coming from; they should stay away from third-party repositories that might not have governance policies for what types of components come in base images. Even when they’re using secure images, organizations need to review their containers for vulnerabilities, unwanted components, and other potential security issues before they use them to build their containers.
Opinions expressed by DZone contributors are their own.