{
	"id": "573402fc-f31c-4032-98a8-150254f73b99",
	"created_at": "2026-04-06T00:13:04.466894Z",
	"updated_at": "2026-04-10T13:11:30.995417Z",
	"deleted_at": null,
	"sha1_hash": "b96739bb65493576a74dd36776a6e9cae9b1a6bb",
	"title": "SCARLETEEL: Operation leveraging Terraform, Kubernetes, and AWS for data theft",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1440148,
	"plain_text": "SCARLETEEL: Operation leveraging Terraform, Kubernetes, and\r\nAWS for data theft\r\nBy Alberto Pellitteri\r\nPublished: 2023-02-28 · Archived: 2026-04-05 12:39:11 UTC\r\nThe Sysdig Threat Research Team recently discovered a sophisticated cloud operation in a customer environment,\r\ndubbed SCARLETEEL, that resulted in stolen proprietary data. The attacker exploited a containerized workload\r\nand then leveraged it to perform privilege escalation into an AWS account in order to steal proprietary software\r\nand credentials. They also attempted to pivot using a Terraform state file to other connected AWS accounts to\r\nspread their reach throughout the organization.\r\nThis attack was more sophisticated than most, as it started from a compromised Kubernetes container and spread\r\nto the victim's AWS account. The attackers also had knowledge of AWS cloud mechanics, such as Elastic\r\nCompute Cloud (EC2) roles, Lambda serverless functions, and Terraform. The end result wasn't just a typical\r\ncryptojacking attack. The attacker had other, more malicious motives: the theft of proprietary software.\r\nCyberattacks in the cloud have increased by 56% over the past year. Obtaining persistence in the cloud,\r\nexfiltrating sensitive data, and creating new resources such as EC2 instances for use in cryptomining are the most\r\ncommon motives. Such resources can have a serious impact on an organization's cloud bills. But more espionage-focused motives are also alive and well.The reality is that attackers can use your cloud resources for more than\r\njust cryptomining.\r\nThe sophisticated attack we witnessed has many facets that underlie the complexity of securing a cloud-based\r\ninfrastructure. Vulnerability management alone won't address everything. Instead, there are a number of tools that\r\ncan reduce your risk from advanced threats, including virtual machine, cloud security posture management\r\n(CSPM), cloud infrastructure entitlement management (CIEM), runtime threat detection, and secrets management.\r\nOverview\r\nThis infographic shows the main steps in the kill chain. Let's first show the attack at a high level, then provide\r\ngreater detail of each step.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 1 of 10\n\nStep 1: The attacker gained initial access by exploiting a public-facing service in a self-managed\r\nKubernetes cluster hosted inside an AWS cloud account.\r\nStep 2: Once the attacker gained access to the pod, the malware was able to perform two initial actions\r\nduring execution:\r\nLaunch a cryptominer in order to make money or provide a distraction.\r\nObtain credential access through a worker's temporary credentials in Instance Metadata Service\r\n(IMDS) v1 to enumerate and collect information on its behalf using the cluster role permissions.\r\nDue to excessive granted permissions, the attacker was able to:\r\nEnumerate AWS resources.\r\nFind credentials of other identity and access management (IAM) users both set as Lambda\r\nenvironment variables and pushed in plain text to Amazon Simple Storage Service (S3)\r\nbuckets.\r\nStep 3: The attacker used the credentials found in the previous step to move laterally. They directly\r\ncontacted the AWS API, further enumerated the account, and proceeded with information gathering and\r\ndata exfiltration. During this step, they were able to:\r\nDisable CloudTrail logs to evade detection.\r\nSteal proprietary software.\r\nFind the credentials of an IAM user related to a different AWS account by discovering Terraform\r\nstate files in S3 buckets.\r\nStep 4: The attacker used the new credentials to move laterally again, repeating the attack and their kill\r\nchain from the other AWS account they found. Fortunately, in this case they were not able to enumerate\r\nresources, since all of the AWS API requests they attempted failed due to a lack of permissions.\r\nTechnical analysis\r\nInitial access – container compromise\r\nThe attacker found and exploited an internet-exposed service deployed in a Kubernetes cluster. Once they\r\naccessed the container, they started performing different actions to proceed with their attack.\r\nThe first action we recorded was the downloading and launching of a miner in order to steal some memory cycles.\r\nThis is a common practice in automated container threats, as reported in our \"2022 Cloud-Native Threat Report.\"\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 2 of 10\n\nAs you can see here, the attacker launched the script miner.sh in order to run an XMRig executable, along with the\r\nminer configuration file config_background.json.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 3 of 10\n\nThe purpose of the attack went far beyond cryptomining, however. Either cryptomining was the attacker's initial\r\ngoal and the goal changed once they accessed the victim's environment, or cryptomining was used as a decoy to\r\nevade the detection of data exfiltration. During the installation of the cryptominer, we observed a bash script\r\nrunning simultaneously on the container to enumerate and extract additional information in the environment, such\r\nas credentials.\r\nIn order to find credentials, the attacker directly accessed IMDS. IMDS v1 is the version used by default when\r\ncreating older versions of self-managed clusters or EC2 instances in AWS. It's used to configure and manage\r\nmachines.\r\nRetrieving AWS temporary security credentials bound to the EC2 instance role from IMDS v1 is a very well-known practice that we've covered in previous blog posts. The attacker may discover the IAM role bound to the\r\nworker instance running:\r\nand later obtain the AccessKeyId, SecretAccessKey, and temporary token:\r\nLooking at the malicious request to IMDS v1, we also found a request to a lesser-known internal endpoint\r\ndescribed as \"internal use only\" and explained in AWS documentation.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 4 of 10\n\nThe screenshot below shows how the attacker targeted both the instance metadata endpoints and what commands\r\nwere executed by the malicious script in order to grep and retrieve the IAM role keys.\r\nOnce collected, it is possible to use those credentials for a short period of time in order to run operations on behalf\r\nof the impersonated IAM role, calling the AWS API directly. Using CloudTrail logs, you can see the first API calls\r\nfrom the attacker using the cluster role:\r\nThe attacker ran some AWS actions to gain persistence on the AWS platform, trying to create new users, groups,\r\nand bind new access keys to existing IAM users. Fortunately, all of these executions were denied because of a lack\r\nof permissions on the account the attacker was using.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 5 of 10\n\nUnfortunately, the AWS cluster role was misconfigured with excessive read permissions. The original intent was\r\nto allow the reading of a specific S3 bucket, but the permissions allowed the role to read everything in the\r\naccount, which enabled the attacker to gain further knowledge of the AWS account, including Lambda.\r\nDiscovery – AWS cloud\r\nOnce the attacker obtained initial access into the cloud account, they started gathering information about the\r\nresources deployed in the AWS account. The activities reported in the table below are just some of the API\r\nrequests recorded in the AWS account.\r\nDuring these scraping operations, the attacker focused their efforts on the most used AWS services: Serverless\r\nLambda functions and S3 buckets.\r\nLambda function enumeration – stolen proprietary code and software\r\nAs we pointed out in this article, Lambda functions and other serverless functions are commonly used to execute\r\ncustom code without worrying about the infrastructure underneath, leaving a lot of flexibility for end users.\r\nThere were different Lambda functions in the affected AWS account, mainly related to account automation.\r\nThe attacker started to enumerate and retrieve all of the Lambda functions located in a specific region in the AWS\r\naccount using the proper API call. For example, you can use the AWS command below to list the functions.\r\nBehind the scenes, it is just REST API calls, so there are many ways to accomplish this task.\r\nAfter obtaining the list of functions, the attacker tried to dig deeper by downloading the Lambda code. Calling the\r\nfollowing AWS API, they were able to get the code location so that they could download the code that makes up\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 6 of 10\n\nthe Lambda. In this case, the Lambda function held proprietary software and the keys needed to execute it.\r\nUsing curl or wget commands, the attacker successfully exfiltrated the Lambda code and stole proprietary code\r\nand software from the Lambda functions. There was also evidence that the attacker executed the stolen software.\r\nThey took the time to look at the Lambda function's environment variables and find additional AWS credentials\r\nrelated to IAM users in the same account, using a command similar to:\r\nAs you will see in the next steps of the attack, adversaries used the credentials found here to retry enumeration\r\nwith the new user, hoping for new findings or to evaluate possible privilege escalation inside the account.\r\nS3 bucket enumeration\r\nAmazon S3 is a widely popular storage service that allows users to store and retrieve data.\r\nAttackers often target resources and files stored in S3 buckets to extract information and credentials. In the past,\r\nmany breaches have exploited misconfigured S3 buckets or S3 buckets left open to the public without passwords\r\nor security measures. During this particular attack, the attacker was able to retrieve and read more than 1 TB of\r\ninformation, including customer scripts, troubleshooting tools, and logging files.\r\nCloudTrail does not log data events for objects stored in S3 buckets unless such functionality is explicitly\r\nrequested. In this case, that functionality was not turned on, which makes it impossible to see information about\r\nthe access of specific objects. However, we are certain that the attacker went through the buckets looking for\r\nsensitive data. To speed up their pursuit without consuming their available storage, they may have used tools like\r\nTruffleHog to immediately obtain new AWS user credentials and continue lateral movement in the cluster.\r\nThe 1 TB of data also included logging files related to Terraform, which was used in the account to deploy part of\r\nthe infrastructure. These Terraform files will play an important part in the later step where the attacker tried to\r\npivot to another AWS account.\r\nDefense evasion – disable CloudTrail logging\r\nOnce the attacker accessed the cloud account, they attempted to disable CloudTrail logs inside the compromised\r\naccount. As you can see from the screenshot below, the attacker succeeded in disabling some of the logs\r\nconfigured in the account because of extra permissions assigned to one of the users compromised in the previous\r\nsteps.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 7 of 10\n\nAs a result of this action, we could not retrieve additional attack evidence. When reviewing account permissions,\r\nit is critical to keep the ability to disable or delete security logs to as few users as possible. Deletion shouldn't even\r\nbe possible in most situations without a solid backup solution.\r\nCredential access – Terraform state files\r\nTerraform is an open source infrastructure as code (IaC) tool used to deploy, change, or create infrastructures in\r\ncloud environments.\r\nIn order for Terraform to know which resources are under its control and when to update and destroy them, it uses\r\na state file named terraform.tfstate by default. When Terraform is integrated and automated in continuous\r\nintegration/continuous delivery (CI/CD) pipelines, the state file needs to be accessible with proper permissions. In\r\nparticular, the service principal running the pipeline needs to be able to access the storage account container that\r\nholds the state file. This makes shared storage like Amazon S3 buckets a perfect candidate to hold the state file.\r\nHowever, Terraform state files contain all data in plain text, which may contain secrets. Storing secrets anywhere\r\nother than a secure location is never a good idea, and definitely should not be put into source control!\r\nThe attacker was able to list the bucket available and retrieve all of the data. Examining the data with different\r\ntools such as Pacu and TruffleHog during the incident investigation, it was possible to find both a clear-text IAM\r\nuser access key and secret key in the terraform.tfstate file inside of an S3 bucket. Here is a screenshot from\r\nTruffleHog.\r\nThese IAM credentials are for a second connected AWS account, giving the attacker the opportunity to move\r\nlaterally to spread their attack throughout the organization.\r\nLateral movement – AWS account\r\nWith the new credentials acquired, the attacker restarted their enumeration and information-gathering process to\r\ndetermine whether they could gain additional resources from inside this additional compromised account. In\r\naddition, CloudTrail recorded suspicious activities in the connected AWS account mentioned above.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 8 of 10\n\nThe attacker tried to perform enumeration on different AWS resources in the connected cloud account.\r\nFortunately, the IAM user was very well scoped, so all of the requests failed due to a lack of permissions, leaving\r\njust the harmless GetCallerIdentity API, which is permitted by default.\r\nRecommendations\r\nThe attack reported here is a clear indication of how threat actors are trying to reach the cloud as a main goal. It all\r\nstarted with a compromised service, although the attacker tried to move laterally in the cloud as soon as they\r\nobtained valid credentials to find valuable information such as proprietary code. They also tried to pivot to other\r\ncloud accounts to get more and more.\r\nHere are some main takeaways that can help you be more careful:\r\nPatch and apply a vulnerability management cycle to your application and public-facing container.\r\nYou will be aware of what you have exposed and can prioritize patching activities.\r\nUse IMDS v2 instead of IMDS v1. The enhancement version requires session-oriented requests to add\r\ndefense in depth against unauthorized metadata access. Moreover, to ensure that only authorized pods can\r\nassume specific IAM roles in your clusters, adopt the principle of least privilege and use IAM roles for\r\nservice accounts (IRSA) whenever possible. IRSA limits access to resources and reduces the risk of\r\nunauthorized access. Pods that are not authorized will stick to the IMDS settings.\r\nDon't underestimate the power of read-only access. Even read-only in specific AWS resources like\r\nLambda functions means data exfiltration or credential harvesting. Scoping the read-only access on just the\r\nneeded resources is fundamental to keep your account safe.\r\nMonitor the stale objects in your cloud account. Unused permissions, even if old and never used, can be\r\ndangerous and cost you a lot in the event of a compromise. Being aware of stale objects and periodically\r\nassessing the cloud object should be mandatory.\r\nTerraform is a great tool, but it needs to be handled with care. Adopt the best practices and store the\r\nstate file in a secure location. Using key management services (KMSs) like AWS KMS, GCP KMS, or\r\nAzure Key Vault, it's possible to keep the secret safe and encrypt or decrypt the secrets once needed.\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 9 of 10\n\nAttack summary and conclusion\r\nTo recap, the SCARLETEEL attack started with the exploitation of a vulnerable pod. The attacker used the\r\nidentity related to the IAM role associated with the node where the pod was running. Then they exploited that role\r\nto do enumeration in the cloud, search for sensitive information, and steal proprietary software. Once they\r\ndiscovered new credentials, they leveraged those to gain persistence and try to obtain more privileges.\r\nThe measures taken in order to secure the environment following discovery of the attack included disabling and\r\nremoving users' access keys and secret access keys; securing vulnerable applications after conducting some audits\r\nand penetration tests; limiting access to sensitive S3 buckets through the use of restrictive policies; and adopting\r\nextra measures of least privilege to reduce the potential attack surface and prevent lateral movement activities in\r\nthe cloud.\r\nIn this sophisticated attack, we saw how far an attacker can go as the result of compromising a vulnerable\r\napplication with a lack of adequate security measures. This event reiterated what we all already knew. First, zero\r\ntrust and the principle of least privilege are important, and if you implement them, you will reduce the likelihood\r\nof compromise. Second, strong detections and alerts should help you catch these activities before an attacker gets\r\ntoo deep.\r\nIoCs\r\nIP Addresses:\r\n80[.]239[.]140[.]66\r\n45[.]9[.]148[.]221\r\n45[.]9[.]148[.]121\r\n45[.]9[.]249[.]58\r\nFor additional IoCs associated with this campaign, please visit our GitHub page.\r\nSource: https://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nhttps://sysdig.com/blog/cloud-breach-terraform-data-theft/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://sysdig.com/blog/cloud-breach-terraform-data-theft/"
	],
	"report_names": [
		"cloud-breach-terraform-data-theft"
	],
	"threat_actors": [
		{
			"id": "c220fe19-ef23-4166-ac54-7a32c3ea75d7",
			"created_at": "2023-11-10T02:00:07.503009Z",
			"updated_at": "2026-04-10T02:00:03.437555Z",
			"deleted_at": null,
			"main_name": "SCARLETEEL",
			"aliases": [],
			"source_name": "MISPGALAXY:SCARLETEEL",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434384,
	"ts_updated_at": 1775826690,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b96739bb65493576a74dd36776a6e9cae9b1a6bb.pdf",
		"text": "https://archive.orkl.eu/b96739bb65493576a74dd36776a6e9cae9b1a6bb.txt",
		"img": "https://archive.orkl.eu/b96739bb65493576a74dd36776a6e9cae9b1a6bb.jpg"
	}
}