Intelligence on ECS Attacks, Tactics, Techniques & Procedures

Tales from the cloud trenches: Amazon ECS is the new EC2 for crypto mining

Where intelligence lacks, you can infer the types of attacks and behaviour you’ll observe in this service based on the nature of the GuardDuty findings for ECS:

GuardDuty Runtime Monitoring finding types - Amazon GuardDuty

Prerequisites

If you’re performing incident response on AWS ECS clusters that sit on Fargate, not EC2, I recommend ensuring the task definitions have ECS Exec, as a preparation action. Additionally, if you run into errors when connecting to the container, see: https://repost.aws/knowledge-center/ecs-error-execute-command. There are other considerations to enabling this such as whether your containers support this and whether you can have SSM agents installed: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html. Without ECS Exec on Fargate-backed ECS containers, you will not be able to connect to the container, this can’t be fixed after the incident occurs.

You will need the correct roles/permissions in the target account to reach the resources.

Key Concepts

Launch Types - How they affect your response

Launch types define how you host and manage your containers in AWS ECS. The two most common options are:

EC2 Launch Type - ECS tasks run directly on EC2 instances that you manage. You provision, patch, and scale the EC2 fleet yourself.
- Net effect as an incident responder: You have more options to contain at the EC2 level, however, more resources to worry about.
AWS Fargate - AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.
- Net effect as an incident responder: Whilst this approach simplifies things for developers, it may obfuscate or abstract evidence as you can’t access everything.

EC2 launch type vs Fargate

EC2 Launch Type vs Fargate

Aspect	EC2-Backed ECS	Fargate-Backed ECS
Storage	Full access to EBS volumes for forensic imaging, timeline reconstruction, and artifact extraction.	No direct access to underlying storage. Ephemeral and abstracted.
Memory	Possible via Volatility or similar tools if EC2 instance is paused or imaged.	Not feasible—memory is abstracted and inaccessible.
Network	Can deploy packet capture tools (e.g., tcpdump) or mirror traffic via VPC features.	Limited—no access to underlying network stack (typically the ENI), therefore VPC traffic mirroring isn’t typically possible$^1$. Must rely on VPC Flow Logs or CloudTrail.
Host Logs	Can access , ECS agent logs, and Docker runtime metadata.	Must rely on CloudWatch or FireLens—no host-level logs.
Containment	Can freeze EC2 instance, snapshot EBS, enable termination protection.	No pause/freeze capability. Must act fast to redirect traffic or isolate via task-level controls.
Runtime Introspection	Can SSH into the EC2.	Can’t SSH, you can use ESC exec commands via SSM, though further design considerations must be made well in advance.

Ref. 1 - VPC Traffic Mirroring relies on a discrete Elastic Network Interface (ENI), your ECS must be running in ‘awsvpc’ mode to take advantage of this. If you’re running in ‘awsvpc’ mode, each task that runs on the instance receives its own ENI attached to the trunk ENI, with a primary private IP address. The awsvpc network mode also allows you to leverage Amazon VPC Traffic Mirroring for security and monitoring of network traffic when using instance types that don't have trunk ENIs attached. Note only certain instances are supported.