A new threat group emerged around late October, or early November 2021, dubbed Team TNT. The discovery of the threat group highlighted the problems traditional antivirus and EDR tools currently face, especially in light of container and cloud security.
As antivirus (AV) and EDR tools struggle to keep up with the newest malware, TeamTNT malware pushers have a slew of new toys with which they wreak havoc — various shell scripts & batch scripts, open source tools, a crypto miner, an IRC network, etc. that have inflicted more than 5,000 infections globally. Threat actors are continuing to break into improperly configured Docker instances to carry out malicious actions including installing Monero crypto miners, according to LMNTRIX labs.
Team TNT is an APT threat actor targeting containers using phishing attacks; privilege escalation, and container escape methods. The ongoing attack campaign had been launched by Team TNT, since November 2021 on exposed docker instances, as observed at LMNTRIX labs. Based on infection statistics on the Chimaera command-and-control (C2) server, our threat researchers noted that TeamTNT has been executing the phishing campaign for more than 48 days.
Towards the end of last year, TeamTNT became increasingly active, and it was linked to cryptocurrency mining malware being installed on susceptible Docker containers. LMNTRIX labs discovered that the gang tries to steal AWS credentials in order to propagate further more into newer server instances.
Team TNT – Advanced Threat Actor
A new threat group emerged around late October, or early November 2021, dubbed Team TNT.
The container infected by Team TNT downloads a variety of post-exploitation and lateral movement tools, such as container escape scripts, credential stealers, and cryptocurrency miners as observed by LMNTRIX labs. The continuing campaign is using Docker Hub accounts that were compromised as part of a previous campaign to drop malicious Docker images. According to LMNTRIX labs statistics, over 150,000 images have been pulled from the rogue Docker Hub accounts.
LMNTRIX Labs observed that the Chimaera campaign has a similar focus to older TeamTNT campaigns: such as compromising cloud credentials, using infected systems for cryptocurrency mining, and abusing victims’ machines to search and spread to other vulnerable systems. TeamTNT typically uses open-source tools for doing their dirty work. Example: they were using a tool libprocesshider to hide its malware under Linux by using the ld preloader. In the Chimaera campaign, TeamTNT had put together another new toolkit to help its crypto-mining malware to evade defense mechanisms.
A partial list of the tools used include:
-> Masscan and port scanner to search for new infection candidates,
-> libprocesshider for executing their bot directly from memory,
-> 7z to decompress downloaded files,
-> b374k shell, which is a PHP web administrator that can be used to control infected systems, and
-> LaZagne, an open-source application used to retrieve passwords from multiple apps and multiple web operating systems that are stored on a local computer, including from Chrome, Firefox, Wi-Fi, OpenSSH, and various database programs.
Recent attacks highlight the increasing sophistication of exposed servers being targeted by TeamTNT. Reusing compromised user credentials to fulfill their malicious motives has become a hot attacking trend for the past 5 to 6 years. Security researchers have reached out to Docker, and the accounts involved in this attack have been removed to prevent further exploitation.
Docker / Container Vulnerabilities
Vulnerabilities in the container environment don’t begin with fuzzing, and/or vulnerability research, rather the vulnerability originates from a software coding mistake. Everything in the container world is an abstraction on top of each layer, misunderstanding, or misuse of programming and program interaction with an abstraction layer results in new vulnerabilities. Examples: memory corruption, memory models, operating system API abuse, and web application code, in addition to misconfiguration errors. A user’s experience with the container environment keeps them “away” from all these layers by showing only the respective program/process and interface associated with their regular work.
Some examples of docker vulnerabilities are referenced below,
- CVE-2018-8115: Jack-in-the-box vulnerability
Example: Host / OS Level Vulnerabilities
Users of Docker for Windows are the only ones impacted by this issue. It enables the insertion of harmful code into individual container images. The Windows Host Computer Service Shim library (hcsshim) then executes the code, providing malicious threat actors a way to remotely execute code on the host’s file system.
- CVE-2019-5736: runC container escape vulnerability
Example: Privilege Escalation / Container Escape
By replacing the host’s runC binary, this Docker flaw lets hostile actors to take control of the host’s operating system at the root level. If the attack is successful, the attacker takes over the host’s system and has unrestricted access to the server and any containers that have been installed on it. We recommend following the principle of least privilege, giving each user only the minimum necessary access, considering utilizing a chroot jail, and putting restrictions like Apparmor and SElinux in place in Linux.
- CVE-2020-13401: IPv6 input validation vulnerability
Example: Man in the Middle (Attack)
A Docker vulnerability reported as CVE-2020-13401 was discovered in Docker Engine versions up to 19.03.10. Since it enables attackers to conduct a man-in-the-middle attack (MitM) against another container or the host’s network, it is classified as a major vulnerability. This flaw allows hackers to spoof IPv6 router ads. If they are successful, they can launch DDoS attacks and remotely access sensitive user data.
- CVE-2018-15664: Docker cp vulnerability
Example: Container / OS Level vulnerability
This Docker vulnerability allows remote attackers to take complete control of an initiated Docker cp process and acquire root access to the host’s file system. If the attack is successful, the attacker may move one or more files that are being created in a specific location on the file system.
- CVE-2018-11757: Apache Open Whisk vulnerability
Example: Application Security (Use of a vulnerable third party dependency)
This vulnerability enables malicious threat actors to take advantage of a bug in the Docker runtime for Open Whisk. If successful, attackers can overwrite the source code of a function in the container. Attackers could then choose to move laterally for gaining access to sensitive data, and delete or exfiltrate compromised data from the container.
- Log4J Vulnerabity / JNDI attack
Example: Java Library / Dependency vulnerability
This vulnerability, which was reported and widely exploited by December 2021, is a remote code execution vulnerability present in the Log4J library, a popular Java logging library, often in the context that an attacker has easy access to Log. It was discovered, initially in Minecraft servers that allowed commands to be typed into chat logs, which were then sent to the logger. Since this logging library is so commonly used, this is a very serious vulnerability that could be easily exploited by a typical attacker with a skillset to go after low-hanging fruit. Many open-source contributors are working hard to improve the software ecosystem with fixes and updates. The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive. The version that has fixed the Log4J vulnerability is 2.15.0. We recommend you update to the latest stable version if you’re using the Log4J library as part of your docker image.
Misconfiguration errors have been steadily increasing since 2018/19. Despite cloud providers’ concerted efforts to provide their customers with a mature shared responsibility model backed by necessary security controls, the truth is that unintended levels of exposure, and even forgotten assets, remain all about your employees. According to the DBIR, up to 13% of breaches are caused by an error or misconfiguration event, which, when combined with a lack of proper tracking and inventory capabilities, drives risk across all verticals.
Log4J Vulnerability – How it affected docker instances
In this context, where misconfigurations are causing an exposure – Docker is vulnerable to Log4J JNDI attack. So how trivial is to carry out the Log4J JNDI attack? A simple HTTP request of the Log4Shell attack for exploiting using a malicious LDAP server – can be tried with burp proxy,
Why is the log4J attack so dangerous?
An industry-wide vulnerability was disclosed in early December 2021 in an open-source Java logging component (known as Log4j) and identified by CVE-2021-44228. The Log4J vulnerability had received the highest CVSS score possible – 10.0 at the time of discovery.
Log4J vulnerability is extremely dangerous due to the following factors,
1) Exploiting the vulnerability is simple and persistent, with a plethora of weaponized exploits available on GitHub and other exploit databases.
2) Log4J2 is a well-known Java logging framework. Currently, around 7,000 Maven assets rely on log4j-core (the vulnerable library), and countless other Java projects do as well.
3) The vulnerability can be easily exploited in a drive-by-attack situation by hammering random HTTP servers with requests, as seen in the preceding JNDI attack, [OR] alternatively, using automated tools like XSStrike, a specific web application can be brute forced by populating all available HTML input fields with XSS payload strings.
4) Although the vulnerability is context-dependent, this scenario is quite common because arbitrary user input must reach one of the Log4j2 logging routines. In most logging contexts, user input is included as part of the log message. Since those inputs are deemed to be safe, it is rarely sanitized/filtered by security controls.
5) Worst Case Scenarios – A remote code execution vulnerability such as Log4J and it’s subsequent exploitation can be used to carry out a range of actions including;
- Deployment of ransomware
- Deployment of botnets
- Deployment of remote access tools
- Deployment of known attack tools
How can I completely fix the Log4J / Log4shell issue?
The ideal way to fix the Log4J issue would be to upgrade your java developer kit & logging dependencies to version 2.16.0, which completely resolves the issue by disabling JNDI by default, support for message lookups has also been removed. Upgrading to version 2.15.0 will also completely shield ‘default’ configurations from remote exploitation, although most of the mitigations added by version 2.15.0 have already been bypassed by emerging threat actors with new exploits. We recommend upgrading to the latest version to tread the world wide web safely.
Insight into How Attackers Use Docker Security Against Your Org
You’re probably aware that if you keep an API (application programming interface) or vulnerable application accessible for an extended period, it will eventually be compromised. That’s exactly what happened with insecure Docker Daemon APIs, and many of them were compromised by malicious crypto-mining malware.
When you visit hub.docker.com, you’ll discover a plethora of containers for cryptocurrency mining. These containers can be used normally, for mining operations, or maliciously by compromising an unsuspecting host and stealing their resources to facilitate mining. The containers mine more cryptocurrency for the threat actor; this process is called crypto-jacking.
Example: Team TNT is one of the more predominant threat actors using such malware for information gathering for files such as known hosts, SSH keys, and bash history to proceed with lateral movement, while mining cryptocurrency in the background.
Docker Security Best Practices
Top priority it to keep your host and docker version up to date, this is a very straightforward suggestion for securing your container images. Other best practices include:
- When you are developing a node.js application, consider using an official and validated Docker image as a base image that is already created using industry best practices. Using the official node image for your application instead of taking a base operating system image and installing node.js, npm, helps you have a cleaner, optimized and secure image alongside the additional scripts, libraries, and dependencies you may require for building your application.
- Using .dockerignore file – When we usually build the container image, we don’t need everything we have in the project to run the application. We can therefore exclude such content from ending up in our application image using the ‘.dockerignore’ file. We create this .dockerignore file and list all the files and folders that we want to be ignored when building the docker image. Docker will look at the contents and, obviously ignore everything specified inside the file.
- Use a dedicated user or the least privileged user concept – When we generate this image and run it as a container, guess which user will be used to start the application inside? When a Dockerfile does not specify a user, the root user is assigned to docker by default. In most cases, there is no rationale or necessity to run containers with root privileges in production.
- Separation of build tools and dependencies from what’s needed for production – If you keep the loosely bound artifacts from the development stage in your final image even though, they’re not necessary for running the application, it will again result in opening up an increased attack surface. So how do we separate the build stage from the runtime stage? The multi-stage builds feature allows you to use multiple temporary images during the build process, but keep only the latest image as the final artifact.
- A typical network scanner such as Nessus, or OpenVAS may miss out on docker vulnerabilities. Once you build the docker image, you can scan the image for security vulnerabilities using the docker scan command. In the background, Docker uses a service called Snyk to do the vulnerability scanning of the images. The scan uses a database of vulnerabilities, which gets constantly updated through research and advisories. Ensure you scan and validate that the image you build has no security vulnerabilities.
For a more comprehensive list of best practices, check out the following links,
The impact of a given vulnerability on container environments might differ significantly from the impact on environments running traditional operating systems, as shown in the examples above. You need to understand how and why the vulnerable packages were included in the container image to estimate the effect of the specific vulnerability on your container environment. Any security or operations team must have policies & procedures in place to address vulnerabilities of varying degrees. In the subsequent article, we will cover Kubernetes-specific vulnerabilities, attack vectors, and ways to defend against orchestration platform attacks.