TeamTNT Hits Docker Containers via 150K Malicious Cloud Image Pulls

An apparent operational security slip-up by a member of the TeamTNT threat group has exposed some of the tactics it’s using to exploit poorly configured Docker servers.

Security researchers from Trend Micro recently set up a honeypot with an exposed Docker REST API to try and understand how threat actors in general are exploiting vulnerabilities and misconfigurations in the widely used cloud container platform. They discovered TeamTNT — a group known for its cloud-specific campaigns — making at least three attempts to exploit its Docker honeypot.

“On one of our honeypots, we had intentionally exposed a server with the Docker Daemon exposed over REST API,” says Nitesh Surana, threat research engineer at Trend Micro. “The threat actors found the misconfiguration and exploited it thrice from IPs based in Germany, where they were logged in to their DockerHub registry,” Surana says. “Based on our observation, the motivation of the attacker was to exploit the Docker REST API and compromise the underlying server to perform cryptojacking.”

The security vendor’s analysis of the activity eventually led to uncovering credentials for at least two DockerHub accounts that TeamTNT controlled (the group was abusing DockerHub free Container Registry services) and was using to distribute a variety of malicious payloads, including coin miners.

One of the accounts (with the name “alpineos”) hosted a malicious container image containing rootkits, kits for Docker container escape, the XMRig Monero coin miner, credential stealers, and Kubernetes exploit kits.

Trend Micro discovered the malicious image had been downloaded more than 150,000 times, which could translate into a wide swath of infections.

The other account (sandeep078) hosted a similar malicious container image but had far fewer “pulls” — just about 200 — compared with the former. Trend Micro pointed to three scenarios that likely resulted in the leak of the TeamTNT Docker registry account credentials. These include a failure to logout from the DockerHub account or their machines being self-infected.

Malicious Cloud Container Images: A Useful Feature

Developers often expose the Docker daemon over its REST API so they can create containers and run Docker commands on remote servers. However, if the remote servers are not properly configured — for instance, by making them publicly accessible — attackers can exploit the servers, Surana says.

In these instances, threat actors can spin up a container on the compromised server from images that execute malicious scripts. Typically, these malicious images are hosted on container registries such as DockerHub, Amazon Elastic Container Registry (ECR), and Alibaba Container Registry. Attackers can use either compromised accounts on these registries to host the malicious images, or they can establish their own, Trend Micro has previously noted. Attackers can also host malicious images on their own private container registry.

Containers that are spun up from a malicious image can be used for a variety of malicious activities, Surana notes. “When a server running Docker has its Docker Daemon publicly exposed over REST API, an attacker can abuse and create containers on the host based on attacker-controlled images,” he says.

A Plethora of Cyberattacker Payload Options

These images may contain cryptominers, exploit kits, container escape tools, network, and enumeration tools. “Attackers could perform crypto-jacking, denial of service, lateral movement, privilege escalation, and other techniques within the environment using these containers,” according to the analysis.

“Developer-centric tools like Docker have been known to be abused extensively. It’s important to educate [developers] at large by creating policies for access and credential use, as well as generate threat models of their environments,” Surana advocates.

Organizations should also ensure that containers and APIs are always properly configured to ensure that exploits are minimized. This includes ensuring that they are accessible only by the internal network or by trusted sources. In addition, they should follow Docker’s guidelines for strengthening security. “With the rising number of malicious open source packages targeting user credentials,” Surana says, “users should avoid storing credentials in files. Instead, they are advised to choose tools such as credential stores and helpers.”