The Unit 42 research arm of Palo Alto Networks revealed this week that it has discovered an instance of cryptojacking employing containers in Docker Engine that includes a worm capable of replicating the original malware infestation.
Dubbed Graboid, this latest attack represents the very first time a worm has been included as part of a cryptojacking attack using containers, says Jen Miller-Osborn, deputy director for threat intelligence at Unit 42. In some way, it was simply a matter of time. Containers have been employed to launch cryptojacking attacks that steal CPU resources to mine cryptocurrencies on behalf of cybercriminals. Worms have also been attached to cryptojacking attacks that didn’t involve containers.
However, this attack should serve as a wake-up call to take cryptojacking more seriously, says Miller-Osborn, noting it’s not too hard to imagine how cybercriminals would use the same vector to launch a more lethal ransomware attack using containers.
The cybercriminals launching Graboid gained their foothold via unsecured Docker daemons, where a Docker image is installed to run on the compromised host. The malware, which was downloaded from command and control (C2) servers, is deployed to mine for Monero cryptocurrency and periodically queries for new vulnerable hosts from the C2 to randomly find its next target.
Miller-Osborn says the cryptojacking appears to run for short amounts of time in the hopes of evading detection. Unit 42 research indicates on average each miner is active 63% of the time and each mining period lasts for 250 seconds.
Unit 42 discovered the malware while researching unsecured Docker daemons, Miller-Osborn says. Since its discovery, Unit 42 alerted Docker Inc., which has removed the malicious images.
However, Unit 42 has shown using the Shodan search engine that more than 2,000 Docker engines are insecurely exposed to the internet, which would suggest there may be more Graboid instances running in IT environments. On average, Miller-Osborne says cryptojacking attacks usually consume only about 12% of CPU capacity, so it’s relatively easy for them to remain undetected.
Miller-Osborne says unsecured Docker daemons generally is an easily avoidable issue. In the age of the cloud, however, developers still get confused by shared responsibility models. They often assume the cloud service provider is securing both the application and the underlying infrastructure when, in fact, the developer is responsible for container image security.
To ensure organizations never encounter this problem, Unit42 recommends the following best practices:
- Never expose a Docker daemon to the internet without a proper authentication mechanism. Note that by default the Docker Engine (CE) is not exposed to the internet.
- Use a Unix socket to communicate with Docker daemon locally or use SSH to connect to a remote Docker daemon.
- Use firewall rules to whitelist the incoming traffic to a small set of sources.
- Never pull Docker images from unknown registries or unknown user namespaces.
- Frequently check for any unknown containers or images in the system.
- Cloud security solutions can identify malicious containers and prevent cryptojacking activities.
Of course, everyone starts out with the best of container security intentions in mind. The difficult part is remaining vigilant.