{ "id": "3beee2a2-0976-4f71-aea4-53cb1b3af6bf", "created_at": "2026-04-06T00:22:05.344919Z", "updated_at": "2026-04-10T03:27:04.776273Z", "deleted_at": null, "sha1_hash": "5990239edd77c73c031624b123c3bce1c9ac918c", "title": "TeamTNT Reemerged with New Aggressive Cloud Campaign", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 3983820, "plain_text": "TeamTNT Reemerged with New Aggressive Cloud Campaign\r\nBy Ofek Itach Ofek Itach was a Senior Security Researcher at Aqua Nautilus research team.\r\nPublished: 2023-07-13 · Archived: 2026-04-05 16:59:20 UTC\r\nIn part one of this two-part blog series, titled The Anatomy of Silentbob’s Cloud Attack we provided an overview\r\nof the preliminary stages of an aggressive botnet campaign that aimed at cloud native environments. This post will\r\ndive into the full extent of the campaign and provide a more comprehensive exploration of an extensive botnet\r\ninfestation campaign.\r\nThe botnet run by TeamTNT has set its sights on Docker and Kubernetes environments, Redis servers, Postgres\r\ndatabases, Hadoop clusters, Tomcat and Nginx servers, Weave Scope, SSH, and Jupyter applications.\r\nDuring our research, Aqua Nautilus managed to access TeamTNT’s Command and Control (C2) server, a move\r\nthat enabled us to collect invaluable intelligence about the victims, the targeted environments, the arsenal at the\r\nattacker’s disposal, and the tactics employed in this campaign.\r\nBased on our research, we have discerned that this botnet perpetually scans the entirety of the internet.\r\nConsequently, every IP address undergoes a scan at least once every hour. We discovered that the rate of infection\r\nis fairly rapid, with a minimum of two new victims emerging every hour.\r\nThe infrastructure\r\nWe recently uncovered an emerging campaign that is targeting exposed Docker APIs and JupyterLab instances.\r\nUpon further investigation of the infrastructure, we found evidence of a broader campaign orchestrated by\r\nTeamTNT.\r\nFigure 1 – Interactive attack graph, you can control the attack graph by choosing specific elements in the attack\r\nThe IP address 45[.]9[.]148[.]108 is registered to NiceIT-NL, a company that provides domain names and web\r\nhosting services. In many cases, a single server is shared by multiple customers, making it challenging to link\r\nmalicious activity to a specific entity from an external viewpoint.\r\nHowever, despite these challenges, we managed to trace a significant amount of activity related to TeamTNT back\r\nto this IP address.\r\nFigure 2 – Interactive Virus Total graph of the C2 server of TeamTNT\r\nAs illustrated in Figure 2 above, the subdomains on the AnonDNS website, are associated with TeamTNT. They\r\nall point to the same cloud native campaign, which aims to infect systems with their cloud worm.\r\nSo far, we have identified the following subdomains involved in this campaign:\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 1 of 21\n\nhttp[:]//silentbob[.]anondns[.]net\r\nhttp[:]//everlost[.]anondns[.]net\r\nhttp[:]//everfound[.]anondns[.]net\r\nhttp[:]//ap-northeast-1[.]compute[.]internal[.]anondns[.]net\r\nThe trend in activity strongly suggests that TeamTNT is still in the process of building, refining, and preparing\r\ntheir campaign.\r\nFigure 3 – DNS queries trend taken from our honeypots\r\nTeamTNT’s toolbox\r\nThe following are files that TeamTNT deposited on our diverse array of honeypots during the execution of their\r\ncampaign.\r\nName  Type  MD5  Description \r\npriv8.sh\r\nshell\r\nscript\r\ncc61a23b635405c4b2f2f6dd1893ac7b changes iptables\r\ndata.sh\r\nshell\r\nscript\r\n5d4f7c74b2d89377a1c0fe1a4db15779 Discovery tool\r\naws.sh\r\nshell\r\nscript\r\n99f0102d673423c920af1abc22f66d4e Credentials stealer\r\ngrab.sh\r\nshell\r\nscript\r\n5daace86b5e947e8b87d8a00a11bc3c5 Credentials stealer\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 2 of 21\n\nclean.sh\r\nshell\r\nscript\r\n7044a31e9cd7fdbf10e6beba08c78c6b Remove cron, cleans bad tools\r\ncurl.sh\r\nshell\r\nscript\r\nfb88d462dba2d9c51fbbf034d1c28ea6\r\nDeploys curl to allow downloading\r\npayloads\r\nint.sh\r\nshell\r\nscript\r\ncfb6d7788c94857ac5e9899a70c710b6 Download tools and deploy backdoors\r\npacu.sh\r\nshell\r\nscript\r\ne9be1816a7814acd5fe0b124ecb5bf08\r\nDeploys Pacu – a Python AWS\r\nexploitation package\r\nscan.sh\r\nshell\r\nscript\r\nc1a0f9d67c47ae5d7a34a63d5f1cf159 Deploys scanner on infected hosts\r\nscope.sh\r\nshell\r\nscript\r\na827e07bd36e1e7c258fb27a18029e7a\r\nDeploys Weave Scope on infected k8s\r\nclusters\r\nsecure.sh\r\nshell\r\nscript\r\na579ab8b4f5ffc0c1a82ba818621eced Deploys various Linux tools\r\nuser.sh\r\nshell\r\nscript\r\n92d6cc158608bcec74cf9856ab6c94e5 Deploys SSH backdoor\r\nrun.sh\r\nshell\r\nscript\r\nDeploys malware and worm\r\nkube.sh\r\nshell\r\nscript\r\n5dad05ea17d53edb43aa273654db7378 Secret theft from k8s environments\r\nkubew.sh\r\nshell\r\nscript\r\nff43150d9ae2f906be4ac3911dd8da0d Deploys Gsocket backdoor\r\nngrok.sh\r\nshell\r\nscript\r\nf3d2a7861b25cb92541c066650ddee3f Deploys Ngrok backdoor\r\nb.sh\r\nshell\r\nscript\r\nf60b75ddeaf9703277bb2dc36c0f114b\r\nContains various other scripts to\r\ndeploy malware and backdoors\r\ngscat.sh\r\nshell\r\nscript\r\nf474ef57b8d4c767273927120e1c9b90 Deploys Gsocket backdoor\r\nx3c.sh\r\nshell\r\nscript\r\n92307435bfac8498bc03fd9370c9d1cd\r\nDeploys cryptominer and rootkit to\r\nhide it\r\ntmate.sh\r\nshell\r\nscript\r\nf13b8eedde794e2a9a1e87c3a2b79bf4 Deploys a backdoor\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 3 of 21\n\naws.meta.sh\r\nshell\r\nscript\r\n575ca10c3fb2adeb766cae815090f5ef\r\nStealing AWS credentials by\r\nexploiting the meta-data server\r\npeirates.sh\r\nshell\r\nscript\r\n519f86ac6c71c736fdadbb7ff37b6c2d A k8s pen test tool\r\ngscat.php\r\nphp\r\nscript\r\n3da71d66e91ebe0876d2fa451fe27e95 Deploys Gsocket backdoor\r\na binary 87c8423e0815d6467656093bff9aa193 Tsunami malware\r\nzgrab binary 26c8f6597826fbdebb5df4cd8cd34663 Scanning tool\r\nscan binary 203fe39ff0e59d683b36d056ad64277b Scanning tool\r\nchmod binary c77cbb5879170acbf6018ee2e141cc7e Linux tool\r\ncharattr binary 2044446e6832577a262070806e9bf22c Linux tool\r\nxmrig binary 4dc1884527550dc27bd5dfc54b9ae433 Cryptominer\r\nngrok binary cc7f8017eebb512b17aa08d09b45b3e9 Linux tool\r\ntmate binary 4061502ba7be7db37d0cd9bc224b1027 Linux tool – allow opening backdoors\r\n1.0.4.tar.gz\r\nTAR\r\nfile\r\nb66fe14854d5c569a79f7b3df93d3191 TAR file – contains masscan\r\nMind that all the above mentioned artifacts were uploaded to VirusTotal.\r\nThe targeted environments\r\nThe following are the targeted environments as identified in the scripts, as well as from observed attacks against\r\nour honeypots and actual organizations:\r\nName Description\r\nKubernetes\r\nclusters\r\nTeamTNT is looking for misconfigured API servers, etcd and kubelet APIs, trying to\r\nextract secrets from the API server, list the content of etcd and list running pods via\r\nkubelet API.\r\nDocker API\r\nTeamTNT is looking for misconfigured Docker API that allows access and code\r\nexecution to everyone. They are often running malicious containers they host on\r\nDocker Hub or vanilla containers such as alpine:latest and add malicious commands\r\nWeave Scope\r\nTeamTNT is looking for Weave scope instances with no authentication and exploit\r\nthese k8s dashboards to get shell access and run malicious code\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 4 of 21\n\nJupyterLab and\r\nJupyter Notebook\r\nTeamTNT is looking for Juypter (lab and notebook) instances with no authentication\r\nand exploit these services to get shell access and run malicious code\r\nRedis servers\r\nWe’ve seen indications in the IRC channel that Redis servers were infected, we’re not\r\nsure regarding this attack vector by TeamTNT. In general, exposed Redis servers can\r\nbe exploited by various vulnerabilities and misconfigurations\r\nHadoop\r\nWe’ve seen actual attacks against Hadoop services. We’re still investigating this attack\r\nvector and aren’t sure how this attack vector is exploited by TeamTNT. In general,\r\nHadoop clusters can be exploited by various vulnerabilities and misconfigurations\r\nWe also saw some tests made with various vulnerabilities and misconfigurations in applications and environments\r\nsuch as Tomcat, Nginx, add ssh access.\r\nExploiting public container registries to deploy malware\r\nTeamTNT is recognized for utilizing Docker Hub’s public registry to distribute their malware. Our Team Nautilus\r\nfrequently reports to Docker Hub about malicious activities occurring on their public registry. The following\r\ncontainer images were used in this current campaign:\r\nName  Description \r\nshanidmk/jltest2:latest Scan for Jupyter Lab instances\r\nshanidmk/jltest:latest  Stores a compiled Zgrab\r\nshanidmk/sysapp:latest  Docker scan and infect with Tsunami malware and cryptominer\r\nshanidmk/blob:latest  Docker scan and infect with Tsunami malware and cryptominer\r\n524470869/dasd:latest  Docker scan and infect with Tsunami malware and cryptominer\r\n524470869/dscan:latest  Docker scan and infect with Tsunami malware and cryptominer\r\nWe notified Docker Hub about these malicious users and container images.\r\nThe scanning mechanism\r\nEach target in this campaign is infected with malware and runs a worm script that operates in three stages:\r\n1. Scanning the internet for potential victims.\r\n2. Infecting the newly identified victims with the malware and worm (example can be seen in the technique\r\nsection below).\r\n3. Reporting back to the Command and Control (C2) server about the compromised victims. Figure 4 –\r\nScanning operation of TeamTNT’s botnet.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 5 of 21\n\nFigure 4 – Scanning operation of TeamTNT’s botnet\r\nThis botnet is notably aggressive, rapidly proliferating across the cloud and targeting a wide array of services and\r\napplications within the Software Development Life Cycle (SDLC). It operates at an impressive speed,\r\ndemonstrating remarkable scanning capability.\r\nThe botnet is designed to communicate with a central C2 server to determine the next range of IP addresses to\r\nscan. Each compromised system, or ‘victim’, involved in scanning the internet, queries the C2 server to receive a\r\nnumber between 1 and 255. This number corresponds to the first octet of the IP range in a /8 CIDR block, which\r\nencompasses approximately 17 million IP addresses.\r\nIn our experiment, we observed that each number (1-255) in the first octet is selected six times per minute. This\r\nsuggests that for each number in the first octet, there are six compromised servers scanning the internet for\r\nvulnerable targets every minute.\r\nUsing Masscan, a tool renowned for its high-speed scanning capabilities, we estimate that a /8 CIDR range can be\r\nscanned within three minutes for a specific port. Based on these calculations, we estimate that each IP address is\r\nscanned approximately once every 30 seconds. This level of scanning frequency is truly remarkable.\r\nTo validate our hypothesis, we examined a dedicated honeypot and observed a significant increase in Docker API\r\nscanning activity, while the scanning frequency of other ports remained consistent. Over a two-week period, we\r\nrecorded 440 scans, suggesting that each IP address worldwide is scanned approximately 1.3 times per hour.\r\nDespite being more moderate than some estimates, this frequency still represents a significant volume of scanning\r\nactivity.\r\nIn the eye of a Tsunami\r\n0:00 / 1:08\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 6 of 21\n\nOver the years, TeamTNT has consistently used Tsunami malware as part of their tactics, techniques, and\r\nprocedures (TTPs), and this campaign is no exception. Tsunami is a type of malware, specifically a botnet, that\r\nprimarily targets Linux systems.\r\nA key feature of Tsunami is its ability to connect to a Command and Control (C2) server using the Internet Relay\r\nChat (IRC) protocol. This server is used to control the botnet, issuing commands to the infected systems. The C2\r\nserver operates through IRC channels, functioning like chat rooms on the IRC network. Each infected system\r\njoins a specific channel on the IRC server, where it waits for commands.\r\nThese commands can instruct the botnet to download additional malware or perform other malicious activities,\r\neffectively transforming the infected system into a backdoor for various nefarious purposes.\r\nTsunami includes features to maintain its presence on the infected system, such as hiding its processes and files to\r\navoid detection. It can also automatically reconnect to the C2 server if the connection is lost, ensuring sustained\r\ncontrol over the compromised system.\r\nBy connecting to the IRC channel of TeamTNT’s Tsunami malware, one can observe all the infected machines,\r\nthe commands sent from the C2, and the targets.\r\nFigure 5 – Screenshot from the IRC channel #AWS used as Command and Control server\r\nOver a span of 7 days, we observed 196 unique infected hosts. This equates to ~1.3 new victims every hour. Given\r\nthat this campaign is aggressively scanning the internet for exposed Docker APIs, Jupyter Lab and Notebook\r\ninstances, Redis servers, SSH connections, and Weave Scope applications, it can rapidly infect new hosts that are\r\nexposed even for a brief moment.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 7 of 21\n\nUnderstanding the techniques used by TeamTNT\r\nIn the following section, we delve into the various techniques that TeamTNT employs as part of their campaign.\r\nInitial Access\r\nIn figure 6 below, you can see our Honeypots alert system indicates a malicious container deployed. You can see\r\nthe vanilla image alpine:latest with a malicious command, mounting the ‘/host’, decoding (base64) and running an\r\nencoded command and downloading aws.sh script from the C2 server.\r\nFigure 6: A screenshot taken from our honeypot’s alert system\r\nExecution\r\nIn terms of execution and the download command is a bash implementation used to download scripts and binaries\r\nfrom the C2 server. It receives an address, parses it, and downloads the available files\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 8 of 21\n\nFigure 7: Execution examples\r\nPersistence\r\nWe’ve seen 4 types of backdoors used by TeamTNT. The first one was by creating a new account by modifying\r\nthe passwd, shadow and sudoers files. First the files’ permissions are modified so they can be modified. Next\r\nunder the use system the data is inserted or modified.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 9 of 21\n\nFigure 8: the make_user_axx() function which creates new users\r\nThe passwd file contains information about the users in the system. Per each user, the username, password, user\r\nID, group ID, Home directory and command shell.\r\nThe shadow file stores hashed passphrases of the users’ accounts.\r\nThe sudoers file stores the system privileges of the users.\r\nIn the script above TeamTNT creates or runs over the user ‘system’, it got listed in the sudoers file with the\r\nhighest privileges to the system.\r\nBelow in figure 9, you can see that TeamTNT is creating an SSH backdoor by inserting their own RSA key. In\r\naddition, they are altering the SSH configuration to prevent access from known hosts, while making the\r\nconfiguration more flexible to SSH connection by them.\r\nFigure 9: the make_user_axx() function which creates new users\r\nFigure 10 below, illustrates a function that is creating a hidden backdoor. This is very similar to the previous\r\nmechanism in figure 9 above. Here the user is games. This function also creates an SSH backdoor, allowing\r\nTeamTNT backdoor access to the server via SSH.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 10 of 21\n\nFigure 10: the make_hiden_door() function which creates ssh backdoor\r\nAs can be seen in figure 11 below, once the user and password were created, the access command (with the\r\ncredentials) is sent to the C2 server of TeamTNT.\r\nFigure 11: the get_ssh_link() function which reports to TeamTNT about a newly acquired backdoor\r\nThe second one was by using Gsocket, as seen in the execution command in figure 12 below, TeamTNT is using\r\nPHP to execute a script that runs on a compromised server.\r\nFigure 12: Opening backdoor on attacked server with gscat.php\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 11 of 21\n\nThis is a snippet from the gscat.php script, and as illustrated is set to download x, which is Gsocket, which is a\r\npowerful reverse shell tool that allows for the creation of secure, always-on, global server sockets. Essentially, it\r\nenables you to create a network socket that is accessible from anywhere on the internet, bypassing NAT and\r\nfirewalls by using the Global Socket Relay Network to route the traffic.\r\nFigure 13: A couple of snippets from the Gsocket infection script\r\nThe third backdoor is by using a webshell of tmate[.]io. Tmate is legitimate software serves as a terminal\r\nmultiplexer with instant terminal sharing: it enables a number of terminals to be created, accessed, and controlled\r\nfrom a single screen and be shared with another mates. In figure 14 below, you can see how TeamTNT is utilizing\r\nthis tool as a backdoor.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 12 of 21\n\nFigure 14: Tmate backdoor execution script\r\nThe fourth backdoor is by utilizing a socket connected over HTTP service with Ngrok product.\r\nAnother interesting persistence technique we’ve seen in the campaign is removing the execution of runc when the\r\ninitial access is via misconfigured Docker API. This is a new type of persistence we offer to MITRE, as it didn’t\r\nappear in record. TeanTNT is locking runc, which effectively locks the misconfiguration and closes the access to\r\nthe compromised server. They are doing it to prevent from other campaigns to access the server and remove their\r\nattack, hence gaining persistence to their attack from competing campaigns.\r\nFigure 15: Changing runc so it won’t execute to block exposed Docker API initial access vector to increase\r\npersistence\r\nAs can be seen in figure 15 above, TeamTNT delete the malicious container with which they gained the initial\r\naccess, thus reducing the chances of detection. Then they run chmod -x on container runtime component, which\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 13 of 21\n\nprevents it from being executed. Thus, preventing from other attackers to exploit the misconfiguration of exposed\r\nDocker API and blocking the initial access. This increases the persistence of the attack.\r\nIn part 1 of this blog, we reported about TeamTNT’s cloud worm – silent bob. In one of the containers, TeamTNT\r\nused an interesting persistence technique. They ran the container with the --restart=always flag, which means\r\nthat if for some reason the container stops it will always attempt restarting, hence creating a new persistence\r\ntechnique.\r\nFigure 16: A part of the botnet infection script, containing docker execution with high privilege and persistence\r\nPrivilege escalation\r\nAs depicted in figure 16 above, TeamTNT is running the container as a privileged one, and mounting the host, this\r\nenables privileged access to the host.\r\nDefense evasion\r\nIn figure 16 above, TeamTNT is using dload() function which is utilizing dev/tcp to invoke communication\r\nand download payloads, instead of using wget or curl which might be monitored or don’t exist on the machine.\r\nThis helps them evade detection.\r\nTeamTNT is using prochider rootkit to hide cryptomining execution. As seen in figure 17 below, TeamTNT is\r\nwriting to /tmp/ld.so an SO file which contains prochider. It is moved to /dev/shm and loaded to ld.preload .\r\nThis will ensure the prochider is running and hiding the xmrig in processes whenever the user is running ps,\r\nfor instance, to check running processes.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 14 of 21\n\nFigure 17: this function deploys prochider rootkit hidden in ldpreload.\r\nCredential Access\r\nIn the script grab.sh depicted in Figure 18 below, you can see the types of credentials that TeamTNT’s scripts\r\nare designed to scan for.\r\nFigure 18: Some lists of credential files that TeamTNT is looking to extract from targeted hosts.\r\nAs depicted in Figure 19 below, the get_azure() function is designed to scan for Azure configuration files,\r\nwhich can include sensitive information such as secrets and environment data.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 15 of 21\n\nFigure 19: the get_azure() function reflects what TeamTNT is looking for in Azure cloud\r\nAs shown in Figure 20 below, the ‘get_google()’ function is configured to scan for Google Cloud Platform (GCP)\r\nconfiguration files, which can include sensitive information such as secrets and environment data.\r\nFigure 20: the get_google() function reflects what TeamTNT is looking for in GCP\r\nTeamTNT is scanning for credentials across multiple cloud environments, including AWS, Azure, and GCP. They\r\nare not only looking for general credentials but also specific applications such as Grafana, Kubernetes, Docker\r\nCompose, Git access, and NPM. Additionally, they are searching for databases and storage systems such as\r\nPostgres, AWS S3, Filezilla, and SQLite. They are also targeting more unique systems such as ngrok data, Samba,\r\nCensys, and others. This indicates that TeamTNT has evolved alongside the industry, shifting from solely targeting\r\ncontainers (as seen in 2019) to becoming a threat actor that targets cloud native applications. As the attack surface\r\nexpands, they are leveraging the expertise they’ve gained in the cloud over the past few years to gain initial\r\naccess, move laterally across the cloud, and deploy backdoors and further malware for their benefit.\r\nFrom k8s clusters, TeamTNT is collecting cluster secrets with the function illustrated in figure 21 below:\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 16 of 21\n\nFigure 21: TeamTNT collects cluster secrets using this function\r\nWith the curl command, using the token, TeamTNT is calling the secrets via the API server. With the second\r\nfunction TeamTNT is collecting further information about the environment, such as pods, deployments, secrets\r\nand daemonsets.\r\nDiscovery\r\nThe e nv_aws() function is used to connect to AWS meta-data server to collect sensitive infotmation about the\r\naccount, such as keys, secrets, IAM roles etc.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 17 of 21\n\nFigure 22: the envaws() function reflects what TeamTNT is looking for in AWS\r\nThe next 3 functions are very interesting. TeamTNT is collecting information about AWS, Azure, Kubernetes and\r\nrunning containers from running containers, processes and AWS configuration files.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 18 of 21\n\nFigure 23: further credentials sought by TeamTNT\r\nDownloading kubectl tool to better query the k8s cluster.\r\nFigure 24: downloading kubectl tool to better explore k8s environments\r\nAs seen in figure 25 below, TeamTNT is running 2 functions to discover the k8s environment, more specifically\r\nthe sysvars and namespaces.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 19 of 21\n\nFigure 25: further discovery of k8s environments\r\nAs depicted in figure 26 and 27 below, TeamTNT is running in pacu.sh, a pip install command to install Pacu\r\nPython package. In the second figure you can see the configuration of what TeamTNT is looking for. They are\r\nafter various AWS services, including EC2, Glue, Lambdas, and Lightsail, which is a virtual private server (VPS)\r\nprovider and is the easiest way to get started with AWS for developers, small businesses, students, and other users\r\nwho need a solution to build and host their applications on cloud. In the past it was reported as an interesting\r\nattack vector, since it is aimed for less proficient practitioners, thus more susceptible to misconfigurations.\r\nFigure 26: Pacu package on Pypi\r\nFigure 27: Pacu configuration file\r\nCommand and Control\r\nTeamTNT is using Tsunami malware, as explained above, this is done by deploying and executing ELF files (a,\r\nsystem, systems). In figure 28 below you can see command execution via IRC channel.\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 20 of 21\n\nFigure 28: IRC commands passed to infected hosts\r\nImpact of TeamTNT on the Software Development Lifecycle\r\nTeamTNT doesn’t directly compromise the code creation phase. However, their actions can indirectly impact code\r\nsecurity. By targeting source code management applications such as GitHub they can impact organizations code,\r\nand even open a supply chain attack vector.\r\nIn the same manner TeamTNT can affect the CI/CD and Build processes by compromising GitHub or NPM. In\r\naddition, they are extensively scanning for misconfigured Kubernetes (k8s) clusters, Docker API, and Weave\r\nScope. They can attack any of these stages: development, staging and production environments and compromise\r\nany of them. By exploiting misconfigurations in these components, or stealing artifact registries secrets, they can\r\ngain unauthorized access to the CI/CD pipeline infrastructure, potentially compromising the build process,\r\ninjecting malicious code, or tampering with build artifacts. This can lead to the deployment of compromised or\r\nvulnerable applications into the runtime environment.\r\nIn the runtime phase, TeamTNT targets cloud native environments and cloud service providers. As mentioned\r\nabove, they extensively seek for misconfigurations in Docker and K8s environments, and they seek unauthorized\r\naccess to data and secrets stored in services such as Glue, S3 buckets, and Lambdas. By compromising these\r\nresources, they can potentially gain access to sensitive data, manipulate runtime configurations, or disrupt the\r\nnormal operation of the applications.\r\nAttributing this campaign to TeamTNT\r\nThe infrastructure in question shares significant similarities with previous campaigns attributed to TeamTNT,\r\nincluding the same coding style, similar infrastructure choices, targeting similar systems, and employing\r\ncomparable tools and coding conventions. However, the focus this time seems to be more on infecting systems\r\nand testing the botnet, rather than deploying cryptominers for profit.\r\nTeamTNT was known for its unique approach, often communicating with researchers through ASCII art, Twitter,\r\nand embedded messages in their code and malware. However, in this latest round of activity, after seemingly\r\ncoming out of retirement, they have become noticeably less communicative.\r\nSource: https://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nhttps://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/\r\nPage 21 of 21", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MITRE" ], "references": [ "https://www.aquasec.com/blog/teamtnt-reemerged-with-new-aggressive-cloud-campaign/" ], "report_names": [ "teamtnt-reemerged-with-new-aggressive-cloud-campaign" ], "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 } ], "ts_created_at": 1775434925, "ts_updated_at": 1775791624, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/5990239edd77c73c031624b123c3bce1c9ac918c.pdf", "text": "https://archive.orkl.eu/5990239edd77c73c031624b123c3bce1c9ac918c.txt", "img": "https://archive.orkl.eu/5990239edd77c73c031624b123c3bce1c9ac918c.jpg" } }