{
	"id": "d865a88c-a356-41ca-b34d-071eae70b4d2",
	"created_at": "2026-04-06T02:11:27.538081Z",
	"updated_at": "2026-04-10T03:30:57.043399Z",
	"deleted_at": null,
	"sha1_hash": "8332803119bcc8679f311360bca98d6572b5b4af",
	"title": "Deep Analysis of TeamTNT Techniques Using Container Images to Attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1100021,
	"plain_text": "Deep Analysis of TeamTNT Techniques Using Container Images to\r\nAttack\r\nBy Assaf Morag\r\nPublished: 2020-08-25 · Archived: 2026-04-06 02:08:23 UTC\r\nEver notice how news about hidden malware almost always focuses on remediation AFTER the fact? So did we.\r\nEven now, there’s yet another news story about a rash of attacks by a group called TeamTNT. They used a crypto-mining worm to steal AWS credentials from Docker Hub. Well, if hijacking cloud resources is so popular, it’s time\r\nto make finding threats BEFORE the attack just as fashionable. Our investigation determined that dynamic\r\nanalysis could have saved some overworked security teams a lot of time and aggravation — if these images were\r\ndetected and removed from Docker Hub before being deployed — in much the same way it helps security teams\r\nwith their private registries.\r\nWe at Team Nautilus detected and analyzed the Docker Hub account hildeteamtnt, which was used by TeamTNT\r\nto store their malicious images. We ran these images in a secure container sandbox and uncovered a total of eight\r\nmalicious container images, with at least two of these images being used to perform attacks in the wild. Here’s\r\nwhat was found:\r\nImages in the hildeteamtnt account\r\nThe images were well-designed and meticulously built to fully exploit the targeted host. The adversaries hid\r\nvarious malware executables (Tsunami and Mirai), backdoors, Docker escape tools, and Potentially Unwanted\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 1 of 8\n\nApplications (PUAs) inside these images. In each image, they used scripts to execute their nefarious attacks, some\r\nof which were simple and straightforward, while others were complex and sophisticated:\r\n1. Simple and straightforward attacks: ‘metal3d’, ‘first’ and ‘dockerfirst’ are images were designed to\r\nlaunch a simple resource hijacking attack (Cryptominer).\r\n2. Sophisticated attacks: ‘Minerescape’ and ‘Debian-service’ contain a binary named docker-escape. The\r\nbinary is based on a tool in GitHub docker-escape-tool. Designed to identify if it’s running in a Docker\r\ncontainer, it then attempts Docker escape techniques.\r\nFor instance, this binary contains some of the following strings:\r\n.docker_escape network – Attempts to escape via Docker TCP socket (if found on any interfaces) or Port\r\nscans (if network namespace shared with the host).\r\n.docker_escape auto – Attempts automatic escape. If successful, this starts a privileged container with the\r\nhost drive mounted at /hostOS.\r\n.docker_escape Unix – Attempts an escape using a mounted Docker UNIX socket located at\r\n/var/run/docker.sock.\r\nAlso, ‘minerescape’ contained a shell script executing a Python file – minedaemon.py. The file nightminer.py\r\nallows the execution of the crypto mining process.\r\n3. Highly sophisticated attacks: Since the first tool ‘xmrigminer’ was uploaded on March 28, 2020, adversaries\r\nworked to perfect it by revising their scripts and adding more and more techniques to evade detection, hide\r\ncommunication channels with command and control servers, and gain persistence over time. The second image\r\n‘avscan’ is a more sophisticated version (described below) and the last and recent version ‘docrunker’ is even\r\nworse.\r\nDeep Analysis of AVscan\r\nThe adversaries used a known technique aimed at taking over the host by mounting the host / dir into /mnt in the\r\ncontainer and then chrooting into /mnt.\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 2 of 8\n\nAVscan.sh\r\nThe entry point for the image is the script AVscan.sh:\r\nFollowing that command, the image is designed to run the scripts Carray.sh, cron.sh, and execute two malicious\r\nbinaries SystemHealt and AVscan. The command vm.nr_hugepages is a system property that is designed to\r\nincrease the efficacy of the crypto-mining process.\r\nThe scripts Carray.sh and cron.sh are already stored inside the image layers.\r\nCarray.sh\r\nThe shell script Carray.sh is designed to kill any competing mining processes running on the host. The script also\r\ndeletes itself after it is executed.\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 3 of 8\n\nCron.sh\r\nThe shell script Cron.sh sets a cron job to download  minion.sh from:\r\nhxxp [:] //yd6ugsklvmydbvmntk54k4dmgkuwzar3u3zzv5vcxwdywjwbwzjmdryd [.] tor2web [.] su/…/minion.sh\r\nMinion.sh\r\nSome of the snippets in this script are encoded with Based64. The adversaries decode this code into new files\r\nusing innocuous or misleading names such as: pu,ntpd.pid,.logs.c, etc. They also hide some of the files they are\r\nwriting to disk. Below are three examples of what this script is doing:\r\nOne file (/usr/bin/hid) is trying to mount given PID from the directory /proc/\u003cPID\u003e into /usr/foo. This\r\nprocess is done stealthily without leaving traces in /etc/mtab.\r\nAnother file (/usr/bin/pu) is a Python script designed to conduct lateral movement in the network by\r\nexploiting the SSH port. \r\nLast, but not least, another file (/tmp/.logs.c) is used to clean all login and logout records on the system\r\n(WTMP, UTMP, and Lastlog for Linux). This exemplifies the level of effort that these adversaries are\r\ntaking to clean their records and maintain high standards of OPSEC.\r\nThis script also deactivates any programs competing for resources on the CPU, such as xmrigMiner and\r\nWatchdog. Once the script is done, it deletes itself and history.\r\nThis script downloaded and executed three other scripts (user.sh, sbs.sh, sxc.sh):\r\nThe script user.sh: Responsible for SSH communication with the infected host:\r\nVerifying that SSHD exists, and if not download, installs an Openssh-server.\r\nTrying to create three users (hilde, reboot, ubuntu).\r\nAttempting to grant the users root privileges.\r\nAppending the adversary’s RSA-keys for the above-mentioned users (hilde, reboot, ubuntu) into:\r\n/home/$usersname/.ssh/authorized_keys\r\n/home/$usersname/.ssh/authorized_keys2\r\nSetting root to be able to SSH login with no password in: /etc/ssh/sshd_config. and restart SSHD.\r\nUsing a web service (iplogger[.]org)  to transmit collected data to the attacker during the discovery process,\r\nfor instance, the number of cores in the CPU, its speed, system details (using uname −a), and targeted host\r\nIP address.\r\nLogging the activity and encoding it into files (using Base64).\r\nThe script sbs.sh: \r\nDownloading 00.jpg (as /usr/bin/dns_ipv4.tar.gz) which is the file /usr/bin/bioset.\r\nExecuting Bioset:\r\nRenaming the process to be systemd.\r\nListening to any connection on port 1982. Each new connection opens a new thread.\r\nCreating a child process that listens to the socket and communicates with the father using a method\r\ncalled ‘Named PIPE’ (also known as FIFO).\r\nThe father is responsible for deciphering messages and writing it back to the child on the PIPE.\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 4 of 8\n\nThe child receives commands which are being executed by /bin/sh.\r\nThis leads us to conclude that the Bioset is serving as a bind shell that probably allows the attacker\r\nto connect to the host after he deployed the container.\r\nDiscovery and Command and control:\r\nUsing a web service (iplogger[.]org) to transmit collected data to the attacker during the discovery\r\nprocess, for instance, the number of cores in the CPU, its speed, system details (using uname -a),\r\nand targeted host IP address.\r\nLogging the activity and encoding it into files (using Base64).\r\nDefense Evasion:\r\nDeleting command history.\r\nDeleting the shell file.\r\nThe script – ‘sxc.sh’: \r\nDownloading xmrig from a remote source.\r\nWriting the configuration file to disk (/usr/bin/ntpd.pid).\r\nVerifying that the Cryptominer (the file ntpd) is running.\r\nTerminating competition on resources:\r\nStopping all Moneroocean processes.\r\nOptimizing the miner’s operation:\r\nStopping monitoring services that limit the mining resources, such as system-getty.slices.service.\r\nStopping system health services, such as cp.syshealt.\r\nDiscovery and Command and control:\r\nUsing a web service (iplogger[.]org)   to transmit collected data to the attacker relevant to the\r\nmining processes, for instance, Monero hash rate, system details (using uname -a), and\r\ntargeted host IP address.\r\nLogging the activity and encoding it into files (using Base64).\r\nDefense Evasion Techniques:\r\nRemoving system logs (/var/log/syslog).\r\nDeleting command history.\r\nDeleting the shell file.\r\nDisabling network configuration, security, and monitoring tools, such as netfilter firewall,\r\niptables, kernel.nmi_watchdog (responsible to check if the kernel is hung).\r\nDisabling security scanners, such as Aliyun.\r\nThe malicious binaries:\r\nSystemHealt – cb782b40757d1aba7a3ab7db57b50847 (MD5)\r\nAVscan – b27eb2159c808f844d60900e2c81a4df (MD5)\r\nThe modus operandi\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 5 of 8\n\nThe more sophisticated attacks contained various changes in the code, implying that TeamTNT invested time and\r\neffort to improve their attacks. They added defense evasion techniques and attempted to conceal the\r\ncommunication with their C2 servers to try and ensure success while making the attacks last longer.\r\nExamples of evasion techniques:\r\nUsing dynamic code. The communication channels (IPs/domains) are defined as variables and use external\r\nconfiguration files to hide their C2 and mining infrastructure.\r\nLeveraging web services and TOR servers to increase the persistence of their C2 infrastructure.\r\nPutting more emphasis on OPSEC. Many stages, in recent attacks, revealed adversaries have been trying to\r\ncover their tracks by deleting their malicious tools, logs, erasing user activity on the host, etc.\r\nUsing a private domain teamtnt[.]red with subdomains vps and pool.\r\nDisabling security tools and network security tools.\r\nEncoding many snippets with base64 (the same snippet may be encoded multiple times).\r\nTo sum it up\r\nOver four months, TeamTNT uploaded various images, with some being used to perform attacks in the wild. This\r\nis still an active campaign targeting cloud native environments in general and misconfigured Docker API ports in\r\nparticular. The newer images in these accounts were designed to use advanced malicious methods, such as defense\r\nevasion, lateral movement, and discovery techniques.\r\nWe believe changes in these newer images somewhat reflect the learning curve (developing capabilities) of\r\nTeamTNT. The simpler and more straightforward images could be detected by static malware analysis, but the\r\nnewer ones are too smart for that. In fact, the image xmrigminer can only be identified as malicious using\r\nbehavioral profiling and monitoring in runtime, or better yet, in the pipeline using Aqua’s Dynamic Threat\r\nAnalysis.\r\nApplying MITRE ATT\u0026CK Framework to the TeamTNT attacks\r\nSummary that maps each component of the attack to the corresponding MITRE ATT\u0026CK framework and\r\ntechniques category:\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 6 of 8\n\nIndications of Compromise (IOCs):\r\nMining pools:\r\nvps[.]teamtnt[.]red[:]33331\r\n45[.]9[.]148[.]123[:]33331\r\nxmr[.]f2pool[.]com[:]13531\r\n47[.]101[.]30[.]124[:]13531\r\nxmr[.]bohemianpool[.]com[:]9000\r\n80[.]211[.]206[.]105[:]9000\r\nMalicious Binaries\r\nxmrigDeamon – d6e169d47a4bed78dffc184409994fbf (MD5)\r\nBioset – 4206dbcf1c2bc80ea95ad64043aa024a (MD5)\r\ndns3 – b348abf1d17f7ba0001905e295b1f670 (MD5)\r\nxmrigMiner – 7c7b77bfb9b2e05a7a472e6e48745aeb (MD5)\r\ndocker-update – ecf5c4e29490e33225182ef45e255d51 (MD5)\r\ndns (Tsunami malware) – b7ad755d71718f2adf3a6358eacd32a3 (MD5)\r\n64[watchdogd] – 8ffdba0c9708f153237aabb7d386d083 (MD5)\r\n64bioset – b8568c474fc342621f748a5e03f71667 (MD5)\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 7 of 8\n\n64tshd – 5f5599171bfb778a7c7483ffdec18408 (MD5)\r\narmbioset – 23812035114dbd56599694ed9b1712d2 (MD5)\r\narmdns – cfa007dc2d02da9a8873c761aa5a5c8c (MD5)\r\narmtshd – d46b96e9374ea6988836ddd1b7f964ee (MD5)\r\ntntscan – 4882879ffdac39219bef1146433ec54f (MD5)\r\nSystemHealt – cb782b40757d1aba7a3ab7db57b50847 (MD5)\r\nAVscan – b27eb2159c808f844d60900e2c81a4df (MD5)\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\nSource: https://blog.aquasec.com/container-security-tnt-container-attack\r\nhttps://blog.aquasec.com/container-security-tnt-container-attack\r\nPage 8 of 8\n\ndocker-update dns (Tsunami – ecf5c4e29490e33225182ef45e255d51 malware) – b7ad755d71718f2adf3a6358eacd32a3 (MD5) (MD5)\n64[watchdogd] -8ffdba0c9708f153237aabb7d386d083 (MD5)\n64bioset -b8568c474fc342621f748a5e03f71667 (MD5)\n  Page 7 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://blog.aquasec.com/container-security-tnt-container-attack"
	],
	"report_names": [
		"container-security-tnt-container-attack"
	],
	"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
		}
	],
	"ts_created_at": 1775441487,
	"ts_updated_at": 1775791857,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8332803119bcc8679f311360bca98d6572b5b4af.pdf",
		"text": "https://archive.orkl.eu/8332803119bcc8679f311360bca98d6572b5b4af.txt",
		"img": "https://archive.orkl.eu/8332803119bcc8679f311360bca98d6572b5b4af.jpg"
	}
}