{
	"id": "ab5b70bf-d572-4039-b815-8d6d9c21b6e5",
	"created_at": "2026-04-06T00:14:50.446673Z",
	"updated_at": "2026-04-10T03:27:04.762827Z",
	"deleted_at": null,
	"sha1_hash": "dd27b22428de7c983474b2d1b1388ad9e5bcdaaa",
	"title": "Analyzing How TeamTNT Used Compromised Docker Hub Accounts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1390994,
	"plain_text": "Analyzing How TeamTNT Used Compromised Docker Hub\r\nAccounts\r\nBy By: Trend Micro Research Dec 01, 2021 Read time: 9 min (2417 words)\r\nPublished: 2021-12-01 · Archived: 2026-04-05 15:27:41 UTC\r\nCloud\r\nFollowing our previous disclosure of compromised Docker hub accounts delivering cryptocurrency miners, we\r\nanalyze these accounts and discover more malicious actions that you need to be aware of.\r\nIn early November, we disclosed that compromised Docker Hub accounts were being used for cryptocurrency\r\nmining and that these activities were tied to the TeamTNT threat actor. While those accounts have now been\r\nremoved, we were still able to investigate TeamTNT’s activities in connection with these compromised accounts.\r\nIn addition to the behavior we noted earlier, we identified several other actions that the same threat actor carried\r\nout in different venues. One was the use of Weave Scope, a legitimate tool by Weaveworks used to\r\nmonitor/control deployed containers.\r\nWeave ScopeWeave Scope is a visualization and monitoring tool for Docker and Kubernetes. System\r\nadministrators can use this to monitor and control their deployed containers/pods/workloads. \r\nFigure 1. Weave Scope window\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 1 of 14\n\nOne can manage running containers by executing, rebooting, pausing, stopping or even deleting containers, all of\r\nwhich can be controlled from a web console (either local or in the cloud).\r\nIn this attack scenario, the compromised underlying host was made a node of the threat actor-controlled Weave\r\nScope Cloud instance, from where they could execute various commands.\r\nFigure 2. Terminal command executed via Weave Scope\r\nThe administration features make Weave Scope an interesting target. This is how attackers targeted this recently:\r\n1. The attacker spins up a new privileged container based on an image from a compromised account. In the\r\narguments, the attacker attempts to mount the root file system of the underlying host to the ‘/host’ mount point and\r\nexecutes a bash script fetched from the attacker’s infrastructure.\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 2 of 14\n\nFigures 3-5. Code to spin up new container\r\n2. The script ‘scope2.sh’ is downloaded and piped to ‘bash’ to be executed. The script initially checks if the\r\nhostname’s value is ‘HaXXoRsMoPPeD’ halting the execution if true. This looks like a flag to prevent self\r\ninfection.\r\nFigure 6. Script checking for hostname\r\n3. Environment variables are set, which overrides localization settings, prevents command history logging, and\r\nexports a new path.\r\n4. A variable ‘SCOPE_TOKEN’ is populated from a controlled endpoint, which contains the Weave Scope service\r\ntoken. ‘SCOPESHFILE’ contains the Weave Scope script, which is encoded in base64.\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 3 of 14\n\nFigure 7. Encoded script\r\n5. The path to ‘docker’ binary is fetched using ‘type docker’. To evade any TTY events, they’re redirected to\r\n‘/dev/null’. Based on this, the execution proceeds.\r\n6. The file ‘/tmp/.ws’ is checked:\r\na. If the file doesn’t exist, the following commands are executed:\r\ni. The ‘/tmp/’ path is remounted with read-write permissions using the ‘mount’ utility.\r\nii. The base64 encoded string of the ‘SCOPESHFILE’ variable is decoded and the output is redirected to\r\n‘/tmp/.ws’. This is the Weaveworks’ script and is hidden by default since the file name begins with a ‘.\r\niii. The permissions of the newly created script are changed to executable using ‘chmod’\r\nb. If the file ‘/tmp/.ws’ exists, then execution proceeds as follows:\r\ni. The ‘/tmp/’ path is remounted as read-write using ‘mount’ utility.\r\nii. The Weaveworks utility Weave Scope at /tmp/.ws is stopped and launched with the service token fetched on\r\nstep 4.\r\nFigure 8. Stop and relaunch of Weave Scope utility\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 4 of 14\n\nWeaveworks published a blog postopen on a new tab in September 2020 that shared best practices for securing\r\nWeave Scope. Unfortunately, the abuse of this legitimate tool is still quite prevalent.\r\nTrend Micro Solutions\r\nCloud One Workload Security™\r\nWhen a new container is created over Docker daemon’s REST API, the rule ‘1010326 – Identified Docker\r\nDaemon Remote API Call’ triggers with different notes for different steps of the container creation from image.\r\nEvents are generated when the 'containerd’ process is created and are logged using the Integrity Monitoring\r\nmodule:\r\nFigure 9: Alert for containerd process\r\nWhen the Docker Daemon is observed listening on TCP port, the Log Inspection module detects this as seen\r\nbelow:\r\nFigure 10. Results of Log Inspection module\r\nThe AntiMalware Module detects the malicious script ‘scope2.sh’ as a Trojan:\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 5 of 14\n\nFigure 11. Detection of malicious script\r\nIntrusion Prevention\r\n1. 1010326 - Identified Docker Daemon Remote API Call\r\n2. 1010561 - Identified Kubernetes Unprotected Primary Channel Information Disclosure\r\n3. 1010762 - Identified Kubernetes API Server LoadBalancer Status Patch Request\r\n4. 1010769 - Identified Kubernetes Namespace API Requests\r\n5. 1009493 - Kubernetes Dashboard Authentication Bypass Information Disclosure Vulnerability (CVE-2018-\r\n18264)\r\n6. 1009450 - Kubernetes API Proxy Request Handling Privilege Escalation Vulnerability (CVE-2018-\r\n1002105)\r\n7. 1009561 - Kubernetes API Server Denial of Service Vulnerability (CVE-2019-1002100)\r\nLog Inspection\r\n1. 1009105 – Kubernetes\r\n2. 1008619 - Application – Docker\r\n3. 1010349 - Docker Daemon Remote API Calls\r\nIntegrity Monitoring \r\n1. 1008271 – Application - Docker\r\n2. 1009060 - Application - Kubernetes Cluster master\r\n3. 1009434 - Application - Kubernetes Cluster node\r\nCloud One Network Security™\r\nThe following rules are triggered by this attack in Network Security:\r\n29993: HTTP: Docker Container With Root Directory Mounted with Write Permission Creation Attempt\r\n33719: HTTP: Docker Daemon \"create/exec\" API with \"Cmd\" Key Set to Execute Shell Commands\r\n33905: HTTP: Kubernetes API Proxy Request Handling Privilege Escalation Vulnerability\r\n34487: HTTP: Kubernetes Dashboard Authentication Bypass Vulnerability\r\n34488: HTTPS: Kubernetes Dashboard Authentication Bypass Vulnerability\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 6 of 14\n\n34668: HTTP: Docker Build Image API Request with remote and networkmode Parameters Set\r\n34796: HTTP: Docker Version API Check Request\r\n35799: HTTP: Kubernetes Overlength json-patch Request\r\n38836: HTTP: Kubernetes API Namespaces Request\r\n38837: HTTP: Kubernetes API Namespaces Status Request\r\n38838: HTTP: Kubernetes API Create Namespace Request\r\n38839: HTTP: Kubernetes API Delete Namespace Request\r\n38840: HTTP: Kubernetes API Update Namespace Request\r\n38847: HTTP: Kubernetes API Server loadBalancer Status Patch Request\r\n38892: HTTP: Kubernetes API Admission Control Create Mutating Webhook Request\r\n38893: HTTP: Kubernetes API Admission Control Create Validating Webhook Request\r\n38896: HTTP: Kubernetes API Admission Control Resources Request\r\n38898: HTTP: Kubernetes API Admission Control List Mutating Webhook Configurations Request\r\n38899: HTTP: Kubernetes API Admission Control List Validating Webhook Configurations Request\r\n38901: HTTP: Kubernetes API Admission Control Delete Validating Webhook Request\r\n38902: HTTP: Kubernetes API Admission Control Delete Mutating Webhook Request\r\n38903: HTTP: Kubernetes API Admission Control Update Validating Webhook Request\r\n38904: HTTP: Kubernetes API Admission Control Update Mutating Webhook Request\r\n38905: HTTP: Kubernetes API Admission Control Read Mutating Webhook Request\r\n38906: HTTP: Kubernetes API Admission Control Read Validating Webhook Request\r\n38907: HTTP: Kubernetes API Admission Control Replace Mutating Webhook Request\r\n38908: HTTP: Kubernetes API Admission Control Replace Validating Webhook Request\r\n38909: HTTP: Kubernetes API CustomResourceDefinition Resources Request\r\n38910: HTTP: Kubernetes API Create CustomResourceDefinition Request\r\n38916: HTTP: Kubernetes API List CustomResourceDefinition Resources Request\r\n38917: HTTP: Kubernetes API Update CustomResourceDefinition Resources Request\r\n38918: HTTP: Kubernetes API Update Status CustomResourceDefinition Resources Request\r\n38919: HTTP: Kubernetes API Read CustomResourceDefinition Resources Request\r\nTrend Micro Vision One™\r\nFigure 12. Detection Model for Weave Scope abuse\r\nSince Weave Scope is a legitimate tool used in workloads, one can enable or disable the XDR Model from\r\nDetection Model Management by toggling the ‘Status’. If the tool is not supposed to be used in the environment\r\nand there are alerts as XDR Model triggers or Observed Attack Techniques, it must be checked.\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 7 of 14\n\nWorkbench\r\nFigure 13. Workbench diagram\r\nThe diagram in Figure 13 demonstrates the power of correlation amongst different Cloud One™ modules,\r\ncomposed into a single screen. The left panel shows the sequence of observed attack techniques with the events\r\ngenerated from Cloud One™ modules, while the right panel details the various objects involved in this attempt.\r\nThe corresponding MITRE ATT\u0026CK tags help identify the parts of the framework being abused.\r\nFigure 14. Workbench diagram\r\nThis Workbench shows all the workloads using the Impact Scope in the organization where the unencrypted\r\nDocker REST API is exposed and on which it’s listening.\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 8 of 14\n\nRoot Cause Analysis\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 9 of 14\n\nFigure 15 and 16. Root cause analysis diagrams\r\nIn the RCAs generated from the Observed Attack Techniques, we can deep dive into the various fields of\r\nimportance, such as the exact time at which the outbound connection was observed and the process lineage with\r\nthe process command line. This shows that ‘nsenter’ is being executed from ‘scope’, it’s being used to create a\r\n‘bash’ shell, and the context is fetched from the PID 1 or ‘init’ process responsible for starting and shutting down\r\nthe system.\r\nEscaping from a compromised container\r\nBased on our research, the attackers also used a well-known technique to escape from a compromised container to\r\nthe host. They did this by using bind mounts and fetching the Docker Hub credentials from the following paths:\r\n1. /root/.docker/config.json\r\n2. /home/*/.docker/config.json\r\nAs per Docker’s official documentationopen on a new tab:\r\n“You can log into any public or private repository for which you have credentials. When you log in, the command\r\nstores credentials in $HOME/.docker/config.json on Linux or %USERPROFILE%/.docker/config.json”.\r\nWhen someone logs into their Docker Hub account using the Docker command line and there are no credential\r\nstores specified, the username, password and registry server link are populated as a JSON that looks like this:\r\nFigure 17. Code with Docker login\r\nBy default, the registry used is of Docker Inc. The value of ‘auths.auth’ field is the base64-encoded string that\r\ncontains the credentials in the format ‘username:password’. If these credentials are compromised, one can gain\r\naccess to the victims’ information:\r\n1. Email ID used to create the account\r\n2. Private Images\r\n3. Access tokens\r\n4. Slack Webhooks\r\n5. Content Subscriptions\r\n6. Upgraded features\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 10 of 14\n\nNow we take a look into how the enumeration of exposed kubelets was performed.\r\nEnumeration Of Exposed Kubelets\r\nThis attack abused the Docker REST API to create a container from an image that had a script at the filesystem\r\npath ‘/root/init.sh’, which contains the following:\r\n1. They initially update the alpine-based container and add the packages they need in later operations, like\r\ncompiling zgrab from source, using masscan, etc. \r\nFigure 18. Building zgrab\r\n2. Once the above steps are executed, they begin the execution of their malicious function using a kill switch,\r\nwhich is based on the contents of a certain endpoint on the attacker’s infrastructure to be equal to ‘RUN’.\r\nFigure 19. Executing malicious functions\r\n3. Once the kill switch is confirmed to be equal to ‘RUN’, the malicious PWN function is executed.\r\nFigure 20: Checking for the kill switch\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 11 of 14\n\nThis script fetches a scan range from a malicious server endpoint. If the results fetched contain ‘ENDE’, that\r\nsignals the exit of the malicious script.\r\nThe results returned by the endpoint is stored in the variable ‘SCAN_RANGE’, which is later appended to\r\n‘.0.0.0/8’. For example, if the value returned from the endpoint is 10, then the value of ‘SCAN_RANGE’ will be\r\n‘10.0.0.0/8’\r\nThe variable ‘rndstr’ is a six-letter random alphabetical string that accumulates a list of IP addresses of running\r\npods with the kubelet API TCP port 10250 exposed that have been found using masscan and zgrab. Once this\r\nsubnet is completed, the results are sent back to the threat actor using a for loop, which iterates over the results\r\nacquired via a website.\r\nOnce the results are sent, the kill switch loop loops back for a new subnet from the infrastructure unless all the\r\nsubnets are enumerated.\r\nThe threat actor seems to do this as preparation to later target exposed kubelets. Earlier, we detailed about the shift\r\nin focus from Docker REST API to Kubernetes API. Here’s a trend of exposed Kubernetes API port 10250\r\nindexed by Shodan from approximately 1,200 exposed workloads, months ago: \r\nFigure 21. Growth in exposed port 10250\r\nTrend Micro Solutions\r\nCloud One Workload Security™\r\nIntrusion Prevention\r\n1. 1010326 - Identified Docker Daemon Remote API Call\r\n2. 1010561 - Identified Kubernetes Unprotected Primary Channel Information Disclosure\r\n3. 1010762 - Identified Kubernetes API Server LoadBalancer Status Patch Request\r\n4. 1010769 - Identified Kubernetes Namespace API Requests\r\n5. 1009493 - Kubernetes Dashboard Authentication Bypass Information Disclosure Vulnerability (CVE-2018-\r\n18264)\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 12 of 14\n\n6. 1009450 - Kubernetes API Proxy Request Handling Privilege Escalation Vulnerability (CVE-2018-\r\n1002105)\r\n7. 1009561 - Kubernetes API Server Denial of Service Vulnerability (CVE-2019-1002100)\r\nLog Inspection\r\n1. 1009105 – Kubernetes\r\n2. 1008619 - Application – Docker\r\n3. 1010349 - Docker Daemon Remote API Calls\r\nIntegrity Monitoring\r\n1. 1008271 – Application - Docker\r\n2. 1009060 - Application - Kubernetes Cluster master\r\n3. 1009434 - Application - Kubernetes Cluster node\r\nCloud One Network Security™C\r\n29993: HTTP: Docker Container With Root Directory Mounted with Write Permission Creation Attempt\r\n33719: HTTP: Docker Daemon \"create/exec\" API with \"Cmd\" Key Set to Execute Shell Commands\r\n33905: HTTP: Kubernetes API Proxy Request Handling Privilege Escalation Vulnerability\r\n34487: HTTP: Kubernetes Dashboard Authentication Bypass Vulnerability\r\n34488: HTTPS: Kubernetes Dashboard Authentication Bypass Vulnerability\r\n34668: HTTP: Docker Build Image API Request with remote and networkmode Parameters Set\r\n34796: HTTP: Docker Version API Check Request\r\n35799: HTTP: Kubernetes Overlength json-patch Request\r\n38836: HTTP: Kubernetes API Namespaces Request\r\n38837: HTTP: Kubernetes API Namespaces Status Request\r\n38838: HTTP: Kubernetes API Create Namespace Request\r\n38839: HTTP: Kubernetes API Delete Namespace Request\r\n38840: HTTP: Kubernetes API Update Namespace Request\r\n38847: HTTP: Kubernetes API Server loadBalancer Status Patch Request\r\n38892: HTTP: Kubernetes API Admission Control Create Mutating Webhook Request\r\n38893: HTTP: Kubernetes API Admission Control Create Validating Webhook Request\r\n38896: HTTP: Kubernetes API Admission Control Resources Request\r\n38898: HTTP: Kubernetes API Admission Control List Mutating Webhook Configurations Request\r\n38899: HTTP: Kubernetes API Admission Control List Validating Webhook Configurations Request\r\n38901: HTTP: Kubernetes API Admission Control Delete Validating Webhook Request\r\n38902: HTTP: Kubernetes API Admission Control Delete Mutating Webhook Request\r\n38903: HTTP: Kubernetes API Admission Control Update Validating Webhook Request\r\n38904: HTTP: Kubernetes API Admission Control Update Mutating Webhook Request\r\n38905: HTTP: Kubernetes API Admission Control Read Mutating Webhook Request\r\n38906: HTTP: Kubernetes API Admission Control Read Validating Webhook Request\r\n38907: HTTP: Kubernetes API Admission Control Replace Mutating Webhook Request\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 13 of 14\n\n38908: HTTP: Kubernetes API Admission Control Replace Validating Webhook Request\r\n38909: HTTP: Kubernetes API CustomResourceDefinition Resources Request\r\n38910: HTTP: Kubernetes API Create CustomResourceDefinition Request\r\n38916: HTTP: Kubernetes API List CustomResourceDefinition Resources Request\r\n38917: HTTP: Kubernetes API Update CustomResourceDefinition Resources Request\r\n38918: HTTP: Kubernetes API Update Status CustomResourceDefinition Resources Request\r\n38919: HTTP: Kubernetes API Read CustomResourceDefinition Resources Request\r\nConclusion\r\nVulnerabilities posed by poor security misconfigurations or inherent software bugs are difficult to protect. In the\r\nabove case, we observed the use of legitimate platforms like Weaveworks. To stay protected, we need to rethink\r\nabout inculcating security in our daily work by regular patching, staying updated and alerted with the latest\r\nhappenings in cyberspace.\r\nTrend Micro™ Cloud One™ – Workload Securityproducts equips defenders and analysts with the ability to\r\nprotect systems against vulnerabilities, exploits, and malware, offering protection from on-premise to cloud\r\nworkloads. Virtual patching can protect critical systems even before the official patches are made available.\r\nTrend Micro™ Vision One™products provides a clear view of the most important events as alerts in a concise\r\nmanner, because the race is about quick response. With XDR capabilities with telemetries from your multi-cloud\r\nenvironments or on-premise workloads, security teams get a clear and vivid understanding of what to prioritize.\r\nIndicators Of Compromise\r\nIP address\r\n45.9.148[.]182\r\nDomain\r\ndl[.]chimaera.cc\r\nShell scripts\r\nHash Detection Name\r\n7c110dc507ed4e2694500c7c37fe9176e9f4db23bc4753c0bfc9f3479eb6385a Trojan.SH.MALXMR.UWELG\r\nb7cef848b61cfb7d667e60ade3a1781def69f5395b5ad6a2a16f7b7fa11ef1db Trojan.Win32.FRS.VSNW0CK21\r\nTags\r\nSource: https://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nhttps://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/21/l/more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html"
	],
	"report_names": [
		"more-tools-in-the-arsenal-how-teamtnt-used-compromised-docker-hu.html"
	],
	"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": 1775434490,
	"ts_updated_at": 1775791624,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dd27b22428de7c983474b2d1b1388ad9e5bcdaaa.pdf",
		"text": "https://archive.orkl.eu/dd27b22428de7c983474b2d1b1388ad9e5bcdaaa.txt",
		"img": "https://archive.orkl.eu/dd27b22428de7c983474b2d1b1388ad9e5bcdaaa.jpg"
	}
}