TeamTNT Cryptomining Explosion 🧨 - Intezer

TeamTNT Cryptomining Explosion 🧨

Written by Intezer

    Share article
    FacebookTwitterLinkedInRedditCopy Link

    Top Blogs

    This post was originally published as a white paper in September 2021. Get the full report as a PDF here.

    Zusammenfassung (Executive Summary)

    Over the past year the TeamTNT threat actor has been very active. TeamTNT is one of the predominant cryptojacking threat actors currently targeting Linux servers. This blog investigates the threat actor’s activity and their Tactics, Techniques and Procedures (TTPs)—providing all of this information in one place so security teams can better detect and prevent attacks from TeamTNT.

    Based on our findings, we can conclude that they have been active since the Fall of 2019, six months before the first public report on the threat actor’s activity. As of this writing, TeamTNT is mainly focused on compromising Kubernetes clusters. Prior to this, they used to target servers running Docker and Redis. We at Intezer also uncovered Windows binaries hosted on a TeamTNT server that was potentially an experiment to target Windows machines.

    Much of the threat actor’s tooling has stayed consistent throughout their different campaigns. The majority of their tools are based on shell scripts but they also use some “tried and tested” compiled binaries in the attack chains. For example, the use of the Tsunami malware, first documented by Trend Micro, has been a staple of TeamTNT’s campaigns since October 2019. In addition to cryptojacking, a second objective for the threat actor has been to exfiltrate information about compromised hosts.

    As early as the Winter of 2020, Intezer saw the threat actor utilizing novel techniques to steal SSH credentials from the compromised machine when it was being used by administrators.

    TeamTNT has employed techniques to hide their activities on compromised machines, making incident response investigations more difficult. All of their scripts are designed to be executed without being written to disk or self deleted after execution. They have used techniques of hiding their running processes by mounting an empty folder over the process entry within the procfs, or by using UserLand and kernel level rootkits.

    The threat actor maintains a public persona on Twitter using the handle HildeTNT. The majority of their tweets are written in German and the account’s location is set to Germany. In addition, many comments in the shell scripts used by the threat actor are written in German. Therefore, it can be assumed that TeamTNT’s country of origin is Germany. Much of their interaction with the security industry is via commenting on reports covering their campaigns, mostly to point out incorrect conclusions. During the Spring of 2021, TeamTNT refuted some campaigns attributed to them. The tools used in these campaigns were based on some of TeamTNT’s older scripts but not something they currently were using. This suggests another threat actor has started to copy TeamTNT.

    teamtnt timeline

    Table of Contents

    Der Anfang (The Beginning)

    Der FrĂŒhling 2020 (Spring 2020)

    Der Sommer 2020 (Summer 2020)

    Der Herbst 2020 (Fall 2020)

    Der Winter 2021 (Winter 2021)

    Der FrĂŒhling 2021 (Spring 2021)

    Der Sommer 2021 (Summer 2021)

    Soziale AktivitÀt (Social Media Activity)

    Werkzeuge (Tools)

    Das Fazit (Conclusion)


    Die EinfĂŒhrung (Intro)

    Since the introduction of Amazon Web Services (AWS), there has been a steady migration from on-premise to cloud deployments. As part of this migration, the security around services has also changed. On-prem deployments can sometimes be more forgiving as a misconfigured service would also be behind a corporate firewall, resulting in it not being exposed to everyone over the internet. A misconfigured cloud service can be low-hanging fruit for an attacker. Palo Alto Networks investigated the attacks against cloud servers during the Spring of 2021 via a Docker honeypot, finding that it was attacked about every 90 minutes. Of these attacks, around 76% were by cryptojacking threat actors. One of the most active actors in this field is TeamTNT.

    The first public report on TeamTNT was published in May 2020 by Trend Micro and covered attacks against servers running exposed Docker instances. While this is early activity, it is not the earliest that can be attributed to the threat actor. As part of this report, we will share our knowledge about campaigns that took place during February the same year and also provide evidence that TeamTNT has been active since at least October 2019.

    The first set of campaigns by TeamTNT targeted only Redis instances. Throughout their over a year and a half tenure, they have migrated away from focusing on Redis to instead target Docker services and most recently Kubernetes clusters. This includes the use of cloud monitoring software to deploy cryptominers on vulnerable servers.

    The techniques and tools used by the threat actor have slightly evolved over time but the general desired outcome has been the same. The first campaign that we at Intezer uncovered, taking place around February 2020, used techniques for stealing credentials and tried to stay hidden on the compromised system. Many of the tools that are still used were leveraged in the first set of campaigns.

    For example, the Tsunami Internet Relay Chat (IRC) bot and the backdoor known as Rathole were used. The majority of tools used by TeamTNT are either open-source or source-code-available but we have also identified some custom written tools and a possible pivot to targeting Windows machines. This is an interesting deviation, since TeamTNT appears to be heavily invested in targeting *NIX servers. The more recent campaigns have targeted Kubernetes and cloud workloads with the goal to steal cloud-related configurations and credentials, in addition to running cryptominers.

    TeamTNT is a bit of an anomaly when it comes to cryptojacking threat actors. They have a public presence on the clear web while most threat actors stay hidden in the shadows. The threat actor has a public profile on Twitter and sometimes interacts with the research community tweeting about the success of their current campaigns. Based on their social media account they are located in Germany and the majority of their tweets are written in German. The threat actor’s interaction with the research community mostly takes the form of commenting on incorrect conclusions made by analysts.

    During the Spring of 2021 some new campaigns were uncovered that looked to have all the makings of TeamTNT. In both cases, the threat actor was quick to point out that it was not their campaign but rather someone was reusing their old scripts to make it look like it was them. Prior to this, TeamTNT had not refuted any campaigns attributed to them. Instead, they were mostly using Twitter to show off their capabilities.

    The activity from TeamTNT does not appear to be slowing down. They continue to reuse their tools in their attacks. This may be because their operations are unhampered by security tools. Because of this and the potential misinformation about the threat actor, we decided to take a deeper dive into TeamTNT’s activities to gain a better understanding of their timeline and Tactics, Techniques, and Procedures (TTPs). With this knowledge, we aim to organize all of this information properly into one resource to help security teams better detect and prevent attacks from this threat actor.

    Der Anfang (The Beginning)

    The first public report on TeamTNT’s activity was published by Trend Micro in May 2020. While this report covers some of the early activities, it does not include the initial activity that can be traced back to the threat actor. One of the network indicators of compromise in this report is the domain name teamtnt[.]red. This domain was registered on February 10, 2020 and is one of the first references to ‘TeamTNT’ by the threat actor. This infrastructure was used by the threat actor against attacks on unprotected Redis servers. The initial “setup” script used in this campaign was uploaded to VirusTotal on February 26, 2020. The setup script downloads the rest of the modules used in the attack. Many of them are shell scripts that are directly piped to either bash or /bin/sh but some files were also written to disk. Figure 1 shows a diagram of all the parts downloaded and executed by the different modules. The oldest files that we were able to capture were added to the server four days after the domain name was registered, giving us a good indication of when the initial campaign might have started.

    Figure 1: Diagram showing how different parts are downloaded and executed when the threat actor compromises an unprotected Redis server.

    The Setup

    The infection on the machine started with the execution of the shell script that was located in a subfolder called load. This script is responsible for downloading and executing the other parts of the toolchain used by TeamTNT. The file has a comment on the top as can be seen in Figure 2. According to the comment, the file was the module scan/pwn Redis Server Setup.

    Figure 2: The first few lines of the file. The file sets up the machine to scan and infect other Redis servers.

    One of the first things the script does is check if a specific binary is running. If it doesn’t run, it downloads a setup script called for this binary. The binary installed by this shell script is an instance of the Tsunami malware. For more information about this malware, see the Tools section.

    Two additional shell scripts were downloaded from the server (hosted at, and sysinfo.txt. The first shell script installs the miner on the infected machine while the second collects host information.

    Following the download and execution of the shell scripts, the scripts try to hide their process. The shell commands executed are shown in Figure 3. To hide the process, a shell script is created at /bin/hid. The shell script hides the process by first making a copy of /etc/mtab. After this, it mounts an empty folder over the process’s folder under /proc. Lastly, it overwrites the /etc/mtab file or symbolic link with the copy it made before the mount. These steps hide the process from programs that walk the /proc filesystem, for example, ps and top. If an admin checks the mtab file the mount entry is not present, but listing the mount points by executing the mount command shows bind mount. After the setup executes the hid shell script it mounts another instance of the proc filesystem under /proc. This essentially results in undoing the process performed by the hid shell script.

    Figure 3: Section of the setup script that creates a shell script for the hiding process.

    To prevent other threat actors from also compromising the Redis instance, the setup script added iptables rules to only accept connections on port 6379 from localhost. The shell script also performs a request to the C2 server that appears to be for logging the infected machine’s IP address.

    During this campaign, the threat actor focused on compromising unprotected Redis servers. The setup script creates the payload that is executed on the Redis servers. The code is shown in Figure 4. It’s using Redis’s FLUSHALL issue to create a cron job that downloads a setup script. This setup script is almost identical to the main setup script, except that it doesn’t set up Tsunami.

    Figure 4: Code for creating the Redis payload.

    The setup script checks if Tsunami and bioset are running. If they are, the script restarts the processes to hide them with the hid shell script. If they are not running, it downloads them followed by starting and hiding them.

    To find other Redis servers to infect, the threat actor uses pnscan. The setup script downloads the source code for the scanner and compiles it. The scanner is “installed” at /usr/sbin/dbus-daemon. Another shell script is downloaded that handles scanning and sending the payload to any found Redis servers. When all stages have been downloaded and started, the setup script removes itself from the infected host.

    DDoS Bot Setup

    This shell script downloads and installs the Tsunami DDoS bot. The script installs the binary to two different places based on if the script was executed as root or not, Figure 5. If it is executed as root, the malware is installed to /bin/kthreadd, otherwise, it is installed to /tmp/.tmp. Before installing the malware, the script flushes and deletes all the iptables chains to ensure it can connect to the C2 server without any resistance.

    Figure 5: The script installs the bot under /bin if it has root permissions. Otherwise, it is installed into the /tmp folder.

    Gather Information About the System

    The file sysinfo.txt, while disguised as a text file, is a shell script that is executed by the setup script. A “lock” file is created in case the script is executed multiple times on the same machine. Figure 6 shows the check for the lock file. If it exists, the script exits early. If this is the first time it’s executed, it starts collecting information about the machine. In the same figure, the logic used to determine the available RAM is also shown.

    Figure 6: Part of the script that checks if system information has already been collected for the machine. If it hasn’t, it gets the available ram.

    The script also collects: username of the user executing the script, CPU speed, how long the machine has been running, if it’s 32 or 64-bit, the number of CPU cores, and which Linux distribution. All this information is sent to the threat actor’s server via the wget command shown in Figure 7. When the script is done, it deletes itself.

    Figure 7: Exfiltration of host information to the actor-controlled server.

    Capture SSH Credentials

    The shell script is downloaded by the setup script and according to the comment at the top of the file, shown in Figure 8, it is used to steal SSH credentials.  

    Figure 8: Comment at the top of the SSH credential stealing module.

    The module uses strace in combination with a shell alias to log the activity. A cron job is used to upload the log files to a threat actor-controlled server. As can be seen in Figure 9, the script adds the alias code to the bashrc file for the root user and all the normal users on the machine. After this, when a user uses SSH to connect to another machine, strace is used to log the activity to a log file. The cron job seen added in the same figure executes the upload script every five minutes.

    Figure 9: SSH credential collection via strace. The log files are uploaded every five minutes via a cron job.

    The upload script is relatively simple, shown in Figure 10. It checks if the log files exist. If they do, it uses curl to upload the files before it is removed.

    Figure 10: Upload script for the strace logs.

    Scan for Other Machines to Compromise

    The dbus-config file downloaded by the setup script is a Redis exploit/scan module. As can be seen in Figure 11, it uses pnscan that was downloaded and compiled earlier. It scans the whole IPv4 space for other Redis servers. If it finds another server, it uses the Redis client on the machine to send the payload, which causes the exploited service to set up a cron job that will download the setup script.

    Figure 11: Redis scanning functionality.

    The results are uploaded to a threat actor-controlled server as can be seen in Figure 12.

    Figure 12: Scan results uploaded to a threat actor-controlled server.


    The shell script’s main job is to set up the mining process. It downloads the miner, a watchdog process, and the configuration file. The installation process depends on if the shell scripts have root permissions or not. If they do, a second stage is downloaded and executed to perform the root setup. Otherwise, the scripts download and install the files into the temp directory. The configuration is modified to be unique for each infected host. A worker ID is created based on the username of the user executing the script and the machine name. The miner used is a fork of XMRig called XMRigCC. It provides a dashboard that can be used to control the miner. The command center used in the campaign was located at 

    Watchdogd Process

    The watchdogd binary is a simple application written in C++. A code reuse analysis is shown in Figure 13. Its sole purpose is to ensure that the miner is running. It does this by using a loop to call libc’s system function. If the process exits, the call to the system is repeated.

    Figure 13: Code reuse analysis of the watchdogd binary.


    NarrenKappe, which translates to jester hat, is a mining setup script that is executed if the script has root-level permissions. Since it has higher permissions, it performs some additional actions than when executed as a normal user.

    First, it checks if the watchdog process is running and exits the setup. Otherwise, it checks if old files from a previous infection exist on the machine and removes them. Following this, it removes all the cron jobs on the machine. It tries to clean out other infections using the commands in Figure 14.

    Figure 14: Commands used to clean the system.

    The script downloads a 64-bit or 32-bit miner depending on what is supported as can be seen in Figure 15.

    Figure 15: Download and installation steps used by the mining setup script.

    The mining configuration is modified to include a unique identifier for the infected host. The logic is shown in Figure 16.

    Figure 16: Logic for modifying the mining software’s configuration file with host information.

    The script ensures the processes are started again if the machine is rebooted. The script adds either a System V init script or a systemd service depending on what is used by the system. The commands executed in either path are shown in Figure 17.

    Figure 17: Code for adding either a System V init script or a systemd service.

    It ensures that the service is running by adding a cron job that is executed every hour, Figure 18.

    Figure 18: Cron job executed every hour.

    In addition to setting up the mining process, the script also starts another script that: scans for Redis servers, downloads and executes a post-exploitation tool called, and exfiltrates SSH keys, bash history, known SSH hosts, and the host file.

    Removing All Traces

    The script is run by the mining setup script if the watchdog process is already running. The script is used to clean out the logs on the machine. First, it hides the process and downloads a log cleaner written in C. As can be seen in Figure 19, the logs for the users reboot, hilde, and .r00t are cleared before it uploads the bash history of the root user to the threat actor’s server.

    Figure 19: Log cleaning for three user accounts and exfiltration of the root user’s bash history.

    Folgen Sie dem Semmelbrösel

    Using information that was present in this campaign, we were able to find some earlier activity. The rathole binary used in this campaign was uploaded to VirusTotal as early as October 2019. Figure 20 shows a screenshot of the submission date.

    Figure 20: First submission of the rathole binary to VirusTotal.

    A script file that was included in the archive with the miner but not used in this campaign included the functionality to download from a server located at This IP was found referenced in a shell script file called that was uploaded to VirusTotal in January 2020. It has very similar functionality as observed in this campaign. An out-commented line in the file references the URL http[:]//3[.]215[.]110[.]66/src/bioset. Additionally, the script adds an SSH key and creates a user called hilde with the password gard, Figure 21.

    Figure 21: Shell script from January 2020 that creates a hilde user and adds a SSH key.

    Der FrĂŒhling 2020 (Spring 2020)

    As reported by Trend Micro on May 6, 2020, TeamTNT targeted Docker daemon ports and abused them to install cryptomining malware and DDoS malware. This is a shift from their previous targeting of Redis servers and appears to be the first documented evidence of the group targeting exposed Docker daemon ports and using them to spread malware.

    As in the previous campaign, the group used several shell scripts to carry out the attack. The first script is used to bootstrap the infection by creating a container from an Alpine image. When the container is started, it uses the volume functionality to mount the host system’s root filesystem to /mnt inside the container. This gives the root user inside the container the ability to modify the host machine as if it was root on the host machine. The container is set to download and execute another script which in turn downloads and executes several shell scripts.

    The use of scripts that download and execute the malicious functionality evades detection techniques because the image doesn’t contain suspicious/malicious parts, therefore it will not be detected by static analysis tools such as image scanners.

    As mentioned above the container is mounted to the filesystem of the host so that the scripts are executed on the host. The implements the functionality for deleting other miners, installing admin tools and cryptomining malware, implementing evasion techniques and spreading to other victims. Many of the same techniques were used in the earlier campaigns.

    Figure 22: Overview of the scripts executed in this campaign (as described by Trend Micro).

    Figure 23: Screenshot of

    As can be seen in Figure 23, gets an argument in the form of an IP address from the victim machine. Using the open-source tool called masscan the script scans a predefined list of ports. The function uses zgrab to identify if a Docker service is listening on the port. ZGrab is an open-source application scanner created by the individuals behind For all Docker services found, the script uses the exposed port to spawn a new container from the Alpine image. Using the bind method, the root directory of the victim machine is mounted to the container filesystem. A shell command to download and execute the script is set to be executed using sh shell as soon as the container is created.

    Figure 24: Screenshot of

    The script removes previous cronjobs named “COVID19” and “SARScov2” and then verifies that curl and bash are installed.  If not, the script installs them. Next, the script downloads and executes scripts that include other functionalities for the attack.

    The container is created with /bin/sh shell (as set in but it seems that the group decided to use bash for some scripts and sh shell for other scripts.

    When we examined the Uniform Resource Locator (URL) http://45.9.148[.]123/COVID19/ in VirusTotal we discovered another file, submitted on April 30, 2020, about one month before Trend Micro released their report. At the time of the report the file had four detections.


    Figure 25: VirusTotal screenshot for the second file.

    The other script doesn’t implement new features, however, it uses a different hosting domain: http://kaiserfranz[.]cc, the domain registered on March 10, 2020.

    Figure 26: Screenshot of the second file.

    It is interesting to note that the group included “COVID19” as part of the URLs used to download scripts. Both scripts were uploaded to VirusTotal on April 30, 2020. Around this time the COVID-19 pandemic was spreading quickly around the world and countries entered lockdowns.

    Figure 27: Number of daily new confirmed COVID-19 cases from March to May 2020. Source: Our World in Data 

    Some threat actors took advantage of the crisis and started abusing it as a theme for phishing activity knowing that people were desperate for information related to the global pandemic. It is unclear if the use of the term “COVID-19” is part of an evasion technique since the group doesn’t make other attempts to hide its activity.

    Figure 28: Screenshot of script.

    This script is responsible for: killing processes of other cryptominers, deleting cron jobs and files used by other threat actors, removing containers that execute malware, and disabling monitoring services such as apparmor.


    Figure 29: Screenshot of dns script.

    The script executes another script named dns. Based on the architecture of the victim system, a tool called dns3 (link to analysis) is downloaded and masqueraded as part of systemd. Based on the code relation this is Tsunami. It has 32-bit and 64-bit versions, both versions which were submitted to VirusTotal on April 19, 2020. For more information check the Tools section.

    Figure 30: Screenshot of dns3 in Intezer Analyze.

    Connection to Other Scripts

    The IP 45.9.148[.]123 from the scripts in this campaign was resolved to vps.teamtnt[.]red on May 2, 2020 and located in The Netherlands. Based on VirusTotal the IP address is related to many malicious scripts, two of these files are: which was submitted on the day of the domain resolution and the second file was submitted a couple of days later.

    Figure 31: Screenshot of

    Figure 32: Graph showing the scripts executed by

    Figure 33Figure 33: Screenshot showing

    The script targets Redis and uses the URL http://45.9.148[.]123/MoneroOcean/sh/ to download the script that will be executed on the exposed Redis instance.

    Both scripts ( and target Redis and they use the tools mentioned in the first captain (bioset and pnscan). Based on similarities in the functionality and behavior of the scripts we can conclude that these scripts were part of the campaign that targeted Redis servers.

    Der Sommer 2020 (Summer 2020)

    Throughout the Spring and Summer of 2020, TeamTNT targeted exposed Docker containers. The exploitation techniques used during the Summer were very similar to the techniques used during the Spring. One key addition was the stealing of AWS credentials, as first reported by Cado Security. The threat actor scanned the home directories of the users on the infected machine for the file ~/.aws/credentials. If the file was found, it would be uploaded together with the /.aws/config file to a server controlled by the threat actor.

    The threat actor also started to publish information on their website that appears to have been collected during their campaign. The screenshot of TeamTNT’s website, seen in Figure 34, shows a list of “free/open” sandboxes available on the internet. Since the earliest campaign we detected the threat actor has been logging the external IP of the machines they have infected. It is possible that they used this data to identify these sandboxes.

    Figure 34: Screenshot from TeamTNT’s website. The website published unprotected sandboxes (Reproduced with permission from Cado Security: Team TNT – The Crypto-Mining Worm to Steal AWS Credentials 2020).

    Docker Exploitation

    In the Spring activity, the shell script called was used to exploit Docker hosts. It would call a function named pwn with three arguments. The first of these arguments was the same first argument passed to the file when it is executed. During the Summer, this logic was changed and it instead would get this value from a compromised server. Figure 35 shows the changes. A similar script file was also used to target other machines on the same network. Figure 36 shows the function in the “lan” file that instead scans the local network.

    Figure 35: Pwn function called. The function uses a URL to determine the range of IPs to scan instead of it being passed onto the parent script file as an argument.

    36: Pwn function used to scan other Docker servers on the same network.

    The pwn function was also changed a bit. During the Spring, it would execute a command to download an alpine image. The image is started with the instruction to download an initialization shell script. In addition to this functionality, during the Summer campaign setup the shell script was also passed in as base-64 encoded data in case the first method failed. Figure 37 shows part of the pwn function used during Summer. The threat actor also added instructions to perform the same attack using an Ubuntu image in addition to the alpine image.

    Figure 37: Part of the own function that is used to infect Docker servers with containers to mine Monero.

    Palo Alto Networks released a report in August 2020 on a new malware that they attributed to TeamTNT. The malware, named Cetus, infected one of the researcher’s Docker honeypots. Cetus essentially has two jobs, start the miner and infect other servers running Docker. This appears to be the first custom written malware used by the threat actor.

    Since the beginning of their activity, TeamTNT has tried to hide their activity on infected machines. In the early campaigns, they would mount an empty directory over a running process’s folder in the procfs to hide it from outputs with top and ps. In the Summer campaign, they took this further by using a Linux Kernel Module (LKM) rootkit. Figure 38 shows the installation of the rootkit. The rootkit called Diamorphine is an open-source rootkit hosted on GitHub.

    Figure 38: Setup script for Diamorphine. It installs kernel headers and build tools.

    The script installs the kernel headers and tools needed to compile the LKM before it downloads the source code for the rootkit via git. After the module has been compiled, it loads the module. The rootkit is used to hide the miner. This is performed by sending a signal 31 to the process. Figure 39 shows an example of this.

    Figure 39: Arrow points to a command to hide the miner via a signal to the rootkit.

    SSH Exploitation

    The SSH exploitation technique was also updated during this time period. For example, more SSH related files are exfiltrated from the compromised host, as seen in Figure 40.

    Figure 40: TeamTNT added more configuration and key files to its list to be exfiltrated from the compromised server.

    Like many other threat actors that target Linux servers, TeamTNT also uses the known_hosts file to find other machines that it may spread to. In addition to this, TeamTNT scans the networks that the machine is connected to using pnscan, to see which other machines have port 22 listening. As can be seen in Figure 41, the result is added to the known_hosts file.

    Figure 41: TeamTNT scanning local networks for other machines that are listening on port 22.

    To find keys that can be used to authenticate to these machines, the threat actor looks for id_rsa files in all home folders and checks for defined IdentityFile configurations. Additionally, the bash history is checked for uses of both SSH and scp. The threat actor uses similar techniques to find more servers to spread to. As examples, it checks: the host file for other machines, defined HostName in the SSH config files, bash history, items in the known_hosts files, and processes connected to external IPs on port 22. Similar methods are also used to determine different user accounts that can be used to connect to the machines. It’s worth noting that since the earliest TeamTNT campaigns we uncovered, the threat actor has exfiltrated the bash history files on machines they have compromised. It is possible that they have used this data to devise these methods for gathering keys and IP addresses from other machines that can be used for lateral movements. Figure 42 shows the different commands used.

    Figure 42: List of commands used by TeamTNT to find SSH keys, machines and user accounts that can be used to infect other machines.

    The collected data is added to “master” lists that the script enumerates through. Each username and key is used for all discovered servers. If a successful login is achieved, a command is executed to download a setup shell script on the machine. This logic can be seen in Figure 43.

    Figure 43: For each enumerated host, the script tries to log in with the usernames and keys. If successful, the setup script is downloaded and executed on the machine.

    In addition to spreading to other machines the following files are downloaded:

    • docker-update (XMRig)
    • tshd (Tiny SHell)
    • kube (Tsunami)
    • bioset (Rathole)

    Docker Containers

    In addition to downloading “base” images from Docker Hub to set up the attack, Aqua Security released research on TeamTNT’s use of custom images. The images uploaded by the user account hildeteamtnt to the hub was categorized into two categories: “Simple and straightforward” images used for cryptomining and “Sophisticated” used for container escaping. The sophisticated images used the Docker Escape Tool, an open-source tool hosted on GitHub. Much of the techniques and tools used were very similar to the threat actor’s previous activity.

    Der Herbst 2020 (Fall 2020)

    On September 8, 2020 Intezer discovered that TeamTNT abused a legitimate cloud monitoring tool called Weave Scope. The tool gives the user full access to their cloud environment and is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic Compute Cloud (ECS).

    Weave Scope is a powerful utility for working with microservices-based applications, as it has many features including: detailed information about each container and processes running in them, memory usage of each container, links and connections between containers, and the ability to start, stop, and open interactive shells in any of these containers.


    Figure 44: shows a screenshot of the Weave Scope dashboard.

    This was the first time TeamTNT was found using a legitimate tool for the purpose of gaining control over the victim’s infrastructure. By installing a legitimate tool such as Weave Scope the attackers gained all the benefits as if they had installed a backdoor on the server, with significantly less effort and without needing to use malware.

    Weave Scope is an open-source project and its installation is relatively easy. The attackers created a container based on an Ubuntu image and used the mount functionality. This method was described in the previous section. At this point the attacker had full access to the filesystem of the victim machine, so they downloaded and installed Weave Scope as described in the project’s Git:

    Figure 45: Scope Weave install to Commands.

    The dashboard of Weave Scope is accessible on port 4040. By exposing this port the attackers gained full access to all of the features of this tool.

    Throughout the Fall of 2020, TeamTNT also expanded their TTPs around credential stealing to not only target stored AWS credentials. In a report published by Palo Alto Networks in October 2020, the researchers reported on uses of mimipenquin and mimipy by the threat actor. Both of these tools are designed to dump passwords from various processes’ memory. They are essentially the *NIX equivalent of Mimikatz for Windows. After the credentials had been dumped, they were exfiltrated to TeamTNT’s C2 server.

    Later the same month, ESET tweeted about a new tool the threat actor had added to their arsenal. The researchers found a binary written in Go with an AES encrypted payload. When the crypter was executed, it would decrypt the payload and write it to a memory only file created with the system call memfd_create. The tool was identified as Ezuri, an open-source project created by a security researcher.

    Figure 46: Tweet published by ESET reporting on the initial finding of TeamTNT’s use of Ezuri to crypt their malware.

    Der Winter 2021 (Winter 2021)

    In January 2021, Lacework Labs released a detailed analysis of Tsunami, the IRC bot used by TeamTNT. By extracting the configurations embedded in the malware, they could connect to the IRC server and get more information about the threat actor’s operation and victim information. At the time of their analysis, around 200 bots were connected but only 90 unique IP addresses were detected. We have seen that TeamTNT has employed techniques to spread to other servers within internal networks. This suggests that some of the bots were behind a NAT and shared the same external IP address. The majority of the infected machines were located in Asia with servers hosted in cloud providers Tencent, Alibaba, and Amazon Network being the largest. Outside of Asia, the United States, France, and Germany had the most bots. The researchers also uncovered that some of these infected machines were used to launch new campaigns.

    The threat actor also added more tools to hide their activity on the infected machines. In January 2021, AT&T Alien Labs released a report on TeamTNT’s use of libprocesshider. The tool is used to hide processes using LD_PRELOAD. The shared object was written to /usr/local/lib/ by the setup script and directives were added to /etc/ to allow the shared object to be loaded with every file that is executed. TeamTNT used libprocesshider to hide their Tsunami bot on infected machines.

    Attacking Kubernetes

    The use of LD_PRELOAD to hide itself was spotted in another campaign of the group, this time targeting exposed Kuberentes instances. Each Kubernetes node has a running agent called kubelet which takes RESTful requests and performs operations on the pods accordingly. The default configuration of standard Kubernetes deployments allow anonymous access to kubelet. TeamTNT used this misconfiguration to gain access to exposed Kubernetes instances and run cryptomining malware in the containers.

    This campaign was reported by Palo Alto Networks who described a new malware called Hildegard that was first seen in this campaign. In this campaign there was no use of container images. The malicious functionality was carried out using a reverse shell and abusing containers that were already running.

    Finding containers and nodes that could be attacked was accomplished by two tools: masscan (a tool that was described in the previous section) and kubelet. To evade detection this campaign uses LD_PRELOAD as described in the previous section and it deletes the scripts immediately after their execution.

    The campaign dropped two files: Peirates, a penetration tool for Kubernetes that steals cluster credentials, and BOtB, a tool for performing a container breakout using known vulnerabilities.

    To establish a connection with the Command and control (C2) server the malware used tmate or the Tsunami bot. It is unclear how the group decides which tool to use.

    In this campaign the Tsunami bot was packed using Ezuri in an attempt to evade detection. The process name of the bot was set to ‘bioset’ to masquerade as a legitimate process. This process name was used by the group in previous campaigns.

    Windows Targeting Attempt?

    While investigating TeamTNT’s infrastructure, we noticed that two Windows PE files had been downloaded from one of the domain names according to VirusTotal. A screenshot from VirusTotal is shown in Figure 47.

    Figure 47: Windows binaries downloaded from TeamTNT’s infrastructure in February 2021.

    The first file, sniffer.exe, is a compiled AutoIt script. A part of the script is shown in Figure 48. The script downloads WinPcap and tries to steal sensitive data from network traffic. It looks for keywords of usernames, passwords, credit card information, cookies, etc.

    Figure 48: Part of AutoIT script that uses WinPcap to steal sensitive data transferred over the network.

    The second file, svchost2.exe, runs an XMRig Miner. A code reuse analysis of the file is shown in Figure 49. The file “installs” itself to the user’s home folder as the file name notepad.exe. The mining software is compiled with CUDA support to take advantage of a NVIDIA graphics card that might be available on the compromised machine.

    Figure 49: Code reuse analysis of svchost2.exe shows that the file executes a XMRig Miner.

    While we were not able to attribute these files to a campaign, the files are aligned with TeamTNT’s TTPs. Since the first campaign in this report, the threat actor has been stealing credentials and installing cryptominers on servers. It is possible the threat actor was just testing against a new target type, never manifesting into a full-fledged campaign.

    When the cryptominer is executed, it drops a driver to the user’s AppData\Roaming\WinCFG\Libs folder. From gene analysis, this driver was identified as WinRing0x64 from OpenLibSys. The driver allows user space applications to access ring 0, essentially giving the process unfettered access. This driver is part of XMRig for Windows. The miner uses the driver to access MSR registers to improve the mining performance. While the driver is part of a legitimate application, it does provide a loophole that can be used to bypass a trust boundary.

    Figure 50: Analysis of WinRing0x64 driver installed by the XMRig Miner.

    Der FrĂŒhling 2021 (Spring 2021)

    During the Spring of 2021, TeamTNT expanded their credential stealing. In a shell script found by Trend Micro, the threat actor had expanded their search to the following applications and services:

    • SSH
    • AWS
    • Docker
    • S3
    • GitHub
    • Shodan
    • Google Cloud
    • Ngrok
    • Pidgin
    • FileZilla
    • HexChat
    • MoneroGuiWallet
    • CloudFlared
    • Davfs2
    • PostgreSQL
    • SMB

    The script, shown in Figure 51, searches for the files but does not exfiltrate the data. It’s not known if and how TeamTNT exfiltrated the identified files as part of the campaign.

    In addition to the credential search, the threat actor also started to enumerate data from the cloud environment that it was running on. Figure 52 shows a snippet of the script that uses AWS CLI to extract data.

    Figure 51: Script by TeamTNT searches for files that normally hold credentials.

    According to Trend Micro, close to 50,000 IP addresses running Kubernetes were compromised between March and May of 2021. The majority of the machines were located in China. The machines are predominantly hosted by cloud providers. This distribution is similar to what Lacework Labs reported in January the same year but with a much larger volume.

    Figure 52: Snippet of a script that uses AWS CLI to enumerate data from AWS.

    Der Sommer 2021 (Summer 2021)

    During the Summer of 2021, TeamTNT continued to target unsecured Docker and Kubernetes servers. Due to other threat actors using some of TeamTNT’s scripts during the Spring of 2021, TeamTNT added some new ways to identify their scripts. The threat actor announced the changes on their Twitter account as can be seen in Figure 53.

    Figure 53: TeamTNT announces via their Twitter account that all scripts from now on are “tagged” to ensure correct attribution.

    Figure 54 shows the first few lines of a script file that was used during the campaign. The file includes the information that the threat actor claimed would be added. Further down in the file is a URL from where the script was downloaded from.

    Figure 54: First few lines in the script file used during Summer 2021.

    TeamTNT also stated on their Twitter that they were going to be more “transparent” about their ongoing campaigns. As part of the Tweet, they included a link to a “beta dashboard.” Figure 55 is a screenshot of the dashboard. From the dashboard, it can be seen that the “Chimaera” campaign started on July 25, 2021 and vulnerable Docker, Kubernetes and WeaveScope services were being targeted.

    Figure 55: Screenshot of Chimaera dashboard.

    As in previous campaigns targeting vulnerable Docker instances, the use of masscan/pnscan with zgrab was used in the Summer to find the instances. Figure 56 shows the payload executed on the vulnerable machines. First, it tells Docker to download an alpine image that downloads the scanning script and infects the machine with a miner. In addition, a WeaveScope probe is installed on the machine.

    Figure 56: Function in the scanner script that exploits insecure Docker services.

    TeamTNT also made some changes to the wallet. Instead of having the wallet address hard-coded in the script, the threat actor added functionality that allows for rotating the address without changing the scripts. Figure 57 shows how the script fetches the latest wallet from the threat actor’s server.

    Figure 57: Added functionality to download the most recent wallet. If the request fails, a hard-coded backup address is used.

    Soziale AktivitÀt (Social Media Activity)

    For being a threat actor, TeamTNT maintains a public persona on Twitter. The Twitter account @HildeTNT, shown in Figure 58, was created in August 2020. The first campaign of the threat actor was reported in May 2020, while we have identified some activity dating back to October 2019. The account was created during the Summer of 2020 when many reports covering the actor’s activity were published. Based on the information provided in the profile their region is Germany.

     Figure 58: Screenshot of TeamTNT’s Twitter profile.

    In the graph presented in Figure 59, the threat actor is active on Twitter during all hours of the day. The data presented in the figure has been adjusted to UTC time zone. If we assume TeamTNT is based in a European time zone, we can conclude that the “spike” in number of tweets corresponds from late afternoon until evening time in Europe.


    Figure 59: A graph showing the correlation between hours of the day (in UTC) and number of tweets.

    Plotting the activity on a timeline we can see when the threat actor has been most active and any potential downtimes. In Figure 60 we can see that the most socially active period was from the middle of January 2021 until the middle of May 2021. There is a less active period at the end of 2020 which correlates to the Christmas holidays and New Year. It appears as the activity might be slowing down.


    Figure 60: A graph showing the correlation between hours of the day (in UTC) and number of tweets.

    Most of TeamTNT’s tweets are in German and the content varies from commenting on political subjects and current affairs (like COVID-19 vaccination), to discussing their activities and replying to researchers that post content related to the group. Figure 61 shows their response to a Trend Micro report.


    Figure 61: Tweet by TeamTNT replying to a research article made about them. Translated from German.


    In March 2021, TeamTNT replied to a tweet (later deleted) pointing out that someone else was using their tools and an attack was falsely attributed to the group. According to TeamTNT, the scripts used by the copycat were at least six months old.


    Figure 62: A reply by TeamTNT to another user on Twitter. Translated from German.

    In June, Palo Alto Networks’ Unit 42 released a report that attributed TeamTNT to a campaign in which appeared to contain a number of scripts and tools that implemented similar techniques to those used by another cryptojacking group, yet had a number of differences in implementation and usage. TeamTNT replied to the author of the blog in a series of tweets claiming that it was not a campaign and tools used by them but rather by someone else. They shared part of the script they own and use in their current campaigns in order to prove their point. The script (Figure 64) was hosted on their site teamtnt[.]red/blog/Kubernetes.txt.

    The group responded to other tweets that mentioned this blog, saying: “Das ist KEINE TeamTNT Kampagne!” (from German: “This is NOT a TeamTNT campaign!”). The threat actor has a history of commenting on previous reports documenting their activity. Sometimes they retweet the links to the report or comment on statements. They haven’t refuted previous campaigns which suggests that they want to take credit for their activity. Based on their previous behavior, we assess that the refuted campaign is not by TeamTNT and instead by an imitator.


     Figure 63: TeamTNT’s reply to Palo Alto’s research from June 2021.

    Figure 64: Script shared by TeamTNT.

    Werkzeuge (Tools)

    Tsunami (Kaiten)

    TeamTNT uses an IRC bot malware known as Tsunami. Figure 65 shows the code reuse analysis of the bot used in the first set of campaigns. Tsunami allows the operator to perform DDoS attacks against targets or execute commands on the infected machine.

    Figure 65: Code reuse analysis of a Tsunami sample used by TeamTNT.

    The source code for the bot was published in 2014. A forked and updated version called ziggystartux is available on GitHub. Figure 66 shows the GitHub repository for the project.

    Figure 66: GitHub repository of ZiggyStarTux.

    The bot used by TeamTNT does not appear to have been compiled from this code. Instead it appears to have been compiled from an earlier version. There are multiple repositories in GitHub hosting the original published code. All of these have the bot version string found in the binary used by TeamTNT, as well as support for the same commands. The commands supported by the bot are shown in the code snippets below.

    TeamTNT’s Configuration

    As can be seen in Figure 67, the bot is setting a “fake” application name to kthreadd, masquerading as a kernel thread.

    Figure 67: Changing the name of the process to kthreadd.

    The bot has two servers in its configuration. The servers are:



    Rathole is an open-source Unix backdoor with its code hosted on GitHub (Figure 68). A code reuse analysis is shown in Figure 69. The backdoor can be compiled on standard Linux distributions, it supports blowfish encryption, process name hiding and preferable shell.

    Figure 68: GitHub repository hosting the Rathole backdoor.

    Figure 69: Code reuse analysis of Rathole binary used by TeamTNT.

    The difference between the source and the binary is that the string ‘teamtnt’ is added to the encryption and decryption routine.

    Figure 70: Screenshot showing the encryption key used by the backdoor.

    The file was first submitted to VirusTotal on October 6, 2019, before the first recorded evidence of TeamTNT’s activity.


    Ezuri is an open-source ELF crypter. The project is hosted on GitHub. Figure 71 shows a screenshot of the GitHub repository.

    Figure 71: GitHub repository of Ezuri crypter hosted on GitHub.

    The crypter uses AES in Cipher Feedback (CFB) mode to encrypt the payload. When the crypter is executed, the payload is decrypted and executed from memory. Figure 72 shows the main and decryption function.

    Figure 72: Ezuri’s main function and decryption logic.

    Figure 73 shows the runFromMemory function. The execution from memory is achieved by first creating a memory file via the Linux syscall memfd_create. The decrypted content is written to the memory file. Following this, the process is forked and the spawned child executes the memory file via the execve syscall.

    Figure 73: Source code of the function that executes the decrypted payload from within memory. is a post-exploitation tool for Unix systems written by Giuseppe Corti. It’s open-source and hosted on GitHub. Figure 74 shows a screenshot of the GitHub repository. It uses credentials found on the exploited host to try to access other machines that are part of the SSH known_hosts database. It has the ability to execute a command on all machines that it manages to log into.

    Figure 74: GitHub repository for punk.


    The libprocesshider is a source code-available project on GitHub. A screenshot of the repository is shown in Figure 75. The project is compiled as a shared object. If it is loaded using LD_PRELOAD it “hooks” some libc functions which allows the library to hide a process from commands like ps, lsof, and top.

    Figure 75: GitHub repository for libproccesshider.


    Tmate is an open-source tool that provides an easy and secure way to share the terminal. It establishes a secure connection over SSH to the website and generates a random URL for each session. The user can share the URL with other trusted users. Tmate supports all popular operating systems, including GNU/Linux, macOS, and BSD systems.

    Figure 76: Screenshot from the official tmate site.


    Masscan is a TCP port scanner written by security researcher Robert Graham, also known as ErrataRob on Twitter. The scanner has been designed to scan the IPv4 address space very quickly and can be used for internet-wide scanning. To achieve this speed it needs to use a userland-based network stack.


    Pnscan, also known as Peter’s parallel Network Scanner, is a similar tool to masscan. It can be used to scan an IPv4 network for SSH, FTP, SMTP, Web, IDENT, and other services. The source code is hosted on GitHub.

    Tiny SHell

    Tiny SHell (tsh) is an open-source Unix backdoor, divided into client and server, written in C. It is small in size and supports multiple file transfers.


    MimiPenguin is an open-source tool thal extracts login passwords similar to Mimikatz in Windows. It dumps processes that are loaded into memory and extracts lines that may contain cleartext passwords.

    Figure 77: Screenshot of the GitHub project MimiPenguin.


    Mimipy is a cross-platform and open-source tool that dumps passwords from processes in memory. It is based on the MimiPenguin mentioned above. Mimipy has other features that include: extracting credentials from browsers and HTTP servers, support for lightDM, and overwriting passwords.


    Break out of the Box (BotB) is an open-source tool designed to be used by pentesters. It has many capabilities: exploits known container vulnerabilities to break out of the container, find and use Kubernetes and GCP secrets, push data to an S3 bucket and more.


    Diamorphine is a Linux Kernel Module rootkit written by Victor Ramos Mello. It’s hosted on GitHub and has support for kernel versions 2.6.x/3.x/4.x/5.x. It can hide processes, files and elevate a given user to root. Interactions with the rootkit are via signals.

    Figure 78: Screenshot of the GitHub project Diamorphine.

    Docker Escape Tool

    Docker Escape Tool is an open-source tool hosted on GitHub that identifies Docker containers and tries to escape the container using known techniques. The purpose of the tool is to assess the security of containers. Implemented techniques include: mount Docker Unix socket, reach the Docker daemon on the default ports, exploit a vulnerability in RunC that allows attackers to overwrite the host RunC binary (CVE-2019-5736).

    Figure 79: Screenshot of the Docker Escape Tool repository on GitHub.

    Das Fazit (Conclusion)

    Illicit cryptomining has become the major threat to Linux servers and cloud environments. TeamTNT is one of the predominant threat actors in this field. TeamTNT’s activity can be traced back to the Fall of 2019 in attacks against Redis server. From this humble beginning, the threat actor has changed its targets towards servers running Docker and now currently Kubernetes clusters. Most of the tooling and tactics used by the group is similar to other threat actors in the field. They predominantly structure their attacks around a set of multiple shell scripts but also use open-source and source available tools. The shell scripts are rarely written to disk, instead they are downloaded using curl or wget and “piped” directly into a shell interpreter. This can make it hard to investigate what has happened to a compromised machine as no artifacts on the machine exist. They also clear logs to make the investigation even harder.

    Since they are competing with other cryptojacking-focused threat actors, TeamTNT employs different techniques to ensure that only their cryptominer is running. In early campaigns, we have seen them “plug the hole” used to compromise the machine, for example, by adding firewall rules to block external network connections to access the vulnerable service. TeamTNT has also used different techniques for hiding their processes on the machine, including userland rootkits. Some of the scripts also include lists of other known cryptominers that the threat actor tries to kill on the machine. This is a common technique employed by many other threat actors in this field which essentially turns the compromised machine into a game of “King of the Hill.”

    What separates TeamTNT from other major threat actors in the cryptojacking field is their public presence on the clear web. They maintain a public appearance on Twitter and frequently tweet. Based on the public persona, it can be assumed that they are based in Germany. The threat actor commonly interacts with German politicians, tweets about their ongoing campaigns, and comments on reports by the security industry. The majority of these comments are to take credit for their work. During the Spring of 2021 some campaigns were attributed to TeamTNT but the threat actor refuted that it was their work. This suggested the emergence of an imitator reusing some of TeamTNT’s older shell scripts. It remains to be seen if this will affect their activity and if they will continue to target Kubernetes clusters or if they will move on and target new cloud infrastructure.


    Pre-February Campaign












    SSH Key

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIzB9hz7bNT6qtQKCMcitaaxEB9RyJEZuumE+gUMrh6hg3ccSMg9qnAlS/Lmw5SwwLJQXMB5WuhclPJsVawuP+pfsm1ZiGF2JnczEW5kBw1o5Fl/6WOV1p9MOaXHAbpi7o/5Zauu3lTktyIWuP5R9l/2pUWcFZInnaiOr1KNtCBPisNYbZ4FWAQVGwXzUWZ/ZE7SYIoOUm3EJihPPiTulegUmIzc7TzrnEn9M3U8K+LVFye+wDeSC3WNYwfjGQJA4aFsANOiz89olh77G7IaDR8LghNfVVkRjaJ6onDZwb2CZWSivkFsdYtL6690S407eqoes7wkJudo9Qxsn9wxNv

    February 2020 Campaign





































    32-bit Archive





    XMRig Miner


    64-bit Archive





















    XMRig Miner





    Used to determine IP

    Main server

    Exfiltration server

    Old server still used by some scripts

    Miner CC

    Command center


    Spring 2020










    3876b58d12e27361bdfebd6efc5423d79b6676ca3b9d800f87098e95c3422e84 (Trend Micro)

    459190ba0173640594d9b1fa41d5ba610ecea59fd275d3ff378d4cedb044e26d (the second script)










    Summer 2020














































































    Fall 2020





    Host malicious scripts and binaries


    Used to obtain the IP address of the victim













    Winter 2021

    Attacking Kubernetes




    The.borg[.]wtf (

    Host malicious scripts and binaries

    Used to obtain the IP address of the victim (

    Host malicious scripts and binaries (

    Host malicious scripts and binaries (123.245.9[.]147)

    C2 server and runs IRC server (13.245.9[.]147)

    C2 server and runs IRC server

    C2 server and runs IRC server

    C2 server and runs IRC server

















    xmrig (oneroocean)


















    Windows Targeting







    Spring 2021







    Summer 2021















    • teamtnt[.]red
    • chimaera[.]cc


    Track the latest malware variants and threat actors

    © 2022 All rights reserved
    Integrate with EDRs like CrowdStrike and SentinelOne to automate alert triage & response tasks.Integrate with EDRs like CrowdStrike and SentinelOne Learn more