{
	"id": "a993f30a-7b9e-4cbd-b138-bf4f6484004e",
	"created_at": "2026-04-06T00:17:51.255693Z",
	"updated_at": "2026-04-10T03:32:46.193625Z",
	"deleted_at": null,
	"sha1_hash": "4c965dbd44ffbfe6ab39efb6ff4849607bc90b3b",
	"title": "TeamTNT Cryptomining Explosion ??????",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 11385669,
	"plain_text": "TeamTNT Cryptomining Explosion 🧨\r\nBy Intezer\r\nPublished: 2022-02-18 · Archived: 2026-04-05 19:46:26 UTC\r\nThis post was originally published as a white paper in September 2021. Get the full report as a PDF here.\r\nZusammenfassung (Executive Summary)\r\nOver the past year the TeamTNT threat actor has been very active. TeamTNT is one of the predominant cryptojacking threat\r\nactors currently targeting Linux servers. This blog investigates the threat actor’s activity and their Tactics, Techniques and\r\nProcedures (TTPs)—providing all of this information in one place so security teams can better detect and prevent attacks\r\nfrom TeamTNT.\r\nBased on our findings, we can conclude that they have been active since the Fall of 2019, six months before the first public\r\nreport on the threat actor’s activity. As of this writing, TeamTNT is mainly focused on compromising Kubernetes clusters.\r\nPrior to this, they used to target servers running Docker and Redis. We at Intezer also uncovered Windows binaries hosted\r\non a TeamTNT server that was potentially an experiment to target Windows machines.\r\nMuch of the threat actor’s tooling has stayed consistent throughout their different campaigns. The majority of their tools are\r\nbased on shell scripts but they also use some “tried and tested” compiled binaries in the attack chains. For example, the use\r\nof the Tsunami malware, first documented by Trend Micro, has been a staple of TeamTNT’s campaigns since October 2019.\r\nIn addition to cryptojacking, a second objective for the threat actor has been to exfiltrate information about compromised\r\nhosts.\r\nAs early as the Winter of 2020, Intezer saw the threat actor utilizing novel techniques to steal SSH credentials from the\r\ncompromised machine when it was being used by administrators.\r\nTeamTNT has employed techniques to hide their activities on compromised machines, making incident response\r\ninvestigations more difficult. All of their scripts are designed to be executed without being written to disk or self deleted\r\nafter execution. They have used techniques of hiding their running processes by mounting an empty folder over the process\r\nentry within the procfs, or by using UserLand and kernel level rootkits.\r\nThe threat actor maintains a public persona on Twitter using the handle HildeTNT. The majority of their tweets are written in\r\nGerman and the account’s location is set to Germany. In addition, many comments in the shell scripts used by the threat\r\nactor are written in German. Therefore, it can be assumed that TeamTNT’s country of origin is Germany. Much of their\r\ninteraction with the security industry is via commenting on reports covering their campaigns, mostly to point out incorrect\r\nconclusions. During the Spring of 2021, TeamTNT refuted some campaigns attributed to them. The tools used in these\r\ncampaigns were based on some of TeamTNT’s older scripts but not something they currently were using. This suggests\r\nanother threat actor has started to copy TeamTNT.\r\nTable of Contents\r\nDer Anfang (The Beginning)\r\nDer Frühling 2020 (Spring 2020)\r\nDer Sommer 2020 (Summer 2020)\r\nDer Herbst 2020 (Fall 2020)\r\nDer Winter 2021 (Winter 2021)\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 1 of 46\n\nDer Frühling 2021 (Spring 2021)\r\nDer Sommer 2021 (Summer 2021)\r\nSoziale Aktivität (Social Media Activity)\r\nWerkzeuge (Tools)\r\nDas Fazit (Conclusion)\r\nIoCs\r\nDie Einführung (Intro)\r\nSince the introduction of Amazon Web Services (AWS), there has been a steady migration from on-premise to cloud\r\ndeployments. As part of this migration, the security around services has also changed. On-prem deployments can sometimes\r\nbe more forgiving as a misconfigured service would also be behind a corporate firewall, resulting in it not being exposed to\r\neveryone over the internet. A misconfigured cloud service can be low-hanging fruit for an attacker. Palo Alto Networks\r\ninvestigated the attacks against cloud servers during the Spring of 2021 via a Docker honeypot, finding that it was attacked\r\nabout every 90 minutes. Of these attacks, around 76% were by cryptojacking threat actors. One of the most active actors in\r\nthis field is TeamTNT.\r\nThe first public report on TeamTNT was published in May 2020 by Trend Micro and covered attacks against servers running\r\nexposed Docker instances. While this is early activity, it is not the earliest that can be attributed to the threat actor. As part of\r\nthis report, we will share our knowledge about campaigns that took place during February the same year and also provide\r\nevidence that TeamTNT has been active since at least October 2019.\r\nThe first set of campaigns by TeamTNT targeted only Redis instances. Throughout their over a year and a half tenure, they\r\nhave migrated away from focusing on Redis to instead target Docker services and most recently Kubernetes clusters. This\r\nincludes the use of cloud monitoring software to deploy cryptominers on vulnerable servers.\r\nThe techniques and tools used by the threat actor have slightly evolved over time but the general desired outcome has been\r\nthe same. The first campaign that we at Intezer uncovered, taking place around February 2020, used techniques for stealing\r\ncredentials and tried to stay hidden on the compromised system. Many of the tools that are still used were leveraged in the\r\nfirst set of campaigns.\r\nFor example, the Tsunami Internet Relay Chat (IRC) bot and the backdoor known as Rathole were used. The majority of\r\ntools used by TeamTNT are either open-source or source-code-available but we have also identified some custom written\r\ntools and a possible pivot to targeting Windows machines. This is an interesting deviation, since TeamTNT appears to be\r\nheavily invested in targeting *NIX servers. The more recent campaigns have targeted Kubernetes and cloud workloads with\r\nthe goal to steal cloud-related configurations and credentials, in addition to running cryptominers.\r\nTeamTNT is a bit of an anomaly when it comes to cryptojacking threat actors. They have a public presence on the clear web\r\nwhile most threat actors stay hidden in the shadows. The threat actor has a public profile on Twitter and sometimes interacts\r\nwith the research community tweeting about the success of their current campaigns. Based on their social media account\r\nthey are located in Germany and the majority of their tweets are written in German. The threat actor’s interaction with the\r\nresearch community mostly takes the form of commenting on incorrect conclusions made by analysts.\r\nDuring the Spring of 2021 some new campaigns were uncovered that looked to have all the makings of TeamTNT. In both\r\ncases, the threat actor was quick to point out that it was not their campaign but rather someone was reusing their old scripts\r\nto make it look like it was them. Prior to this, TeamTNT had not refuted any campaigns attributed to them. Instead, they\r\nwere mostly using Twitter to show off their capabilities.\r\nThe activity from TeamTNT does not appear to be slowing down. They continue to reuse their tools in their attacks. This\r\nmay be because their operations are unhampered by security tools. Because of this and the potential misinformation about\r\nthe threat actor, we decided to take a deeper dive into TeamTNT’s activities to gain a better understanding of their timeline\r\nand Tactics, Techniques, and Procedures (TTPs). With this knowledge, we aim to organize all of this information properly\r\ninto one resource to help security teams better detect and prevent attacks from this threat actor.\r\nDer Anfang (The Beginning)\r\nThe first public report on TeamTNT’s activity was published by Trend Micro in May 2020. While this report covers some of\r\nthe early activities, it does not include the initial activity that can be traced back to the threat actor. One of the network\r\nindicators of compromise in this report is the domain name teamtnt[.]red. This domain was registered on February 10, 2020\r\nand is one of the first references to ‘TeamTNT’ by the threat actor. This infrastructure was used by the threat actor against\r\nattacks on unprotected Redis servers. The initial “setup” script used in this campaign was uploaded to VirusTotal on\r\nFebruary 26, 2020. The setup script downloads the rest of the modules used in the attack. Many of them are shell scripts that\r\nare 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\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 2 of 46\n\ndownloaded and executed by the different modules. The oldest files that we were able to capture were added to the server\r\nfour days after the domain name was registered, giving us a good indication of when the initial campaign might have started.\r\nFigure 1: Diagram showing how different parts are downloaded and executed when the threat actor compromises an\r\nunprotected Redis server.\r\nThe Setup\r\nThe infection on the machine started with the execution of the setup.sh shell script that was located in a subfolder called\r\nload. This script is responsible for downloading and executing the other parts of the toolchain used by TeamTNT. The file\r\nhas a comment on the top as can be seen in Figure 2. According to the comment, the file was the module scan/pwn Redis\r\nServer Setup.\r\nFigure 2: The first few lines of the setup.sh file. The file sets up the machine to scan and infect other Redis servers.\r\nOne 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\r\ncalled whois2.irc.sh for this binary. The binary installed by this shell script is an instance of the Tsunami malware. For more\r\ninformation about this malware, see the Tools section.\r\nTwo additional shell scripts were downloaded from the server (hosted at teamtnt.red), tmp.min.sh and sysinfo.txt. The first\r\nshell script installs the miner on the infected machine while the second collects host information.\r\nFollowing the download and execution of the shell scripts, the scripts try to hide their process. The shell commands executed\r\nare shown in Figure 3. To hide the process, a shell script is created at /bin/hid. The shell script hides the process by first\r\nmaking a copy of /etc/mtab. After this, it mounts an empty folder over the process’s folder under /proc. Lastly, it overwrites\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 3 of 46\n\nthe /etc/mtab file or symbolic link with the copy it made before the mount. These steps hide the process from programs that\r\nwalk the /proc filesystem, for example, ps and top. If an admin checks the mtab file the mount entry is not present, but\r\nlisting the mount points by executing the mount command shows bind mount. After the setup executes the hid shell script it\r\nmounts another instance of the proc filesystem under /proc. This essentially results in undoing the process performed by the\r\nhid shell script.\r\nFigure 3: Section of the setup script that creates a shell script for the hiding process.\r\nTo prevent other threat actors from also compromising the Redis instance, the setup script added iptables rules to only\r\naccept connections on port 6379 from localhost. The shell script also performs a request to the C2 server that appears to be\r\nfor logging the infected machine’s IP address.\r\nDuring this campaign, the threat actor focused on compromising unprotected Redis servers. The setup script creates the\r\npayload that is executed on the Redis servers. The code is shown in Figure 4. It’s using Redis’s FLUSHALL issue to create a\r\ncron job that downloads a setup script. This setup script is almost identical to the main setup script, except that it doesn’t set\r\nup Tsunami.\r\nFigure 4: Code for creating the Redis payload.\r\nThe setup script checks if Tsunami and bioset are running. If they are, the script restarts the processes to hide them with the\r\nhid shell script. If they are not running, it downloads them followed by starting and hiding them.\r\nTo find other Redis servers to infect, the threat actor uses pnscan. The setup script downloads the source code for the\r\nscanner and compiles it. The scanner is “installed” at /usr/sbin/dbus-daemon. Another shell script is downloaded that\r\nhandles scanning and sending the payload to any found Redis servers. When all stages have been downloaded and started,\r\nthe setup script removes itself from the infected host.\r\nDDoS Bot Setup\r\nThis shell script downloads and installs the Tsunami DDoS bot. The script installs the binary to two different places based\r\non if the script was executed as root or not, Figure 5. If it is executed as root, the malware is installed to /bin/kthreadd,\r\notherwise, it is installed to /tmp/.tmp. Before installing the malware, the script flushes and deletes all the iptables chains to\r\nensure it can connect to the C2 server without any resistance.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 4 of 46\n\nFigure 5: The script installs the bot under /bin if it has root permissions. Otherwise, it is installed into the /tmp folder.\r\nGather Information About the System\r\nThe 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\r\nin case the script is executed multiple times on the same machine. Figure 6 shows the check for the lock file. If it exists, the\r\nscript exits early. If this is the first time it’s executed, it starts collecting information about the machine. In the same figure,\r\nthe logic used to determine the available RAM is also shown.\r\nFigure 6: Part of the script that checks if system information has already been collected for the machine. If it hasn’t, it gets\r\nthe available ram.\r\nThe script also collects: username of the user executing the script, CPU speed, how long the machine has been running, if\r\nit’s 32 or 64-bit, the number of CPU cores, and which Linux distribution. All this information is sent to the threat actor’s\r\nserver via the wget command shown in Figure 7. When the script is done, it deletes itself.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 5 of 46\n\nFigure 7: Exfiltration of host information to the actor-controlled server.\r\nCapture SSH Credentials\r\nThe s_poor.ssh.sh shell script is downloaded by the setup script and according to the comment at the top of the file, shown\r\nin Figure 8, it is used to steal SSH credentials.  \r\nFigure 8: Comment at the top of the SSH credential stealing module.\r\nThe 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\r\nthreat actor-controlled server. As can be seen in Figure 9, the script adds the alias code to the bashrc file for the root user\r\nand all the normal users on the machine. After this, when a user uses SSH to connect to another machine, strace is used to\r\nlog the activity to a log file. The cron job seen added in the same figure executes the upload script every five minutes.\r\nFigure 9: SSH credential collection via strace. The log files are uploaded every five minutes via a cron job.\r\nThe upload script is relatively simple, shown in Figure 10. It checks if the log files exist. If they do, it uses curl to upload\r\nthe files before it is removed.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 6 of 46\n\nFigure 10: Upload script for the strace logs.\r\nScan for Other Machines to Compromise\r\nThe dbus-config file downloaded by the setup script is a Redis exploit/scan module. As can be seen in Figure 11, it uses\r\npnscan that was downloaded and compiled earlier. It scans the whole IPv4 space for other Redis servers. If it finds another\r\nserver, it uses the Redis client on the machine to send the payload, which causes the exploited service to set up a cron job\r\nthat will download the setup script.\r\nFigure 11: Redis scanning functionality.\r\nThe results are uploaded to a threat actor-controlled server as can be seen in Figure 12.\r\nFigure 12: Scan results uploaded to a threat actor-controlled server.\r\nCryptomining\r\nThe tmp.min.sh shell script’s main job is to set up the mining process. It downloads the miner, a watchdog process, and the\r\nconfiguration file. The installation process depends on if the shell scripts have root permissions or not. If they do, a second\r\nstage is downloaded and executed to perform the root setup. Otherwise, the scripts download and install the files into the\r\ntemp directory. The configuration is modified to be unique for each infected host. A worker ID is created based on the\r\nusername of the user executing the script and the machine name. The miner used is a fork of XMRig called XMRigCC. It\r\nprovides a dashboard that can be used to control the miner. The command center used in the campaign was located at\r\n80.211.206.105. \r\nWatchdogd Process\r\nThe watchdogd binary is a simple application written in C++. A code reuse analysis is shown in Figure 13. Its sole purpose\r\nis 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\r\nto the system is repeated.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 7 of 46\n\nFigure 13: Code reuse analysis of the watchdogd binary.\r\nNarrenKappe\r\nNarrenKappe, which translates to jester hat, is a mining setup script that is executed if the script has root-level permissions.\r\nSince it has higher permissions, it performs some additional actions than when executed as a normal user.\r\nFirst, it checks if the watchdog process is running and exits the setup. Otherwise, it checks if old files from a previous\r\ninfection exist on the machine and removes them. Following this, it removes all the cron jobs on the machine. It tries to\r\nclean out other infections using the commands in Figure 14.\r\nFigure 14: Commands used to clean the system.\r\nThe script downloads a 64-bit or 32-bit miner depending on what is supported as can be seen in Figure 15.\r\nFigure 15: Download and installation steps used by the mining setup script.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 8 of 46\n\nThe mining configuration is modified to include a unique identifier for the infected host. The logic is shown in Figure 16.\r\nFigure 16: Logic for modifying the mining software’s configuration file with host information.\r\nThe script ensures the processes are started again if the machine is rebooted. The script adds either a System V init script or\r\na systemd service depending on what is used by the system. The commands executed in either path are shown in Figure 17.\r\nFigure 17: Code for adding either a System V init script or a systemd service.\r\nIt ensures that the service is running by adding a cron job that is executed every hour, Figure 18.\r\nFigure 18: Cron job executed every hour.\r\nIn addition to setting up the mining process, the script also starts another script that: scans for Redis servers, downloads and\r\nexecutes a post-exploitation tool called punk.py, and exfiltrates SSH keys, bash history, known SSH hosts, and the host file.\r\nRemoving All Traces\r\nThe cyo.sh script is run by the mining setup script if the watchdog process is already running. The script is used to clean out\r\nthe 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\r\nlogs for the users reboot, hilde, and .r00t are cleared before it uploads the bash history of the root user to the threat actor’s\r\nserver.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 9 of 46\n\nFigure 19: Log cleaning for three user accounts and exfiltration of the root user’s bash history.\r\nFolgen Sie dem Semmelbrösel\r\nUsing information that was present in this campaign, we were able to find some earlier activity. The rathole binary used in\r\nthis campaign was uploaded to VirusTotal as early as October 2019. Figure 20 shows a screenshot of the submission date.\r\nFigure 20: First submission of the rathole binary to VirusTotal.\r\nA script file that was included in the archive with the miner but not used in this campaign included the functionality to\r\ndownload punk.py from a server located at 116.62.122.90. This IP was found referenced in a shell script file called\r\nash.sh that was uploaded to VirusTotal in January 2020. It has very similar functionality as observed in this campaign. An\r\nout-commented line in the file references the URL http[:]//3[.]215[.]110[.]66/src/bioset. Additionally, the script adds an\r\nSSH key and creates a user called hilde with the password gard, Figure 21.\r\nFigure 21: Shell script from January 2020 that creates a hilde user and adds a SSH key.\r\nDer Frühling 2020 (Spring 2020)\r\nAs reported by Trend Micro on May 6, 2020, TeamTNT targeted Docker daemon ports and abused them to install\r\ncryptomining malware and DDoS malware. This is a shift from their previous targeting of Redis servers and appears to be\r\nthe first documented evidence of the group targeting exposed Docker daemon ports and using them to spread malware.\r\nAs in the previous campaign, the group used several shell scripts to carry out the attack. The first script mxutzh.sh is used to\r\nbootstrap the infection by creating a container from an Alpine image. When the container is started, it uses the volume\r\nfunctionality to mount the host system’s root filesystem to /mnt inside the container. This gives the root user inside the\r\ncontainer the ability to modify the host machine as if it was root on the host machine. The container is set to download and\r\nexecute another script init.sh which in turn downloads and executes several shell scripts.\r\nThe use of scripts that download and execute the malicious functionality evades detection techniques because the image\r\ndoesn’t contain suspicious/malicious parts, therefore it will not be detected by static analysis tools such as image scanners.\r\nAs mentioned above the container is mounted to the filesystem of the host so that the scripts are executed on the host. The\r\ninit.sh implements the functionality for deleting other miners, installing admin tools and cryptomining malware,\r\nimplementing evasion techniques and spreading to other victims. Many of the same techniques were used in the earlier\r\ncampaigns.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 10 of 46\n\nFigure 22: Overview of the scripts executed in this campaign (as described by Trend Micro).\r\nmxutzh.sh\r\nFigure 23: Screenshot of mxutzh.sh\r\nAs can be seen in Figure 23, mxutzh.sh gets an argument in the form of an IP address from the victim machine. Using the\r\nopen-source tool called masscan the script scans a predefined list of ports. The function uses zgrab to identify if a Docker\r\nservice is listening on the port. ZGrab is an open-source application scanner created by the individuals behind Censys.io. For\r\nall Docker services found, the script uses the exposed port to spawn a new container from the Alpine image. Using the bind\r\nmethod, the root directory of the victim machine is mounted to the container filesystem. A shell command to download and\r\nexecute the init.sh script is set to be executed using sh shell as soon as the container is created.\r\nInit.sh\r\nFigure 24: Screenshot of init.sh\r\nThe init.sh script removes previous cronjobs named “COVID19” and “SARScov2” and then verifies that curl and bash are\r\ninstalled.  If not, the script installs them. Next, the script downloads and executes scripts that include other functionalities for\r\nthe attack.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 11 of 46\n\nThe container is created with /bin/sh shell (as set in mxutzh.sh) but it seems that the group decided to use bash for some\r\nscripts and sh shell for other scripts.\r\nWhen we examined the Uniform Resource Locator (URL) http://45.9.148[.]123/COVID19/init.sh in VirusTotal we\r\ndiscovered another init.sh file, submitted on April 30, 2020, about one month before Trend Micro released their report. At\r\nthe time of the report the file had four detections.\r\nFigure 25: VirusTotal screenshot for the second init.sh file.\r\nThe other init.sh script doesn’t implement new features, however, it uses a different hosting domain:\r\nhttp://kaiserfranz[.]cc, the domain registered on March 10, 2020.\r\nFigure 26: Screenshot of the second init.sh file.\r\nIt is interesting to note that the group included “COVID19” as part of the URLs used to download scripts. Both\r\ninit.sh scripts were uploaded to VirusTotal on April 30, 2020. Around this time the COVID-19 pandemic was spreading\r\nquickly around the world and countries entered lockdowns.\r\nFigure 27: Number of daily new confirmed COVID-19 cases from March to May 2020. Source: Our World in Data \r\nSome threat actors took advantage of the crisis and started abusing it as a theme for phishing activity knowing that people\r\nwere desperate for information related to the global pandemic. It is unclear if the use of the term “COVID-19” is part of an\r\nevasion technique since the group doesn’t make other attempts to hide its activity.\r\nClean.sh\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 12 of 46\n\nFigure 28: Screenshot of clean.sh script.\r\nThis script is responsible for: killing processes of other cryptominers, deleting cron jobs and files used by other threat actors,\r\nremoving containers that execute malware, and disabling monitoring services such as apparmor.\r\nDNS\r\nFigure 29: Screenshot of dns script.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 13 of 46\n\nThe init.sh script executes another script named dns. Based on the architecture of the victim system, a tool called dns3 (link\r\nto analysis) is downloaded and masqueraded as part of systemd. Based on the code relation this is Tsunami. It has 32-bit and\r\n64-bit versions, both versions which were submitted to VirusTotal on April 19, 2020. For more information check the Tools\r\nsection.\r\nFigure 30: Screenshot of dns3 in Intezer Analyze.\r\nConnection to Other Scripts\r\nThe IP 45.9.148[.]123 from the init.sh scripts in this campaign was resolved to vps.teamtnt[.]red on May 2, 2020 and\r\nlocated in The Netherlands. Based on VirusTotal the IP address is related to many malicious scripts, two of these files are:\r\nlan.redis.pwn.sh which was submitted on the day of the domain resolution and the second file minion_worker.sh was\r\nsubmitted a couple of days later.\r\nlan.redis.pwn.sh\r\nFigure 31: Screenshot of lan.redis.pwn.sh\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 14 of 46\n\nFigure 32: Graph showing the scripts executed by lan.redis.pwn.sh\r\nminion_worker.sh\r\nFigure 33: Screenshot showing minion_worker.sh\r\nThe minion-setup.sh script targets Redis and uses the URL http://45.9.148[.]123/MoneroOcean/sh/init.sh to download the\r\ninit.sh script that will be executed on the exposed Redis instance.\r\nBoth scripts (minion_worker.sh and lan.redis.pwn.sh) target Redis and they use the tools mentioned in the first captain\r\n(bioset and pnscan). Based on similarities in the functionality and behavior of the scripts we can conclude that these scripts\r\nwere part of the campaign that targeted Redis servers.\r\nDer Sommer 2020 (Summer 2020)\r\nThroughout the Spring and Summer of 2020, TeamTNT targeted exposed Docker containers. The exploitation techniques\r\nused during the Summer were very similar to the techniques used during the Spring. One key addition was the stealing of\r\nAWS credentials, as first reported by Cado Security. The threat actor scanned the home directories of the users on the\r\ninfected machine for the file ~/.aws/credentials. If the file was found, it would be uploaded together with the\r\n/.aws/config file to a server controlled by the threat actor.\r\nThe threat actor also started to publish information on their website that appears to have been collected during their\r\ncampaign. The screenshot of TeamTNT’s website, seen in Figure 34, shows a list of “free/open” sandboxes available on the\r\ninternet. Since the earliest campaign we detected the threat actor has been logging the external IP of the machines they have\r\ninfected. It is possible that they used this data to identify these sandboxes.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 15 of 46\n\nFigure 34: Screenshot from TeamTNT’s website. The website published unprotected sandboxes (Reproduced with\r\npermission from Cado Security: Team TNT – The Crypto-Mining Worm to Steal AWS Credentials 2020).\r\nDocker Exploitation\r\nIn the Spring activity, the shell script called mxutzh.sh was used to exploit Docker hosts. It would call a function named\r\npwn with three arguments. The first of these arguments was the same first argument passed to the mxutzh.sh file when it is\r\nexecuted. During the Summer, this logic was changed and it instead would get this value from a compromised server. Figure\r\n35 shows the changes. A similar script file was also used to target other machines on the same network. Figure 36 shows the\r\nfunction in the “lan” file that instead scans the local network.\r\nFigure 35: Pwn function called. The function uses a URL to determine the range of IPs to scan instead of it being passed\r\nonto the parent script file as an argument.\r\n36: Pwn function used to scan other Docker servers on the same network.\r\nThe pwn function was also changed a bit. During the Spring, it would execute a command to download an alpine image.\r\nThe image is started with the instruction to download an initialization shell script. In addition to this functionality, during the\r\nSummer campaign setup the shell script was also passed in as base-64 encoded data in case the first method failed. Figure 37\r\nshows part of the pwn function used during Summer. The threat actor also added instructions to perform the same attack\r\nusing an Ubuntu image in addition to the alpine image.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 16 of 46\n\nFigure 37: Part of the own function that is used to infect Docker servers with containers to mine Monero.\r\nPalo Alto Networks released a report in August 2020 on a new malware that they attributed to TeamTNT. The malware,\r\nnamed Cetus, infected one of the researcher’s Docker honeypots. Cetus essentially has two jobs, start the miner and infect\r\nother servers running Docker. This appears to be the first custom written malware used by the threat actor.\r\nSince the beginning of their activity, TeamTNT has tried to hide their activity on infected machines. In the early campaigns,\r\nthey would mount an empty directory over a running process’s folder in the procfs to hide it from outputs with top and ps.\r\nIn the Summer campaign, they took this further by using a Linux Kernel Module (LKM) rootkit. Figure 38 shows the\r\ninstallation of the rootkit. The rootkit called Diamorphine is an open-source rootkit hosted on GitHub.\r\nFigure 38: Setup script for Diamorphine. It installs kernel headers and build tools.\r\nThe script installs the kernel headers and tools needed to compile the LKM before it downloads the source code for the\r\nrootkit via git. After the module has been compiled, it loads the module. The rootkit is used to hide the miner. This is\r\nperformed by sending a signal 31 to the process. Figure 39 shows an example of this.\r\nFigure 39: Arrow points to a command to hide the miner via a signal to the rootkit.\r\nSSH Exploitation\r\nThe SSH exploitation technique was also updated during this time period. For example, more SSH related files are\r\nexfiltrated from the compromised host, as seen in Figure 40.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 17 of 46\n\nFigure 40: TeamTNT added more configuration and key files to its list to be exfiltrated from the compromised server.\r\nLike many other threat actors that target Linux servers, TeamTNT also uses the known_hosts file to find other machines\r\nthat it may spread to. In addition to this, TeamTNT scans the networks that the machine is connected to using pnscan, to see\r\nwhich other machines have port 22 listening. As can be seen in Figure 41, the result is added to the known_hosts file.\r\nFigure 41: TeamTNT scanning local networks for other machines that are listening on port 22.\r\nTo find keys that can be used to authenticate to these machines, the threat actor looks for id_rsa files in all home folders and\r\nchecks for defined IdentityFile configurations. Additionally, the bash history is checked for uses of both SSH and scp. The\r\nthreat actor uses similar techniques to find more servers to spread to. As examples, it checks: the host file for other\r\nmachines, defined HostName in the SSH config files, bash history, items in the known_hosts files, and processes connected\r\nto external IPs on port 22. Similar methods are also used to determine different user accounts that can be used to connect to\r\nthe machines. It’s worth noting that since the earliest TeamTNT campaigns we uncovered, the threat actor has exfiltrated the\r\nbash history files on machines they have compromised. It is possible that they have used this data to devise these methods\r\nfor gathering keys and IP addresses from other machines that can be used for lateral movements. Figure 42 shows the\r\ndifferent commands used.\r\nFigure 42: List of commands used by TeamTNT to find SSH keys, machines and user accounts that can be used to infect\r\nother machines.\r\nThe collected data is added to “master” lists that the script enumerates through. Each username and key is used for all\r\ndiscovered servers. If a successful login is achieved, a command is executed to download a setup shell script on the\r\nmachine. This logic can be seen in Figure 43.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 18 of 46\n\nFigure 43: For each enumerated host, the script tries to log in with the usernames and keys. If successful, the setup script is\r\ndownloaded and executed on the machine.\r\nIn addition to spreading to other machines the following files are downloaded:\r\ndocker-update (XMRig)\r\ntshd (Tiny SHell)\r\nkube (Tsunami)\r\nbioset (Rathole)\r\nDocker Containers\r\nIn addition to downloading “base” images from Docker Hub to set up the attack, Aqua Security released research on\r\nTeamTNT’s use of custom images. The images uploaded by the user account hildeteamtnt to the hub was categorized into\r\ntwo categories: “Simple and straightforward” images used for cryptomining and “Sophisticated” used for container\r\nescaping. The sophisticated images used the Docker Escape Tool, an open-source tool hosted on GitHub. Much of the\r\ntechniques and tools used were very similar to the threat actor’s previous activity.\r\nDer Herbst 2020 (Fall 2020)\r\nOn September 8, 2020 Intezer discovered that TeamTNT abused a legitimate cloud monitoring tool called Weave Scope. The\r\ntool gives the user full access to their cloud environment and is integrated with Docker, Kubernetes, the Distributed Cloud\r\nOperating System (DC/OS), and AWS Elastic Compute Cloud (ECS).\r\nWeave Scope is a powerful utility for working with microservices-based applications, as it has many features including:\r\ndetailed information about each container and processes running in them, memory usage of each container, links and\r\nconnections between containers, and the ability to start, stop, and open interactive shells in any of these containers.\r\nFigure 44: shows a screenshot of the Weave Scope dashboard.\r\nThis was the first time TeamTNT was found using a legitimate tool for the purpose of gaining control over the victim’s\r\ninfrastructure. By installing a legitimate tool such as Weave Scope the attackers gained all the benefits as if they had\r\ninstalled a backdoor on the server, with significantly less effort and without needing to use malware.\r\nWeave Scope is an open-source project and its installation is relatively easy. The attackers created a container based on an\r\nUbuntu image and used the mount functionality. This method was described in the previous section. At this point the\r\nattacker had full access to the filesystem of the victim machine, so they downloaded and installed Weave Scope as described\r\nin the project’s Git:\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 19 of 46\n\nFigure 45: Scope Weave install to Commands.\r\nThe dashboard of Weave Scope is accessible on port 4040. By exposing this port the attackers gained full access to all of the\r\nfeatures of this tool.\r\nThroughout the Fall of 2020, TeamTNT also expanded their TTPs around credential stealing to not only target stored AWS\r\ncredentials. In a report published by Palo Alto Networks in October 2020, the researchers reported on uses of\r\nmimipenquin and mimipy by the threat actor. Both of these tools are designed to dump passwords from various processes’\r\nmemory. They are essentially the *NIX equivalent of Mimikatz for Windows. After the credentials had been dumped, they\r\nwere exfiltrated to TeamTNT’s C2 server.\r\nLater the same month, ESET tweeted about a new tool the threat actor had added to their arsenal. The researchers found a\r\nbinary written in Go with an AES encrypted payload. When the crypter was executed, it would decrypt the payload and\r\nwrite it to a memory only file created with the system call memfd_create. The tool was identified as Ezuri, an open-source\r\nproject created by a security researcher.\r\nFigure 46: Tweet published by ESET reporting on the initial finding of TeamTNT’s use of Ezuri to crypt their malware.\r\nDer Winter 2021 (Winter 2021)\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 20 of 46\n\nIn January 2021, Lacework Labs released a detailed analysis of Tsunami, the IRC bot used by TeamTNT. By extracting the\r\nconfigurations embedded in the malware, they could connect to the IRC server and get more information about the threat\r\nactor’s operation and victim information. At the time of their analysis, around 200 bots were connected but only 90 unique\r\nIP addresses were detected. We have seen that TeamTNT has employed techniques to spread to other servers within internal\r\nnetworks. This suggests that some of the bots were behind a NAT and shared the same external IP address. The majority of\r\nthe infected machines were located in Asia with servers hosted in cloud providers Tencent, Alibaba, and Amazon Network\r\nbeing the largest. Outside of Asia, the United States, France, and Germany had the most bots. The researchers also\r\nuncovered that some of these infected machines were used to launch new campaigns.\r\nThe threat actor also added more tools to hide their activity on the infected machines. In January 2021, AT\u0026T Alien Labs\r\nreleased a report on TeamTNT’s use of libprocesshider. The tool is used to hide processes using LD_PRELOAD. The\r\nshared object was written to /usr/local/lib/systemhealt.so by the setup script and directives were added to\r\n/etc/ld.so.preload to allow the shared object to be loaded with every file that is executed. TeamTNT used libprocesshider to\r\nhide their Tsunami bot on infected machines.\r\nAttacking Kubernetes\r\nThe use of LD_PRELOAD to hide itself was spotted in another campaign of the group, this time targeting exposed\r\nKuberentes instances. Each Kubernetes node has a running agent called kubelet which takes RESTful requests and performs\r\noperations on the pods accordingly. The default configuration of standard Kubernetes deployments allow anonymous access\r\nto kubelet. TeamTNT used this misconfiguration to gain access to exposed Kubernetes instances and run cryptomining\r\nmalware in the containers.\r\nThis campaign was reported by Palo Alto Networks who described a new malware called Hildegard that was first seen in\r\nthis campaign. In this campaign there was no use of container images. The malicious functionality was carried out using a\r\nreverse shell and abusing containers that were already running.\r\nFinding containers and nodes that could be attacked was accomplished by two tools: masscan (a tool that was described in\r\nthe previous section) and kubelet. To evade detection this campaign uses LD_PRELOAD as described in the previous\r\nsection and it deletes the scripts immediately after their execution.\r\nThe campaign dropped two files: Peirates, a penetration tool for Kubernetes that steals cluster credentials, and BOtB, a tool\r\nfor performing a container breakout using known vulnerabilities.\r\nTo establish a connection with the Command and control (C2) server the malware used tmate or the Tsunami bot. It is\r\nunclear how the group decides which tool to use.\r\nIn this campaign the Tsunami bot was packed using Ezuri in an attempt to evade detection. The process name of the bot was\r\nset to ‘bioset’ to masquerade as a legitimate process. This process name was used by the group in previous campaigns.\r\nWindows Targeting Attempt?\r\nWhile investigating TeamTNT’s infrastructure, we noticed that two Windows PE files had been downloaded from one of the\r\ndomain names according to VirusTotal. A screenshot from VirusTotal is shown in Figure 47.\r\nFigure 47: Windows binaries downloaded from TeamTNT’s infrastructure in February 2021.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 21 of 46\n\nThe first file, sniffer.exe, is a compiled AutoIt script. A part of the script is shown in Figure 48. The script downloads\r\nWinPcap and tries to steal sensitive data from network traffic. It looks for keywords of usernames, passwords, credit card\r\ninformation, cookies, etc.\r\nFigure 48: Part of AutoIT script that uses WinPcap to steal sensitive data transferred over the network.\r\nThe second file, svchost2.exe, runs an XMRig Miner. A code reuse analysis of the file is shown in Figure 49. The file\r\n“installs” itself to the user’s home folder as the file name notepad.exe. The mining software is compiled with\r\nCUDA support to take advantage of a NVIDIA graphics card that might be available on the compromised machine.\r\nFigure 49: Code reuse analysis of svchost2.exe shows that the file executes a XMRig Miner.\r\nWhile we were not able to attribute these files to a campaign, the files are aligned with TeamTNT’s TTPs. Since the first\r\ncampaign in this report, the threat actor has been stealing credentials and installing cryptominers on servers. It is possible the\r\nthreat actor was just testing against a new target type, never manifesting into a full-fledged campaign.\r\nWhen the cryptominer is executed, it drops a driver to the user’s AppDataRoamingWinCFGLibs folder. From gene\r\nanalysis, this driver was identified as WinRing0x64 from OpenLibSys. The driver allows user space applications to access\r\nring 0, essentially giving the process unfettered access. This driver is part of XMRig for Windows. The miner uses the driver\r\nto access MSR registers to improve the mining performance. While the driver is part of a legitimate application, it does\r\nprovide a loophole that can be used to bypass a trust boundary.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 22 of 46\n\nFigure 50: Analysis of WinRing0x64 driver installed by the XMRig Miner.\r\nDer Frühling 2021 (Spring 2021)\r\nDuring the Spring of 2021, TeamTNT expanded their credential stealing. In a shell script found by Trend Micro, the threat\r\nactor had expanded their search to the following applications and services:\r\nSSH\r\nAWS\r\nDocker\r\nS3\r\nGitHub\r\nShodan\r\nGoogle Cloud\r\nNgrok\r\nPidgin\r\nFileZilla\r\nHexChat\r\nMoneroGuiWallet\r\nCloudFlared\r\nDavfs2\r\nPostgreSQL\r\nSMB\r\nThe script, shown in Figure 51, searches for the files but does not exfiltrate the data. It’s not known if and how TeamTNT\r\nexfiltrated the identified files as part of the campaign.\r\nIn addition to the credential search, the threat actor also started to enumerate data from the cloud environment that it was\r\nrunning on. Figure 52 shows a snippet of the script grab_aws_data.sh that uses AWS CLI to extract data.\r\nFigure 51: Script by TeamTNT searches for files that normally hold credentials.\r\nAccording to Trend Micro, close to 50,000 IP addresses running Kubernetes were compromised between March and May\r\nof 2021. The majority of the machines were located in China. The machines are predominantly hosted by cloud providers.\r\nThis distribution is similar to what Lacework Labs reported in January the same year but with a much larger volume.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 23 of 46\n\nFigure 52: Snippet of a script that uses AWS CLI to enumerate data from AWS.\r\nDer Sommer 2021 (Summer 2021)\r\nDuring the Summer of 2021, TeamTNT continued to target unsecured Docker and Kubernetes servers. Due to other threat\r\nactors using some of TeamTNT’s scripts during the Spring of 2021, TeamTNT added some new ways to identify their\r\nscripts. The threat actor announced the changes on their Twitter account as can be seen in Figure 53.\r\nFigure 53: TeamTNT announces via their Twitter account that all scripts from now on are “tagged” to ensure correct\r\nattribution.\r\nFigure 54 shows the first few lines of a script file that was used during the campaign. The file includes the information that\r\nthe threat actor claimed would be added. Further down in the file is a URL from where the script was downloaded from.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 24 of 46\n\nFigure 54: First few lines in the script file used during Summer 2021.\r\nTeamTNT also stated on their Twitter that they were going to be more “transparent” about their ongoing campaigns. As part\r\nof the Tweet, they included a link to a “beta dashboard.” Figure 55 is a screenshot of the dashboard. From the dashboard, it\r\ncan be seen that the “Chimaera” campaign started on July 25, 2021 and vulnerable Docker, Kubernetes and WeaveScope\r\nservices were being targeted.\r\nFigure 55: Screenshot of Chimaera dashboard.\r\nAs in previous campaigns targeting vulnerable Docker instances, the use of masscan/pnscan with zgrab was used in the\r\nSummer to find the instances. Figure 56 shows the payload executed on the vulnerable machines. First, it tells Docker to\r\ndownload an alpine image that downloads the scanning script and infects the machine with a miner. In addition, a\r\nWeaveScope probe is installed on the machine.\r\nFigure 56: Function in the scanner script that exploits insecure Docker services.\r\nTeamTNT also made some changes to the wallet. Instead of having the wallet address hard-coded in the script, the threat\r\nactor added functionality that allows for rotating the address without changing the scripts. Figure 57 shows how the script\r\nfetches the latest wallet from the threat actor’s server.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 25 of 46\n\nFigure 57: Added functionality to download the most recent wallet. If the request fails, a hard-coded backup address is used.\r\nFor being a threat actor, TeamTNT maintains a public persona on Twitter. The Twitter account @HildeTNT, shown in Figure\r\n58, was created in August 2020. The first campaign of the threat actor was reported in May 2020, while we have identified\r\nsome activity dating back to October 2019. The account was created during the Summer of 2020 when many reports\r\ncovering the actor’s activity were published. Based on the information provided in the profile their region is Germany.\r\n Figure 58: Screenshot of TeamTNT’s Twitter profile.\r\nIn the graph presented in Figure 59, the threat actor is active on Twitter during all hours of the day. The data presented in the\r\nfigure has been adjusted to UTC time zone. If we assume TeamTNT is based in a European time zone, we can conclude that\r\nthe “spike” in number of tweets corresponds from late afternoon until evening time in Europe.\r\nFigure 59: A graph showing the correlation between hours of the day (in UTC) and number of tweets.\r\nPlotting the activity on a timeline we can see when the threat actor has been most active and any potential downtimes. In\r\nFigure 60 we can see that the most socially active period was from the middle of January 2021 until the middle of May\r\n2021. There is a less active period at the end of 2020 which correlates to the Christmas holidays and New Year. It appears as\r\nthe activity might be slowing down.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 26 of 46\n\nFigure 60: A graph showing the correlation between hours of the day (in UTC) and number of tweets.\r\nMost of TeamTNT’s tweets are in German and the content varies from commenting on political subjects and current affairs\r\n(like COVID-19 vaccination), to discussing their activities and replying to researchers that post content related to the group.\r\nFigure 61 shows their response to a Trend Micro report.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 27 of 46\n\nFigure 61: Tweet by TeamTNT replying to a research article made about them. Translated from German.\r\nCopycat\r\nIn March 2021, TeamTNT replied to a tweet (later deleted) pointing out that someone else was using their tools and an\r\nattack was falsely attributed to the group. According to TeamTNT, the scripts used by the copycat were at least six months\r\nold.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 28 of 46\n\nFigure 62: A reply by TeamTNT to another user on Twitter. Translated from German.\r\nIn June, Palo Alto Networks’ Unit 42 released a report that attributed TeamTNT to a campaign in which appeared to contain\r\na number of scripts and tools that implemented similar techniques to those used by another cryptojacking group, yet had a\r\nnumber of differences in implementation and usage. TeamTNT replied to the author of the blog in a series of tweets claiming\r\nthat it was not a campaign and tools used by them but rather by someone else. They shared part of the script they own and\r\nuse in their current campaigns in order to prove their point. The script (Figure 64) was hosted on their site\r\nteamtnt[.]red/blog/Kubernetes.txt.\r\nThe group responded to other tweets that mentioned this blog, saying: “Das ist KEINE TeamTNT Kampagne!” (from\r\nGerman: “This is NOT a TeamTNT campaign!”). The threat actor has a history of commenting on previous reports\r\ndocumenting their activity. Sometimes they retweet the links to the report or comment on statements. They haven’t refuted\r\nprevious campaigns which suggests that they want to take credit for their activity. Based on their previous behavior, we\r\nassess that the refuted campaign is not by TeamTNT and instead by an imitator.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 29 of 46\n\nFigure 63: TeamTNT’s reply to Palo Alto’s research from June 2021.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 30 of 46\n\nFigure 64: Script shared by TeamTNT.\r\nTsunami (Kaiten)\r\nTeamTNT uses an IRC bot malware known as Tsunami. Figure 65 shows the code reuse analysis of the bot used in the first\r\nset of campaigns. Tsunami allows the operator to perform DDoS attacks against targets or execute commands on the infected\r\nmachine.\r\nFigure 65: Code reuse analysis of a Tsunami sample used by TeamTNT.\r\nThe source code for the bot was published in 2014. A forked and updated version called ziggystartux is available on\r\nGitHub. Figure 66 shows the GitHub repository for the project.\r\nFigure 66: GitHub repository of ZiggyStarTux.\r\nThe bot used by TeamTNT does not appear to have been compiled from this code. Instead it appears to have been compiled\r\nfrom an earlier version. There are multiple repositories in GitHub hosting the original published code. All of these have the\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 31 of 46\n\nbot version string found in the binary used by TeamTNT, as well as support for the same commands. The commands\r\nsupported by the bot are shown in the code snippets below.\r\nTeamTNT’s Configuration\r\nAs can be seen in Figure 67, the bot is setting a “fake” application name to kthreadd, masquerading as a kernel thread.\r\nFigure 67: Changing the name of the process to kthreadd.\r\nThe bot has two servers in its configuration. The servers are:\r\n111.230.15.240\r\nTeamtnt.twilightparadox.com\r\nRathole\r\nRathole is an open-source Unix backdoor with its code hosted on GitHub (Figure 68). A code reuse analysis is shown in\r\nFigure 69. The backdoor can be compiled on standard Linux distributions, it supports blowfish encryption, process name\r\nhiding and preferable shell.\r\nFigure 68: GitHub repository hosting the Rathole backdoor.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 32 of 46\n\nFigure 69: Code reuse analysis of Rathole binary used by TeamTNT.\r\nThe difference between the source and the binary is that the string ‘teamtnt’ is added to the encryption and decryption\r\nroutine.\r\nFigure 70: Screenshot showing the encryption key used by the backdoor.\r\nThe file was first submitted to VirusTotal on October 6, 2019, before the first recorded evidence of TeamTNT’s activity.\r\nEzuri\r\nEzuri is an open-source ELF crypter. The project is hosted on GitHub. Figure 71 shows a screenshot of the GitHub\r\nrepository.\r\nFigure 71: GitHub repository of Ezuri crypter hosted on GitHub.\r\nThe crypter uses AES in Cipher Feedback (CFB) mode to encrypt the payload. When the crypter is executed, the payload is\r\ndecrypted and executed from memory. Figure 72 shows the main and decryption function.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 33 of 46\n\nFigure 72: Ezuri’s main function and decryption logic.\r\nFigure 73 shows the runFromMemory function. The execution from memory is achieved by first creating a memory file\r\nvia the Linux syscall memfd_create. The decrypted content is written to the memory file. Following this, the process is\r\nforked and the spawned child executes the memory file via the execve syscall.\r\nFigure 73: Source code of the function that executes the decrypted payload from within memory.\r\nPunk.py\r\nPunk.py is a post-exploitation tool for Unix systems written by Giuseppe Corti. It’s open-source and hosted on GitHub.\r\nFigure 74 shows a screenshot of the GitHub repository. It uses credentials found on the exploited host to try to access other\r\nmachines that are part of the SSH known_hosts database. It has the ability to execute a command on all machines that it\r\nmanages to log into.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 34 of 46\n\nFigure 74: GitHub repository for punk.\r\nlibprocesshider\r\nThe libprocesshider is a source code-available project on GitHub. A screenshot of the repository is shown in Figure 75. The\r\nproject is compiled as a shared object. If it is loaded using LD_PRELOAD it “hooks” some libc functions which allows the\r\nlibrary to hide a process from commands like ps, lsof, and top.\r\nFigure 75: GitHub repository for libproccesshider.\r\ntmate\r\nTmate is an open-source tool that provides an easy and secure way to share the terminal. It establishes a secure connection\r\nover SSH to the tmate.io website and generates a random URL for each session. The user can share the URL with other\r\ntrusted users. Tmate supports all popular operating systems, including GNU/Linux, macOS, and BSD systems.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 35 of 46\n\nFigure 76: Screenshot from the official tmate site.\r\nmasscan\r\nMasscan is a TCP port scanner written by security researcher Robert Graham, also known as ErrataRob on Twitter. The\r\nscanner has been designed to scan the IPv4 address space very quickly and can be used for internet-wide scanning. To\r\nachieve this speed it needs to use a userland-based network stack.\r\npnscan\r\nPnscan, also known as Peter’s parallel Network Scanner, is a similar tool to masscan. It can be used to scan an IPv4 network\r\nfor SSH, FTP, SMTP, Web, IDENT, and other services. The source code is hosted on GitHub.\r\nTiny SHell\r\nTiny SHell (tsh) is an open-source Unix backdoor, divided into client and server, written in C. It is small in size and supports\r\nmultiple file transfers.\r\nMimiPenguin\r\nMimiPenguin is an open-source tool thal extracts login passwords similar to Mimikatz in Windows. It dumps processes that\r\nare loaded into memory and extracts lines that may contain cleartext passwords.\r\nFigure 77: Screenshot of the GitHub project MimiPenguin.\r\nMimipy\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 36 of 46\n\nMimipy is a cross-platform and open-source tool that dumps passwords from processes in memory. It is based on the\r\nMimiPenguin mentioned above. Mimipy has other features that include: extracting credentials from browsers and HTTP\r\nservers, support for lightDM, and overwriting passwords.\r\nBotB\r\nBreak out of the Box (BotB) is an open-source tool designed to be used by pentesters. It has many capabilities: exploits\r\nknown container vulnerabilities to break out of the container, find and use Kubernetes and GCP secrets, push data to an S3\r\nbucket and more.\r\nDiamorphine\r\nDiamorphine is a Linux Kernel Module rootkit written by Victor Ramos Mello. It’s hosted on GitHub and has support for\r\nkernel 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\r\nvia signals.\r\nFigure 78: Screenshot of the GitHub project Diamorphine.\r\nDocker Escape Tool is an open-source tool hosted on GitHub that identifies Docker containers and tries to escape the\r\ncontainer using known techniques. The purpose of the tool is to assess the security of containers. Implemented techniques\r\ninclude: mount Docker Unix socket, reach the Docker daemon on the default ports, exploit a vulnerability in RunC that\r\nallows attackers to overwrite the host RunC binary (CVE-2019-5736).\r\nFigure 79: Screenshot of the Docker Escape Tool repository on GitHub.\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 37 of 46\n\nDas Fazit (Conclusion)\r\nIllicit cryptomining has become the major threat to Linux servers and cloud environments. TeamTNT is one of the\r\npredominant threat actors in this field. TeamTNT’s activity can be traced back to the Fall of 2019 in attacks against Redis\r\nserver. From this humble beginning, the threat actor has changed its targets towards servers running Docker and now\r\ncurrently Kubernetes clusters. Most of the tooling and tactics used by the group is similar to other threat actors in the field.\r\nThey predominantly structure their attacks around a set of multiple shell scripts but also use open-source and source\r\navailable tools. The shell scripts are rarely written to disk, instead they are downloaded using curl or wget and “piped”\r\ndirectly into a shell interpreter. This can make it hard to investigate what has happened to a compromised machine as no\r\nartifacts on the machine exist. They also clear logs to make the investigation even harder.\r\nSince they are competing with other cryptojacking-focused threat actors, TeamTNT employs different techniques to ensure\r\nthat only their cryptominer is running. In early campaigns, we have seen them “plug the hole” used to compromise the\r\nmachine, for example, by adding firewall rules to block external network connections to access the vulnerable service.\r\nTeamTNT has also used different techniques for hiding their processes on the machine, including userland rootkits. Some of\r\nthe scripts also include lists of other known cryptominers that the threat actor tries to kill on the machine. This is a common\r\ntechnique employed by many other threat actors in this field which essentially turns the compromised machine into a game\r\nof “King of the Hill.”\r\nWhat separates TeamTNT from other major threat actors in the cryptojacking field is their public presence on the clear web.\r\nThey maintain a public appearance on Twitter and frequently tweet. Based on the public persona, it can be assumed that they\r\nare based in Germany. The threat actor commonly interacts with German politicians, tweets about their ongoing campaigns,\r\nand comments on reports by the security industry. The majority of these comments are to take credit for their work. During\r\nthe Spring of 2021 some campaigns were attributed to TeamTNT but the threat actor refuted that it was their work. This\r\nsuggested the emergence of an imitator reusing some of TeamTNT’s older shell scripts. It remains to be seen if this will\r\naffect their activity and if they will continue to target Kubernetes clusters or if they will move on and target new cloud\r\ninfrastructure.\r\nIoCs:\r\nPre-February Campaign\r\nFiles\r\nName SHA256\r\nbsh.sh 125dc99b9f94d5548bb68b371cb2ff22134b60b1fef915d1ae85b025f4039be0\r\nash.sh 561b76684d80084bd4b924e439f7e37683f486ca94fa088f283402dc7443271c\r\n  dcc96cdc7192a41fb242a680a83969e16247511816dc0f80e63b134059497ad1\r\nhole64 da43ed194729f82db68b1d91a17cea6afde8ae81357116c35c4c129888a836bf\r\nNetwork\r\nValue\r\n36.7.154.124\r\n116.62.122.90\r\n3.215.110.66\r\n125.254.128.200\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 38 of 46\n\nSSH Key\r\nssh-rsa\r\nAAAAB3NzaC1yc2EAAAADAQABAAABAQDIzB9hz7bNT6qtQKCMcitaaxEB9RyJEZuumE+gUMrh6hg3ccSMg9qnAlS/Lmw5SwwLJQXMB5Wuh\r\nFebruary 2020 Campaign\r\nFiles\r\nName SHA256\r\n32bit.tar.gz 40c298446a7e53c3775f67deedf5d13b7c2c601de3c744f72fda42f99c156075\r\n64bit.tar.gz 4f2ee441b35e8e0fe99608a011b632db219bd6631bcda39899b747a0dd38b5c6\r\nbioset da43ed194729f82db68b1d91a17cea6afde8ae81357116c35c4c129888a836bf\r\nconfig.json 1470c3100b976ae2d4f9a1def5d6c6715d4f050e7de5e261b5d4e4a2faf9603d\r\ncyo.sh 77334b8e3c8df468eda2ef93467d63e41dab7beb451a3bbb5637473fabc620d6\r\ndbus-config b7225aefd8fb399a7f18639c32c59442daa5401b6164130e316092e8618f667f\r\nFullCleanUp.sh 6a1221fc82b2bf13dc8112795d3edfb7bab8df7a9d4af69b89da4ac31e0e87e5\r\nhfile e5f48ccf07addd83986f5b6f9444d5f91cacbb5c471b815a2b68a9c02727821b\r\nhid.sh fe6e522ff266867060fa70d85be299ac5b12f2888935c5fe6e0a07d3ccaa1de2\r\nlogs.c 59aa2101b05225dd0eb7e7b456eb26357540723e3c1d8a10deca83e9715a10fb\r\nsetup.sh b5ba2c86ebf85cbf700c83d7edc034717d7ee08e84fbae440a38139c15ef7a27\r\nNarrenKappe.sh a25a73af06c43a20eb9f4f8b67357cec3c74143ccf97ce666446296a360d93fa\r\npnscan-1.11.tar.gz 702b123a3abd518ac696c9e340e1aaf4742d271922b8b537d8595ea6486d7aa8\r\npunk.py a66140870d0a71c7bd42b7631e4a85858e6b33e4a21be637b94d41833dee8383\r\nrd.sh d42ee8a001de9b13496f2980de6ca22b544a5a9012e9e97374343411593c2c29\r\nsetup.sh dad3016b75e89b415e3c7e360ec2ffa31e48b667082843013bbff719add826c7\r\ns_poor.ssh.sh 1eead4f456ed8741d1de821e2fcecb026c1cbbf3477786cc3e637eac05811f46\r\nsysinfo.txt 53ba0436084f054c9c2c8aaf110f2c89c3c8b1fd9f1e4ca48cedfa86b7dece81\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 39 of 46\n\ntmp.min.sh 669ace6d57c68e4a7f2fabcacfecf485a5c90bfc28a809a432e68b53f60836a4\r\nwatchdogd.tar.gz e0876231c4829e0c7be4ffe47466b57e17a15e9c1529f332f813ea532716c945\r\nwhois2.irc.sh 795a3d99c1e8e34a6228d95c4435c5ed7c866dc0e303f9788ea6fe055b1a7ac6\r\nwhois.irc 205db0ef59cad167c6132916f8f7a1d1963e740b36400419b2e5ba307e9f765c\r\n32-bit Archive\r\nName SHA256\r\nwatchdogd 69fea980538a12ac0791f0801fc93d8b4d16e8329793d635221a16f935e8ca07\r\nXMRig Miner 4256402fc04e49f3da8d1bf88efdcca6a3b03f4b881777d2c32a8df364cececd\r\n64-bit Archive\r\nName SHA256\r\nbioset da43ed194729f82db68b1d91a17cea6afde8ae81357116c35c4c129888a836bf\r\nconfig.json 285e91d3d578fcaf6665c70de457f602d572203b04c281c03b4bf9103aa5f61f\r\ndo.sh 9c29d4ecf6a60e7bfc0afbaa7a669a18af163440730711367d1c715042b5f755\r\nlo 920014ace9add87139db41eb2538b292ad136fde7ac5f683eb3b31e0fed5f808\r\nrstart.sh 4beaf3edbd1065c0dfd02cf864effe3d1e18d0f39275f0d49cb21951a12976c3\r\nsystemd-clean 3a2aa7235f0617df430b3d556779bee2ae0af75d7c2f17f052971d3f38fad9e0\r\nwatchdogd fdf26ebad48da26be59b5784f43d1e5ee2efa93c59a717fe2ae1d82bf3f016d3\r\nwatchdogd.initd 16b26d9e4413c2f6d081ca093106935673747d5266aaa33f51c845e65b90e904\r\nwatchdogd.service 264c9b440f2fbd03000211a92a8bbb190f69c78dc087b8f757b3e8676554df57\r\nwatchdogd-stop 020ba2a9f603588dbc6498a6e230249c6952daa920a58de89d997b3fcdc4c115\r\nXMRig Miner b6f57f8a7fba70d6660335828d2a14029c88079a8176dca2c63281a759fd84ca\r\nNetwork\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 40 of 46\n\nValue Comment\r\nicanhazip.com Used to determine IP\r\nteamtnt.red Main server\r\n123.56.193.119 Exfiltration server\r\n116.62.122.90 Old server still used by some scripts\r\n120.26.230.68 Miner CC\r\n80.211.206.105 Command center\r\nWallet\r\n89X8a5RqKMGLubB19DwVVqPxgF27C8hqpbtWMqNorpsDSu6Qw5uu4iJF8WwoLt2VQGRgALfjEqpq61awRTaBwpciDatbCNB\r\nSpring 2020\r\nFiles\r\nName SHA256\r\nclean.sh 6b8d828511b479e3278264eff68059f03b3b8011f9a6daaeff2af06b13ba6090\r\ndns 6c73e45b06544fc43ce0e9164be52810884f317a710978c31462eb5b8ebc30cc\r\ndns3 07377cac8687a4cde6e29bc00314c265c7ad71a6919de91f689b58efe07770b0\r\ndns3_32bit 3876b58d12e27361bdfebd6efc5423d79b6676ca3b9d800f87098e95c3422e84\r\ninit.sh (Trend Micro) 459190ba0173640594d9b1fa41d5ba610ecea59fd275d3ff378d4cedb044e26d\r\ninit.sh (the second script) 5c488d9d6820f859cde5fb5d147cfe584a603152653d12e720b897df60c6f810\r\nmxutzh.sh 8926672fe6ab2f9229a72e344fcb64a880a40db20f9a71ba0d92def9c14497b6\r\nNarrenKappe.sh d791ac65b01008d2be9622095e6020d7a7930b6ce1713de5d713fc3cccfa862\r\nsetup.mytoys.sh  b60be03a7305946a5b1e2d22aa4f8e3fc93a55e1d7637bebb58bf2de19a6cf4a\r\nsetup.xmrig.curl.sh  bebaac2a2b1d72aa189c98d00f4988b24c72f72ae9348c49f62d16b433b05332\r\nsysinfo 3c907087ec77fc1678011f753ddf4531a484009f3c64563d96eff0edea0dcd29\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 41 of 46\n\nlan.redis.pwn.sh 25b4c5a3b3bfb1adab66fe17313a9828ef4ed13ea903e603f0ae36f3aa00cab0\r\nminion_worker.sh 2adb1a298dd4ffd1b4fe2d5f5468363e977c8962dc837dc57219362ee2fc3127\r\nSummer 2020\r\nFiles\r\nName SHA256\r\nCarray.jpg 230e2a06df2cd7574ee15cb13714d77182f28d50f83a6ed58af39f1966177769\r\nclean.jpg c55e4c67ba3cf54360a88980183767522fc05e8bf076f31399ee45efbfbd78e5\r\ncron.jpg 9f5e14ca8c877b7dff84ffbe018c461233af975654bd5b87431920dfc24568a5\r\ncron_set.jpg 705a22f0266c382c846ee37b8cd544db1ff19980b8a627a4a4f01c1161a71cb0\r\nds.jpg a386aced768146fecfe81cac214c51c7e575b2c0c27a29c683e3357706f651ba\r\ninit.jpg 616c3d5b2e1c14f53f8a6cceafe723a91ad9f61b65dd22b247788329a41bc20e\r\nlocal.jpg b556d266b154c303bb90db005d7dd4267ed8d0e711e3fd32406c64b1fc977f9e\r\nmo.jpg 3a377e5baf2c7095db1d7577339e4eb847ded2bfec1c176251e8b8b0b76d393f\r\nmos.jpg 0742efecbd7af343213a50cc5fd5cd2f8475613cfe6fb51f4296a7ec4533940d\r\nssh.jpg 929c3017e6391b92b2fbce654cf7f8b0d3d222f96b5b20385059b584975a298b\r\ntnt.jpg b3c94173daf8f825dcba80ecc813dd0ca36636851f9fa83901ae3b36af166d78\r\nmo.jpg 1b7180c7e1f150ba6848e392e8482b83c638b27b37873f7f0948be991416431\r\nmo.jpg 3a377e5baf2c7095db1d7577339e4eb847ded2bfec1c176251e8b8b0b76d393f\r\ninit.jpg 616c3d5b2e1c14f53f8a6cceafe723a91ad9f61b65dd22b247788329a41bc20e\r\ncron_set.jpg 705a22f0266c382c846ee37b8cd544db1ff19980b8a627a4a4f01c1161a71cb0\r\nds.jpg a386aced768146fecfe81cac214c51c7e575b2c0c27a29c683e3357706f651ba\r\nmo.jpg b6e369f0eb241ffb1b63c8c5b2b8a9131a9b98125ca869165f899026ab2c64ba\r\nssh.jpg b9036b471ade3a0ed2c3e7d7c20f0844ee15d67ddcbe3380350944e427a7bf49\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 42 of 46\n\ncron.jpg c4cd9c12d47e5468f6f6e4b27e122f1a3d05dcae958245b59bde07d11c27328e\r\nArchives\r\nName SHA256\r\n01.jpg 78037e2d2e596bd450b99551535fa9c38c4e8346ab75eb424bf9e95316424fbe\r\n21.jpg 4f115381c17ba1dedb25d35d922feda9a723e206d811ed437b75fd8116ef461b\r\n22.jpg 4a5d3435cd4a835056b4940e1cea9a25b1619562525bd9953a120b556b305983\r\nabout.jpg a79d4f5633dbbe98842d5073b41cc25468679c46e011373587ffdbc544d1ea12\r\ndet.jpg 79a060a0efcf4a1538c58e532b984dcd927fda17ca9fd10c2ff212f9d9d76be6\r\nmod.jpg feb0a0f5ffba9d7b7d6878a8890a6d67d3f8ef6106e4e88719a63c3351e46a06\r\nstock.jpg 2c40b76408d59f906f60db97ea36503bfc59aed22a154f5d564d8449c300594f\r\nBinaries\r\nName SHA256\r\nimpressum.jpg f64a828d58ac5bbdde5e982ebb0766c8969cb63b4ab642467392042f2a594295\r\njq.jpg bcfa215dec8fe15d4265c508c39c1ebafb7370acc95721e4e7d610b0459eb8dd\r\nkube.jpg 15dce6f833812b119de9447db49e61f5c238c4e45b0dafbe0b6af0ab50bb329a\r\nms.jpg 72b1cbfbd87c6cd85b9dc1da48c852768003e7fb4f01d8f6904921474be199ad\r\nsocat.jpg 71c81cb46dd1903f12f3aef844b0fc559f31e2f613a8ae91ffb5630bc7011ef5\r\ntshd.jpg ba974b31c7e6715b83e9468f72fd5927d560fe80dbcba8c4466bb8ce5b93601d\r\nzgrab.jpg 1474298ed7a5c63ca8098794cd743a276807cca0e678e046160718626bb038f3\r\nportainer b49a3f3cb4c70014e2c35c880d47bc475584b87b7dfcfa6d7341d42a16ebe443\r\n88ZrgnVZ687Wg8ipWyapjCVRWL8yFMRaBDrxtiPSwAQrNz5ZJBRozBSJrCYffurn1Qg7Jn7WpRQSAA3C8aidaeadAn4xi4k\r\nFall 2020\r\nNetwork\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 43 of 46\n\nValue Comment\r\n85[.]214.149.236 Host malicious scripts and binaries\r\nhttps://iplogger[.]org/2Xvkv5 Used to obtain the IP address of the victim\r\nName SHA256\r\nxmrig 3b4ff9aff08a7ca9a36ed997f94adb6b18bb757157cec4f04b53ba67e9377003\r\nkdevtmpfsi dd603db3e2c0800d5eaa262b6b8553c68deaa486b545d4965df5dc43217cc839\r\nxmrigCCMiner_64Bit b6f57f8a7fba70d6660335828d2a14029c88079a8176dca2c63281a759fd84ca\r\nx86_64 139f393594aabb20543543bd7d3192422b886f58e04a910637b41f14d0cad375\r\nxmrig fdf26ebad48da26be59b5784f43d1e5ee2efa93c59a717fe2ae1d82bf3f016d3\r\nWinter 2021\r\nAttacking Kubernetes\r\nNetwork\r\nValue Comment\r\nThe.borg[.]wtf (45.9.150.36) Host malicious scripts and binaries\r\n147.75.47.199 Used to obtain the IP address of the victim\r\nteamtnt.red (45.9.148.108) Host malicious scripts and binaries\r\nBorg.wtf (45.9.148.108) Host malicious scripts and binaries\r\nIrc.borg.wtf (123.245.9[.]147) C2 server and runs IRC server\r\nSampwn.anondns.net (13.245.9[.]147) C2 server and runs IRC server\r\n164.68.106.96 C2 server and runs IRC server\r\n62.234.121.105 C2 server and runs IRC server\r\nFiles\r\nName SHA256\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 44 of 46\n\nTDGG 2c1528253656ac09c7473911b24b243f083e60b98a19ba1bbb050979a1f38a0f\r\ntt.sh 2cde98579162ab165623241719b2ab33ac40f0b5d0a8ba7e7067c7aebc530172\r\napi.key b34df4b273b3bedaab531be46a0780d97b87588e93c1818158a47f7add8c7204\r\ntmate d2fff992e40ce18ff81b9a92fa1cb93a56fb5a82c1cc428204552d8dfa1bc04f\r\nsGAU.sh 74e3ccaea4df277e1a9c458a671db74aa47630928a7825f75994756512b09d64\r\nkshell 8e33496ea00218c07145396c6bcf3e25f4e38a1061f807d2d3653497a291348c\r\ninstall_monerod.bash 518a19aa2c3c9f895efa0d130e6355af5b5d7edf28e2a2d9b944aa358c23d887\r\nsetup_moneroocean_miner.sh 5923f20010cb7c1d59aab36ba41c84cd20c25c6e64aace65dc8243ea827b537b\r\nxmrig (oneroocean) a22c2a6c2fdc5f5b962d2534aaae10d4de0379c9872f07aa10c77210ca652fa9\r\npei.sh ee6dbbf85a3bb301a2e448c7fddaa4c1c6f234a8c75597ee766c66f52540d015\r\npei64 937842811b9e2eb87c4c19354a1a790315f2669eea58b63264f751de4da5438d\r\npei32 72cff62d801c5bcb185aa299eb26f417aad843e617cf9c39c69f9dde6eb82742\r\nxmr3.assi 12c5c5d556394aa107a433144c185a686aba3bb44389b7241d84bea766e2aea3\r\naws2.sh 053318adb15cf23075f737daa153b81ab8bd0f2958fa81cd85336ecdf3d7de4e\r\nt.sh e6422d97d381f255cd9e9f91f06e5e4921f070b23e4e35edd539a589b1d6aea7\r\nx86_64.so 77456c099facd775238086e8f9420308be432d461e55e49e1b24d96a8ea585e8\r\nxmrig 78f92857e18107872526feb1ae834edb9b7189df4a2129a4125a3dd8917f9983\r\nxmrig.so 3de32f315fd01b7b741cfbb7dfee22c30bf7b9a5a01d7ab6690fcb42759a3e9f\r\nxmr.sh fe0f5fef4d78db808b9dc4e63eeda9f8626f8ea21b9d03cbd884e37cde9018ee\r\nziggy 74f122fb0059977167c5ed34a7e217d9dfe8e8199020e3fe19532be108a7d607\r\nWindows Targeting\r\nName SHA256\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 45 of 46\n\nsniffer.exe 42e60ce9f0b7c5260282a7006af0166cd3603a6043d833719586bd1adaece138\r\nsvchost2.exe dd0a5c62db8403263872716b8b2dfd190fcf9c742e9d13ad2c40ab41df7f2045\r\nWallet:\r\n84dg9MjSkFvXkqHQuBr6ep6TfhR3pTP8DRyTMN5s8RgYMVRcnce7Day8edLkk3TqAaSHXu2N4W3A3XjKMaSx4X8Q3KQgZnh\r\nSpring 2021\r\nName SHA256\r\naws.sh 8cedd6187439f73675b076d70647ee117ec3a4184a5045499a6172ae6e6c2c39\r\ngrab_aws-data.sh a1e9cd08073e4af3256b31e4b42f3aa69be40862b3988f964e96228f91236593\r\ninit.sh 4e059d74e599757226f93ea8ddcfb794d4bcda605f0e553fbbef47b8b7c82d2b\r\nsearch.sh ed40bce040778e2227c869dac59f54c320944e19f77543954f40019e2f2b0c35\r\nSummer 2021\r\nFiles\r\nName SHA256\r\nSSH.id_rsa.LAN.spread.sh 000f9927d2aad73a10d7034cff8308535322e629a75600addfe38202305101ba\r\nmo.sh 1b72088fc6d780da95465f80ab26ba094d89232ff30a41b1b0113c355cfffa57\r\nSSH.id_rsa.LAN.spread.sh 3cc54142b5f88d03fb0552a655e32e94f366c9e3bb387404c6f381cfea506867\r\nbot_u 5e1af7f4e6cf89cff44ee209399a9fab3bfd8f1ca9703fb54cee05cce2b16d4c\r\nscan.sh 6c8a2ba339141b93c67f9d79d86a469da75bfbc69f128a6ed702a6e3925d5a29\r\nsetup.scanner.root.sh 8737eb891a80302929a7d2a6ffacd51338705783f250ecbcd62d2d623f9e98fd\r\nsx.sh a383e770c319b2411ed17775a114b697fb83ab53912266462ad1607c090ca608\r\nkbot_x86_64 a46c870d1667a3ee31d2ba8969c9024bdb521ae8aad2079b672ce8416d85e8df\r\nDomains\r\nteamtnt[.]red\r\nchimaera[.]cc\r\nSource: https://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nhttps://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/\r\nPage 46 of 46",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.intezer.com/blog/malware-analysis/teamtnt-cryptomining-explosion/"
	],
	"report_names": [
		"teamtnt-cryptomining-explosion"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f809bfcb-b200-4988-80a8-be78ef6a52ef",
			"created_at": "2023-01-06T13:46:39.186988Z",
			"updated_at": "2026-04-10T02:00:03.240002Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"Adept Libra"
			],
			"source_name": "MISPGALAXY:TeamTNT",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "c3ca592f-0669-49bd-ab5c-310007ab2fb4",
			"created_at": "2022-10-25T15:50:23.334495Z",
			"updated_at": "2026-04-10T02:00:05.264841Z",
			"deleted_at": null,
			"main_name": "TeamTNT",
			"aliases": [
				"TeamTNT"
			],
			"source_name": "MITRE:TeamTNT",
			"tools": [
				"Peirates",
				"MimiPenguin",
				"LaZagne",
				"Hildegard"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3fff98c9-ad02-401d-9d4b-f78b5b634f31",
			"created_at": "2023-01-06T13:46:38.376868Z",
			"updated_at": "2026-04-10T02:00:02.949077Z",
			"deleted_at": null,
			"main_name": "Cleaver",
			"aliases": [
				"G0003",
				"Operation Cleaver",
				"Op Cleaver",
				"Tarh Andishan",
				"Alibaba",
				"TG-2889",
				"Cobalt Gypsy"
			],
			"source_name": "MISPGALAXY:Cleaver",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434671,
	"ts_updated_at": 1775791966,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4c965dbd44ffbfe6ab39efb6ff4849607bc90b3b.pdf",
		"text": "https://archive.orkl.eu/4c965dbd44ffbfe6ab39efb6ff4849607bc90b3b.txt",
		"img": "https://archive.orkl.eu/4c965dbd44ffbfe6ab39efb6ff4849607bc90b3b.jpg"
	}
}