ECS and Fargate Attack Surface Worth Testing

Cloud Security

Fargate looks tidier than EC2 because there is no host to manage. The IAM, secrets, and image pipeline still leak in familiar ways. Here is what a pentester targets and what to fix.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 7, 2025 · 7 min read

ECS on Fargate removes the host as an attack surface but does not remove the task. The task IAM role, the credential endpoint at 169.254.170.2, the ECR images you pull, and the secrets you wire in are all still attackable. The escapes change shape but they do not disappear.

How attackers find this

From a compromised container in a Fargate task we read the task metadata endpoint and the credentials endpoint. The credentials endpoint returns short-lived credentials for the task IAM role. We then enumerate that role with aws sts get-caller-identity and aws iam list-attached-role-policies (if the role can read its own policies; many can).

• Task IAM role with secretsmanager:GetSecretValue across the account: pull every secret.
• Task IAM role with ecr:BatchGetImage and ecr:PutImage: poison the next image pull.
• Task definition that injects secrets through environment variables instead of secrets references: env is dumpable.
• Task running with executeCommand enabled and IAM allowing ecs:ExecuteCommand from outside: shell into running tasks.
• Cluster running with IMDSv1 reachable from tasks (rare on Fargate, common on EC2-launch-type ECS).

Methodology in practice

Once we have RCE in a Fargate task, the task IAM role is the prize. We try the role's permissions against expected services first (S3 buckets in the same account, secrets with names that match the app's domain) because broad enumeration is noisy. Then we look for the path to other tasks, often through ecs:ExecuteCommand or through service-discovery endpoints inside the cluster's VPC.

Detection

CloudTrail captures every API call the task role makes. The detections we recommend look at the role identity (arn:aws:sts::ACCOUNT:assumed-role/TaskRole/TaskID) and the cross product of that role with API calls outside its normal pattern. GuardDuty has runtime monitoring for ECS that catches in-container suspicious commands. ECS itself emits events for ExecuteCommand sessions; alert on those when they happen outside maintenance windows.

Remediation

1. Scope task IAM roles to specific resources, not wildcards; use aws:ResourceTag conditions where possible.
2. Reference secrets through the task definition's secrets block (which calls SecretsManager at runtime) rather than baking them into environment variables.
3. Sign images with AWS Signer Notation and enforce signature verification at pull time so a poisoned ECR push fails.
4. Disable ecs:ExecuteCommand at the cluster level unless explicitly needed; if needed, restrict it to incident-response IAM principals only.
5. Rotate any secrets a task touches on a defined schedule; use SecretsManager rotation for database creds.
6. Run the task in a VPC subnet with a tight security group; do not give tasks access to the metadata IP or to other tenants' tasks they should not reach.

Fargate is friendly because it removes the host, but the task identity is still an identity, and identities still need least privilege, monitoring, and rotation. The pentest finding is almost always one of those three slipping.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.