The Scarleteel threat targets AWS Fargate environments for data theft and more malicious types of attacks such as cryptojacking and DDoS. Learn how to mitigate this threat.
Sysdig, a cloud and container security company, has released a new report on the Scarleteel threat that targets specific AWS environments for data theft and additional malicious activities. Learn how the Scarleteel threat operates and how to secure your business from this threat.
Jump to:
What is the Scarleteel threat?
Scarleteel is a sophisticated attack on AWS cloud environments that was discovered in February 2023 by Sysdig. That operation started by compromising Kubernetes containers to spread to the victim’s AWS account with one goal in mind: stealing proprietary software. The attack also dropped a cryptominer on the compromised environment, yet Sysdig’s Threat Research Team estimated the cryptojacking operation was probably used as a decoy to evade the detection of the data theft operation.
The attack showed that the threat actor had solid knowledge of AWS cloud mechanics including Elastic Compute Cloud roles, lambda serverless functions and Terraform, an open-source infrastructure as code tool that is able to automate operations on infrastructures on any kind of cloud solution.
Scarleteel’s new operation
Scarleteel’s Tactics, Techniques and Procedures has improved, according to the Sysdig Threat Research Team. As in the previous operation, the final goal of the threat actor here seems to be data theft, although the actor still plants cryptominers during its attack (Figure A).
Figure A
How Scarleteel targets AWS Fargate credentials
This time, the attack starts with the threat actor exploiting JupyterLab notebook containers deployed in a Kubernetes cluster. Then, the attacker focuses on credential stealing, using several scripts to try to get AWS Fargate credentials in the instance metadata service (IMDSv1 and IMDSv2) in the filesystem and in the Docker containers created in the targeted machine. The stolen credentials are sent to an IP address that was previously used by Scarleteel.
The attacker managed to steal AWS credentials in containers that were using IMDSv1. IMDSv2 password theft highly depends on the specific environment. Depending on the configuration, it might not be possible for an attacker to steal credentials on IMDSv2.
To evade detections based on the use of the curl and wget command-line tools, which are often monitored by security solutions, the threat actor decided to use a custom script to exfiltrate the obtained credentials (Figure B). The data is base64-encoded, so it wouldn’t be sent as clear text.
Figure B
Once the attacker is in possession of the credentials, they install the AWS Command-Line Interface with Pacu, an open-source AWS exploitation framework designed for offensive security testing.
The attacker then used the AWS CLI to connect to Amazon S3-compatible Russian systems using the –endpoint-url option, which allows the attackers to download their tools and exfiltrate data without being logged by the victim’s CloudTrail.
After the threat actor conducted automated reconnaissance in the target’s AWS environment, they obtained admin access and created a user named “aws_support,” switching to it to continue the operation.
How Scarleteel targets Kubernetes
The threat actor actively targets Kubernetes in the victim’s environment. The attacker has used Peirates, a Kubernetes penetration tool that enables an attacker to escalate privileges and pivot through a Kubernetes cluster. It also automates known techniques to steal and collect tokens and secrets.
The threat actor also executed Pandora, a Mirai-like malware that runs DDoS attacks using Linux systems and IoT systems to specific targets. As stated by the researchers, “This attack is likely part of a DDoS-as-a-Service campaign, where the attacker provides DDoS capabilities for money.”
Cryptojacking possibly used as a decoy
During the attack, the threat actor created 42 instances of the XMRig cryptominer, which is a legitimate tool often used by attackers in cryptojacking operations. This huge number of instances all running the miner was caught quickly, but the threat actor then created other accounts to achieve the same purpose by stealing secrets from the Secret Manager or updating SSH keys to run new instances. It failed due to insufficient privileges.
It’s intriguing to see a threat actor running a stealth operation suddenly start such a noisy activity. This once again leads us to believe that the cryptomining part of the operation might just be a decoy to hide all the data theft activity.
How to protect from this cybersecurity threat
- Container images should always come from trusted sources and constantly updated with the latest security patches.
- Unnecessary services should always be disabled so the attack surface isn’t increased. Privileges should also be minimized, and resource limitations should be enforced.
- Using AWS IMDSv2 instead of IMDSv1 is a recommended security best practice for containers because it makes credential stealing harder for attackers, depending on the configuration.
- AWS Identity and Access Management role permissions should be carefully checked.
- Security scanning tools should be used to identify vulnerabilities and malware in container images.
- Precise inbound and outbound policies should be deployed to limit access to only necessary tasks. AWS CloudTrail logs should be analyzed for any suspicious activity.
- Multifactor authentication should be deployed for connecting to AWS accounts.
Disclosure: I work for Trend Micro, but the views expressed in this article are mine.
