Mastodawn

Analysis of a real-world attack chain in AWS

Compromise container running on EKS

IAM user credentials in Lambda environment variables and in plaintext in an S3 bucket

Disable CloudTrail logs

Steal "proprietary software"

Find credentials of an IAM user in a Terraform state file in an S3 bucket

Pivot to another AWS account

On the attack chain:

IAM users strike again. Your first step in securing an AWS environment should be nuking anything that has static, long-term credentials. See A retrospective of 2022 cloud data breaches
IMDSv2 only protects your application against SSRFs. If it gets compromised, it doesn't make any difference. The phrasing from Sysdig is misleading here, what should be done is to block access to IMDS from the pod.
If your pod needs to access AWS APIs, use IAM roles for service accounts, see https://infosec.exchange/@christophetd/109491506163807997
If your Lambda function needs to access AWS APIs, use a Lambda execution role, it's much easier and more secure!

The Sysdig Threat Research Team recently discovered a sophisticated cloud operation in a customer environment, dubbed SCARLETEEL.

Sysdig