{
	"id": "4ec77a17-d9a1-42b7-859f-07f982d645f7",
	"created_at": "2026-04-06T00:22:34.085659Z",
	"updated_at": "2026-04-10T03:27:04.676716Z",
	"deleted_at": null,
	"sha1_hash": "3f6cf8dc6691538a411cd471e77fd9c8fee5d2f1",
	"title": "Threat Alert: Anatomy of Silentbob’s Cloud Attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 984497,
	"plain_text": "Threat Alert: Anatomy of Silentbob’s Cloud Attack\r\nBy Ofek Itach Ofek Itach was a Senior Security Researcher at Aqua Nautilus research team.\r\nPublished: 2023-07-05 · Archived: 2026-04-05 21:40:35 UTC\r\nAqua Nautilus researchers identified an infrastructure of a potentially massive campaign against cloud native\r\nenvironments. This infrastructure is in early stages of testing and deployment, and is mainly consistent of an\r\naggressive cloud worm, designed to deploy on exposed JupyterLab and Docker APIs in order to deploy Tsunami\r\nmalware, cloud credentials hijack, resource hijack and further infestation of the worm. We strongly believe that\r\nTeamTNT is behind this new campaign. In this blog, the first in our two part series, we will unfold the story of\r\nthis being developed attack infrastructure, speculate on the threat actor and the potential results of such a\r\ncampaign.\r\nIntegrated campaign on cloud resources\r\nOur investigation was prompted by an attack on one of our honeypots. After examining the container image and\r\nthe Docker Hub account, we identified four container images, including the one used in the attack on our\r\nhoneypot:\r\nFigure 1: Illustration of the relationships among the attacks\r\nshanidmk/jltest2 (updated: June 8, 2023): Its purpose is to detect exposed Jupyter Lab instances.\r\nshanidmk/jltest (updated: June 8, 2023): This image is used to compile Zgrab using the make command.\r\nshanidmk/sysapp (updated: May 25, 2023): This one seeks out and assaults exposed Docker Daemon instances.\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 1 of 12\n\nshanidmk/blob (updated: June 24, 2023): This container image is an updated version of sysapp and is intended\r\nto find exposed Docker Daemon instances. It releases a cryptominer and includes the Tsunami malware, which\r\nacts as a backdoor.\r\nWe reported these container images to Docker Hub who promptly removed the malicious images from the public\r\nregistry.\r\nIn the sections below, we explore each of these container images and discuss the unique set of tools devised by the\r\nattacker.\r\nshanidmk/jltest2 (44 pulls)\r\nThe first attack on our honeypot was launched in early June using this container image. Comprised of three layers,\r\none layer includes a run.sh shell script designed to initiate when the container starts up.\r\nFigure 2 illustrates the run.sh shell script, programmed to commence upon the startup of the shanidmk/jltest2\r\ncontainer.\r\nAs demonstrated in the figure 2 above, the process begins with the downloading of some packages to secure the\r\nnecessary utilities for the environments. Following this, the ZGrab application is built and relocated to the /bin\r\nlibrary. It’s crucial to note that ZGrab is an application layer scanner, developed with Go language, that enables\r\nthe attacker to perform banner grabbing. This function will later assist the attacker in identifying Jupyter Lab and\r\nDocker API.\r\nSubsequently, the masscan tool scans and pipes the IP to be utilized by ZGrab for assessing whether there is an\r\nexposed Jupyter Lab instance operating at  http://Currently_found_IP_Address:8888/lab . The resulting\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 2 of 12\n\ninformation is organized and stored in the JupyterLab.txt file, which is then transmitted to the attacker’s C2\r\nserver through a specific command.\r\nFigure 3 presents the curl command used to send the IPs of the exposed Jupyter Lab instances to the C2 server\r\nThe next step involves the activation of a loop set to run whenever the C2 server returns an IP range for scanning.\r\nThe first octet of the IP address is determined by the result of a curl command to the attacker’s C2 server, which\r\nsubsequently scans a CIDR range of /8, equating to approximately 16.7 million IP addresses.\r\nIt’s important to note that the HTTP_SOURCE environment variable was initially set by the attacker at the start of\r\nthe container.\r\nFigure 4 showcases the HTTP_SOURCE environment variable.\r\nThrough the use of NGROK, the attacker is able to conceal the infrastructure, thereby minimizing the risk of it\r\nbeing shut down.\r\nshanidmk/jltest (8 pulls)\r\nUpon examining the attacker’s Docker Hub account, we identified a particular container image. As suggested by\r\nits name, it appears to be an earlier version of the container image utilized in our attack. It seems that the attacker\r\ndeveloped this image to have a pre-compiled binary of zgrab, specifically tailored to meet the requirements of this\r\ncampaign. This indicates a considerable level of technical expertise and skill, allowing the attacker to customize\r\nthe binary to suit their needs.\r\nshanidmk/sysapp (11 pulls)\r\nThis container image is composed of six layers. Three of the layers encompass parts of the base image, basic\r\nfilesystem, and various utilities. One layer incorporates the ELF system\r\n(MD5=ba1b03bc2c262d724c0616eba9d7828b ), which is classified as a cryptominer according to VirusTotal.\r\nAnother layer houses ZGrab, while yet another contains the run.sh shell script, which is programmed to initiate\r\nas soon as the container starts.\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 3 of 12\n\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 4 of 12\n\nFigure 5 the shell script run.sh, set to run when the shanidmk/sysapp container start\r\nAs depicted in figure 5 above, a random initial octet of the IP address is chosen. It is then passed to the function\r\npwn_d along with the random range, a potentially exposed Docker Daemon port, and a rate ( 2375, 2376, 2377,\r\n4244, 4243 ).\r\nThe pwn_d function, based on the provided arguments, scans for misconfigured docker daemons v1.16. The\r\nsyntax timeout -s sigkill signifies that a timeout signal will be sent to terminate the docker info or run\r\ncommand issued by this function. The first docker info seeks to gather information about the target\r\nenvironment, while the second is a remote command to the docker daemon, commanding it to run a privileged\r\nalpine container. This container mounts the host filesystem, utilizes the host network, and executes an ‘echo’\r\ncommand of a base64 script.\r\nThe following figure 6 illustrates the second command executed by the attacker upon container start:\r\nFigure 6 – this is the second command the attacker is running\r\nAs seen in figure 6 above, the attacker persistently runs a privileged container that restarts, utilizes the host\r\nnetwork, and downloads the ELF files x.noback and x.back . These binaries were unavailable during our\r\ninvestigation; thus, we speculate that these could either be backup cryptominers or the Tsunami malware, a potent\r\nIRC-based backdoor. We will elaborate on this in the attribution section. In addition, the script retrieves the\r\nsetup_c3pool_miner.sh script , which is specifically designed to deploy a cryptominer.\r\nFinally, the script is configured to download aws.sh.txt . We strongly suspect that this script is designed to\r\nsystematically scan the environment for AWS keys and secrets, thereby enabling the attacker to steal them.\r\nshanidmk/blob (29 pulls)\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 5 of 12\n\nThis container image is composed of seven layers. Four of these layers house the base image and essential\r\nutilities. Two layers contain the Tsunami malware ( MD5=87c8423e0815d6467656093bff9aa193 ), as classified by\r\nVirusTotal. The remaining layer holds the shell script docker_entrypoint.sh , which is programmed to execute\r\nwhen the container launches.\r\nFigure 7 presents the docker_entrypoint.sh shell script:\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 6 of 12\n\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 7 of 12\n\nAs observable in figure 7 above, the attacker initiates the process by installing certain packages or dependencies to\r\nfacilitate the attack. Subsequently, the ELF systems ( MD5= 87c8423e0815d6467656093bff9aa193 ), classified as\r\nTsunami malware by VirusTotal, are executed. Following this, the attacker launches the TOR service to obscure\r\nnetwork communication.\r\nThe attacker then conducts a rate scan test by checking /proc/meminfo , which provides memory usage\r\ninformation. Based on this information and subsequent adjustments, the attacker determines the scan rate of\r\nmasscan.\r\nNext, a loop invokes the primary function dAPIpwn (Docker API pwn). The attacker employs anondns.net to\r\nmask his C2 server. Anondns is a DNS over HTTP service enabling the attacker to interact with his backend\r\nwithout revealing the actual address on the attacked server. The attacker has created a subdomain in the anondns\r\ndomain named silentbob , potentially a reference to the film “Jay and Silent Bob”, giving a clue to the attacker’s\r\nidentity.\r\nThe main function, dAPIpwn , randomly selects a file name and initiates a scan. It uses the proxychains3\r\napplication, which is designed to force any TCP connection made by any given TCP client to follow through a\r\nproxy (or proxy chain). Masscan then scans a specified range of approximately 16.7 million IP addresses in search\r\nof exposed Docker APIs.\r\nFor each target obtained, the function lists the images on the host with exposed Docker API. The output is then\r\nsent back to the C2 server.\r\nThere’s another function, upres() , which seems to be inactive. It is also designed to transmit information to the\r\nattacker’s C2 server.\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 8 of 12\n\nExposed JupyterLab servers in the wild\r\nOur goal was to gain a deeper understanding of the breadth of this campaign. Regrettably, our investigation of the\r\nattacks against our JupyterLab honeypots did not yield any evidence that our servers have been compromised by\r\nthis campaign. As a result, we turned to Shodan to help us identify 51 servers with exposed JupyterLab instances\r\nin the wild. All of these exposed instances had been actively exploited or had recently suffered exploitation\r\nattempts by an attacker.\r\nWe discovered a live manual attack on one of the servers that employed masscan to scan for exposed Docker\r\nAPIs. The scan range was set to 124 , and when we queried the attacker’s server\r\n( http[:]//silentbob[.]anondns[.]com ), the response was a number strikingly similar, further supporting our\r\nsuspicion that this is related to our campaign. To us, it appeared as if the attacker was conducting some tests.\r\nFurther analysis on other exposed hosts revealed more activity from this same attacker.\r\nFigure 8 – a random attacked server with similar patterns to our campaign\r\nFigure 9 – a random attacked server with similar patterns to our campaign #2\r\nCampaign analysis and attribution\r\nTo summarize our findings, we have identified four distinct container images. One of these was utilized in an\r\nattack on our misconfigured Docker API. These images were all recently uploaded to Docker Hub’s public\r\nregistry, yet cumulatively, they have received less than 100 pulls. Given that some functions in the code remain\r\nunused and the linked attack patterns suggest manual testing, we theorize that the attacker is in the process of\r\noptimizing their algorithm. Therefore, we speculate that this attack is yet to fully launch and it is likely to attract\r\nsignificant attention once it develops into a full-blown campaign.\r\nThe operation of this cloud worm can be illustrated as follows (see Gif below):\r\nInitially, the attacker identifies a misconfigured server (either Docker API or JupyterLab) and deploys a container\r\nor engages with the Command Line Interface (CLI) to scan for and identify additional victims. This process is\r\ndesigned to spread the malware to an increasing number of servers. The secondary payload of this attack includes\r\na cryptominer and a backdoor, the latter employing the Tsunami malware as its weapon of choice.\r\nGiven the specific Tactics, Techniques and Procedures (TTPs) observed, we firmly believe that the infrastructure\r\nfor this operation was established by none other than the cybercriminal group known as TeamTNT. Alternatively,\r\nit could be an advanced copycat, who not only emulates their code, but also mirrors their degree of sophistication,\r\naffinity for the Dutch language, and distinct sense of humor.\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 9 of 12\n\nTeamTNT is a notorious cybercriminal group that has gained prominence for its aggressive attacks on cloud-based\r\nsystems, especially those using Docker and Kubernetes environments. They specialize in cryptomining operations,\r\nbut their methods have evolved over time to incorporate a variety of other malicious activities.\r\nThe group initially made headlines by exploiting misconfigured Docker APIs to launch their attacks. They would\r\ninfect cloud systems with cryptominers, a tactic that has become increasingly common among cybercriminals due\r\nto the potential for significant financial gain. However, TeamTNT’s approach was unique for the level of\r\nsophistication and the scale at which they operated.\r\nAs their tactics evolved, they began to target unsecured Kubernetes installations and even added functionality to\r\ntheir malware that could steal AWS credentials, providing them with potentially vast access to resources and data.\r\nThey’ve also employed a worm-like feature to their malware, allowing it to spread itself across improperly\r\nconfigured or unsecured Docker and Kubernetes systems.\r\nOne key hallmark of TeamTNT’s operation is their extensive use of open-source tools. For instance, they used\r\ntools such as “Weave Scope,” which allowed them to visualize and interact with cloud environments, further\r\nextending their reach and effectiveness.\r\nIn addition, the group was known for its aggressive scanning of IP addresses, seeking exposed Docker APIs to\r\nexploit. They also cleverly concealed their command and control (C2) servers using services like DNS over HTTP\r\nto hide their actual addresses.\r\nHowever, as of our last update in September 2021, it appears that TeamTNT has ceased its activities. The reasons\r\nbehind this sudden halt are unclear; it could be due to heightened security measures, successful law enforcement\r\noperations, or an internal decision to discontinue operations.\r\nDespite this cessation of activities, the impact of TeamTNT’s campaigns is significant and provides essential\r\nlessons for the future. It highlights the critical importance of proper configuration and security measures in cloud\r\nenvironments. It also showcases how quickly and innovatively cybercriminal groups can evolve and adapt their\r\ntactics, using both traditional and emerging techniques to carry out their attacks.\r\nIt is crucial to note that while TeamTNT may have ceased its activities, the threat to cloud environments remains\r\nvery much alive. Other groups or individuals may adopt similar or more advanced tactics, making ongoing\r\nvigilance and robust security measures essential in today’s digital landscape.\r\nIn this campaign we’ve seen the following resemblance to TeamTNT’s TTPs:\r\n1. In figure 7 the rate_to_scan snippet and some sections of the dAPIpwn function were used in the\r\nwhatwillbe campaign.\r\n2. In figure 7 the dAPIpwn function was used in various previous campaigns by TeamTNT such as\r\ndockgeddon, chimaera , and others.\r\n3. In figure 6, the script aws.sh , was previously used by TeanTNT in various campaigns. But this is a fairly\r\nweak connection.\r\n4. When pinging the C2 server it replies in German, another mischief done by TeamTNT in the past.\r\n5. Tsunami malware was often used by TeamTNT in past campaigns.\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 10 of 12\n\nApplying MITRE ATT\u0026CK Framework to the TeamTNT attacks\r\nA summary that maps each component of the attack to the corresponding MITRE ATT\u0026CK framework and\r\ntechniques category:\r\n*Restart container: The container is running with the flag --restart=always , which creates a persistence in case\r\nthe container fails it will try to restart.\r\nIn summary\r\nLooks like TeamTNT or a TeamTNT copycat is preparing a campaign. We treat this as an early warning, and\r\nhopefully a prevention to the campaign. At this stage an infrastructure is being built to support a worm like\r\nexpansion across misconfigured Docker APIs and JupyterLAb instances. Below are few recommendations, when\r\npracticed together they can assist you against these kinds of attacks:\r\nImmediate basic steps:\r\n1. Ensure you’re not running JupyterLab without authentication, specifically make sure the token flag\r\nwhen running JupyterLab is not left empty.\r\n2. Verify that your Docker API isn’t exposed to the world and set to accept requests from 0.0.0.0.\r\n3. Secure Configuration and Hardening: Ensure that Docker daemons and cloud instances are properly\r\nconfigured and hardened. Implement secure configurations, including strong passwords, disabling\r\nunnecessary services, and limiting access to only trusted networks or IP ranges. Regularly update and patch\r\nDocker and cloud platforms to address any vulnerabilities.\r\n4. Least Privilege Principle: Apply the principle of least privilege to limit the permissions and capabilities of\r\ncontainers, Docker daemons, and cloud instances. Use appropriate user roles and access controls to restrict\r\nprivileges and minimize the potential impact of a successful attack.\r\n5. Scan the images that you use, making sure you are familiar with them and their use, using minimal\r\nprivileges such as avoiding root user and privileged mode. Use a vulnerability scanner such as Trivy (open\r\nsource).\r\n6. Investigate logs, mostly around user actions, look for any anomalous actions.\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 11 of 12\n\n7. Continuous Monitoring and Logging: Implement robust monitoring and logging solutions to detect and\r\nalert suspicious activities within your cloud environment. Monitor network traffic, container behavior, and\r\nsystem logs for indicators of compromise (IoCs) related to integrated attacks. Regularly\r\n8. Form a security strategy where you can enforce your policies with ease, consider using cloud security\r\ntools that will widen your scope and reach within your cloud resources.\r\nLook for part two in this blog series as we continue to discover more about Team TNT’s recent campaign\r\nSource: https://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nhttps://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.aquasec.com/blog/threat-alert-anatomy-of-silentbobs-cloud-attack/"
	],
	"report_names": [
		"threat-alert-anatomy-of-silentbobs-cloud-attack"
	],
	"threat_actors": [
		{
			"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": 1775434954,
	"ts_updated_at": 1775791624,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3f6cf8dc6691538a411cd471e77fd9c8fee5d2f1.pdf",
		"text": "https://archive.orkl.eu/3f6cf8dc6691538a411cd471e77fd9c8fee5d2f1.txt",
		"img": "https://archive.orkl.eu/3f6cf8dc6691538a411cd471e77fd9c8fee5d2f1.jpg"
	}
}