{ "id": "b95d0545-abfd-4f39-9b1d-26bdd8e6d742", "created_at": "2026-04-06T00:14:55.285365Z", "updated_at": "2026-04-10T03:32:45.98819Z", "deleted_at": null, "sha1_hash": "4b77bb19c7ec1981844875df9a25eb8591ac937d", "title": "Threat Alert: New Malware in the Cloud By TeamTNT", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1988693, "plain_text": "Threat Alert: New Malware in the Cloud By TeamTNT\r\nBy Assaf Morag\r\nPublished: 2022-09-15 · Archived: 2026-04-05 13:38:55 UTC\r\nOver the past week we observed three different attacks on our honeypots. The scripts and malware that were used\r\nbear a striking resemblance to none other than the threat actor TeamTNT. Eleven months ago they posted a\r\nfarewell note on Twitter. Since then, we have only seen legacy attacks which automatically run on past\r\ninfrastructure. Could it be that TeamTNT is back with new tricks? In this blog we analyze these attacks and their\r\npossible connection to TeamTNT.\r\nA Brief History of TeamTNT\r\nIn the beginning of 2020, TeamTNT emerged as a threat actor mainly targeting cloud environments including\r\nmisconfigured Kubernetes clusters, Docker APIs, Kubernetes UI tools, Redis servers, and more.\r\nSince that first attack, this threat actor was highly productive and innovative, introducing new techniques against\r\ncloud environments that hadn’t been seen before. There had been many reports over the years about the threat\r\nactor’s campaigns and toolbox.\r\nOn November 6th, 2021, TeamTNT communicated via Twitter a farewell note. In reality, their infrastructure\r\ncontinued to automatically infect new victims with old malware as their tools included various worms that could\r\nscan and infect new targets. Once a target is acquired, a new scan and infection sequence begins. Thus, as of\r\ntoday, their old campaigns continues working. Still, over the past eleven months we haven’t seen any new\r\ncampaigns or tools coming from TeamTNT. This has led the entire community to assume that TeamTNT had\r\nindeed stopped their activity.\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 1 of 11\n\nTweet by TeamTNT saying farewell on November 6th, 2021\r\nBut, are they back?\r\nIn the first week of September, our honeypots identified at least three different attacks bearing various signatures\r\nand tools which are associated with TeamTNT. Based on these, we are quite certain that this vibrant threat actor\r\nhas renewed its malicious activity.\r\nWith these new attacks, should we expect further innovation and cunning from TeamTNT?\r\nThe Kangaroo Attack\r\nBy far, this may be their simplest and most dramatic attack. What we discovered is that TeamTNT has been\r\nscanning for a misconfigured Docker Daemon and deploying alpine, a vanilla container image, with a command\r\nline to download a shell script (k.sh) to a C2 server (domain: whatwill[.]be on IP 93[.]95[.]229[.]203 ).\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 2 of 11\n\nKangaroo attack flow\r\nThe file k.sh that was dropped and executed on the attacked server\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 3 of 11\n\nThe shell script is cloning a GitHub project from what seems to be a TeamTNT account. The project was a bit of a\r\nconundrum at first, specifying that this is a fork of “Pollard’s kangaroo for SECPK1”. We consulted  Jonathan S.,\r\na cryptographic expert, to better understand this technique. Additionally, we conducted further research to shed\r\nlight on what we observed. We tracked this topic within a Bitcoin talk forum as well as several academic papers,\r\n“A New Method for Solving the Elliptic Curve Discrete Logarithm Problem”, “How Would Quantum Computing\r\nImpact the Security of Bitcoin by Enhancing Our Ability to Solve the Elliptic Curve Discrete Logarithm\r\nProblem?” and the best explanation about Pollard’s Kangaroo for WIF solving. In addition, we consulted with a\r\ncryptographic expert to better understand this topic.\r\nSince these articles are a challenging read, we‘ve worked here to summarize them for you to highlight the most\r\nessential information. The Elliptic Curve Discrete Logarithm Problem (ECDLP) is considered an irreversible\r\nfunction. It is the foundation for secure cryptography in private and public keys encryption which is the bedrock\r\nof secure internet communication (SSH, SSL etc).\r\nThe Pollard’s Kangaroo interval ECDLP solver algorithm appears to be an attempt to break the SECP256K1\r\nencryption which is used by Bitcoin to implement its public key cryptography. This is interesting because\r\nTeamTNT is using the high (and free or illegal) computational power of their targets to run the ECDLP solver. It is\r\ndesigned to run in a distributed fashion since the algorithm breaks the key into chunks and distributes them to\r\nvarious nodes (attacked servers), collecting the results which are then written locally to a text file.\r\nBreaking the cryptographic encryption is considered “Mission: Impossible”. If you actually succeed doing that,\r\nyou potentially have the keys to almost everything that is connected online, which could have a devastating effect\r\non the entire internet.\r\nThe Cronb Attack\r\nThis name had been used in the past by TeamTNT in previous attacks and, thus, thought to have been associated\r\nwith an old attack. However, it turns out that this script is novel, pointing to new C2 servers (on\r\n93[.]95[.]229[.]203 and 205[.]185[.]118[.]246 ). In this attack, though, we see all the old tricks TeamTNT\r\nhas used over the years including rootkits to hide their activity, cron jobs to gain persistence, cryptominers to\r\nhijack resources, ssh and keys theft to conduct lateral movement in the local and external network, and many other\r\ntechniques seen in the past.\r\nCronb.sh shell file\r\nFirst, the C2 server (93[.]95[.]229[.]203) is defined as a variable. The file is designed to “initiate” the\r\nenvironments and contains 14 functions as follows:\r\n1. check_exist\r\nChecks if netstat, which is a Linux network utility that displays network connections information, is\r\npresent.\r\nIf netstats exists, the function also checks for cryptominers presence.\r\n2. m_command\r\nThis function scans for various applications like wget on the host and sets them as environment variables if\r\nthey exist. In past campaigns, TeamTNT commonly used this technique mostly to avoid detection and\r\ncircumvent network controls.\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 4 of 11\n\n3. ins_package\r\nInstalls various applications on Ubuntu, Alpine, and Debian distributions by using apk, apt , or yum\r\ncommands based on the OS distribution.\r\n4. SetupNameServers\r\nSetting up a name server to circumvent network defense. In past campaigns, TeamTNT commonly used\r\nthis technique.\r\n5. download_f\r\nDownloading a Monero cryptominer and its configuration file and executing a cryptojacking attack.\r\n6. setup_s\r\nDeleting the content of md service and installing a new service of cryptomining to be run by systemd .\r\n7. makesshaxx\r\nInserts TeamTNT’s SSH key to the host.\r\n8. clean_monitor\r\nDeletes history and stops and deletes security tools such as SElinux, watchdog, gcloud of GCP, and aegis\r\nof Alibaba cloud.\r\n9. clean_cron\r\nVery straightforward – deletes all cron scheduled jobs.\r\n10. lock_cron\r\nLocking the cron jobs.\r\n11. exec_hide\r\nMakes sure that Diamorphine rootkit is deployed and calls exec_f . If Diamorphine isn’t deployed, the\r\nhide_f function is called.\r\nhide_f: Extracts a contained encoded (base64) tar file of Diamorphine rootkit, extracts, compiles,\r\nand checks that it was deployed successfully.\r\nexec_f: Hides the malicious processes of masscan and md service executed.\r\n12. exec_hide2:Deploys prochider rootkit that hides itself, explained here.\r\n13. clmo: Stops and deletes security tools of Alibaba cloud.\r\n14. exe_remo:Checks if this server has /var/tmp/.kalafwhich may indicate that TeamTNT botnet has\r\nalready attacked this server. If not, executes the localgo function, downloads and runs s.sh shell file\r\nand cleans history.\r\nlocalgo: Deletes logs such as wtmp which documents ssh access to the server and uses known hosts and\r\nssh keys (if exists) to access other servers on the network, infecting them by deploying and running the\r\nscript b.sh ( ronb.sh renamed) on them. In past campaigns TeamTNT commonly used this technique.\r\ns.sh shell file\r\nThis file also uses the C2 server (93[.]95[.]229[.]203) and another C2 server (205[.]185[.]118[.]246) .\r\nThe file is designed to “support” the attack and contains one function and various snippets as follows:\r\n1. m_command : Similar to the one in cronb.sh file as described above.\r\n2. The rest of the script is not as organized as the cronb.sh script. It contains several snippets:\r\nDesigned to download various applications.\r\nDownloads zgrab, masscan, pnscan which are scanning applications.\r\nDownloads the shell scripts c.sh and d.sh .\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 5 of 11\n\nDeleting the content of md service and installing a new service of cryptomining to be run by\r\nsystemd .\r\nb.sh shell file \r\nIdentical to the cronb.sh script.\r\nc.sh shell file\r\nThis script seems to be designed to deploy a cryptomining attack on vulnerable and misconfigured Redis services\r\nand contains the following snippets:\r\n1. Changing iptables to allow scanning for Redis servers.\r\n2. Creating the payload which is a .dat file that writes to cron, downloads, and runs the b.sh shell script.\r\n3. Scanning locally and on the internet for exposed Redis services and running the .dat file.\r\nThe file c.sh is designed to detect and attack exposed Redis server. In the past, TeamTNT massively attacked\r\nRedis servers to mine cryptocurrency.\r\nThe “What Will Be” Attack\r\nThis is the third attack by TeamTNT that that we observed this week on our honeypots. Initially, the threat actor\r\nexploited a misconfigured Docker API to run the vanilla container image alpine with a malicious command that\r\nwas designed to download and run the shell file dc.sh .\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 6 of 11\n\ndc.sh shell file\r\nThis file contains two very interesting functions designed to exploit the release_agent vulnerability in order to\r\nescape to the host from the container. You can further read about it here in a previous blog from our team.\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 7 of 11\n\nAs can be seen in the two screenshots below, in both functions the threat actor is downloading and running further\r\nshell scripts.\r\nThe first function from the shell file dc.sh\r\nThe second function from the shell file dc.sh\r\nThe first function ( dock1 ) and the second one ( dock2 ) download the shell scripts en.sh , which is designed to\r\noptimize cryptomining by using wrmsr  and meant to write to model a specific register. It allows writing to CPU\r\nmachine specific registers. As can be seen below, the attackers appear to be trying to address the specific registers\r\nto optimize CPU for cryptomining based on the microarchitecture.\r\nApparently, TeamTNT has added some new tricks since this technique did not appear to be used in the past by the\r\ngroup.\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 8 of 11\n\nIn the first function (dock1) d.sh is downloaded and run. It is identical to the one used in the cronb attack\r\ndescribed above. We could see that a download and execution of a syslog binary from the C2 server is\r\ncommented out. That binary is available for download from the C2 server and is actually a Tsunami malware\r\n( MD5:1ded4ed94ab31f1a3bba3a50cfa7238f, 32 detections in VT), commonly used in the past by TeamTNT. It\r\ncould be that their infrastructure is not fully online and thus it wasn’t used in this attack.\r\nIn the second function (dock2), there are two comments that are supposed to open a backdoor. This technique is\r\nalso new since it wasn’t seen by the group in the past. Additionally, Tsunami malware ( syslog ) and ent.sh\r\nshell file ( en.sh renamed) downloads are kept as a comment as well.\r\nIterating back to the GitHub Account\r\nIn the Kangaroo attack analyzed above, we mentioned that the GitHub account used to host the repository of the\r\nKangaroo project is most likely utilized by TeamTNT. The name of the account is wafferz which means armory\r\nin German. In the past, there were many indications in TeamTNT’s code, repositories, websites, servers, and\r\nTwitter account that have a German origin. In this attack it is no different. In the code, their “sense of humor” is\r\napparent in the comments and prints to logs.\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 9 of 11\n\nIn the project Dock in the GitHub account, you can see a further link to TeamTNT since most of the code is\r\nstrikingly similar to the attacks described here. The shell script scan.sh is particularly interesting and designed\r\nto search for misconfigured Docker environments and deploy malware. In a comment we found a link to the main\r\nserver TeamTNT used in the past, teamtnt[.]red . It looks like the server is offline.\r\nInterestingly this account also contains the fork of an argo workflows project. Could it be that TeamTNT is\r\nplanning something in the future to exploit this application?\r\nFinal Thoughts\r\nTeamTNT was highly active between 2020 and 2021. They had used many tools and techniques in their\r\ncampaigns and had launched them frequently. Some of these tools had been designed to escape from container\r\nenvironments, steal tokens and credentials, scan and attack local and external networks, hide activities with\r\nrootkits, and more.\r\nNow TeamTNT appears to be back with new tricks. We are still assessing if these three attacks are a sign that they\r\nhave resumed their campaigns against cloud native environments or not.\r\nRegardless of the question if TeamTNT is back or not, we strongly encourage organizations to empower their\r\nsecurity teams with Cloud Native Application Protection Platform (CNAPP) solutions that cover various stages of\r\nthe cloud development pipeline and enable greater visibility and context.\r\nAssaf is the Director of Threat Intelligence at Aqua Nautilus. He is responsible of acquiring threat intelligence\r\nrelated to software development life cycle in cloud native environments, supports the team's data needs, and helps\r\nAqua and the ecosystem remain at the forefront of emerging threats and protective methodologies. His research\r\nhas been featured in leading information security publications and journals worldwide, and he has presented at\r\nleading cybersecurity conferences. Notably, Assaf has also contributed to the development of the new MITRE\r\nATT\u0026CK Container Framework.\r\nAssaf is leading an O’Reilly course, focusing on cyber threat intelligence in cloud-native environments. The\r\ncourse covers both theoretical concepts and practical applications, providing valuable insights into the unique\r\nchallenges and strategies associated with securing cloud-native infrastructures.\r\nAsaf Eitani\r\nAsaf is a Security Researcher at Aqua Nautilus research team. He focuses on researching Linux malware,\r\ndeveloping forensics tools, and analyzing new attack vectors in cloud native environments. In his spare time, he\r\nlikes painting, playing beach volleyball, and carving wood sculptures.\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 10 of 11\n\nSource: https://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nhttps://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt\r\nPage 11 of 11\n\n https://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt \ndc.sh shell file \nThis file contains two very interesting functions designed to exploit the release_agent vulnerability in order to\nescape to the host from the container. You can further read about it here in a previous blog from our team.\n Page 7 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.aquasec.com/new-malware-in-the-cloud-by-teamtnt" ], "report_names": [ "new-malware-in-the-cloud-by-teamtnt" ], "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": 1775434495, "ts_updated_at": 1775791965, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4b77bb19c7ec1981844875df9a25eb8591ac937d.pdf", "text": "https://archive.orkl.eu/4b77bb19c7ec1981844875df9a25eb8591ac937d.txt", "img": "https://archive.orkl.eu/4b77bb19c7ec1981844875df9a25eb8591ac937d.jpg" } }