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

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

@@ -10,32 +10,71 @@ For more information check:
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}
 
-### Sensitive Information
+### संवेदनशील जानकारी
 
-कभी-कभी आप buckets में पढ़ने योग्य रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets.
+कभी-कभी आप buckets में पठनीय रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets।
 
 ### Pivoting
 
 विभिन्न प्लेटफ़ॉर्म S3 का उपयोग संवेदनशील assets स्टोर करने के लिए कर सकते हैं।\
-उदाहरण के लिए, **airflow** वहाँ **DAGs** **code** स्टोर कर सकता है, या **web pages** सीधे S3 से सर्व की जा सकती हैं। एक attacker जिसके पास write permissions हैं, वह bucket के code को **modify the code** करके अन्य प्लेटफ़ॉर्म पर **pivot** कर सकता है, या JS फाइलें बदलकर **takeover accounts** कर सकता है।
+उदाहरण के लिए, **airflow** वहाँ **DAGs** **code** स्टोर कर सकता है, या **web pages** सीधे S3 से serve की जा सकती हैं। write permissions वाला एक हमलावर बकेट के **code** को modify करके अन्य प्लेटफ़ॉर्म पर **pivot** कर सकता है, या JS files को modify करके accounts **takeover** कर सकता है।
 
 ### S3 Ransomware
 
-इस परिदृश्य में, **attacker अपने ही AWS account में या किसी अन्य compromised account में KMS (Key Management Service) key बनाता है**। फिर वे इस **key को दुनिया में किसी के लिए भी accessible** बना देते हैं, जिससे कोई भी AWS user, role, या account इस key का उपयोग करके objects को encrypt कर सकता है। हालाँकि, objects को decrypt नहीं किया जा सकता।
+इस परिदृश्य में, हमलावर अपनी खुद की AWS account में या किसी अन्य compromised account में **KMS (Key Management Service) key बनाता है**। फिर वह इस **key को दुनिया में किसी के लिए भी accessible** बना देता है, जिससे कोई भी AWS user, role, या account इस key का उपयोग करके objects को encrypt कर सके। हालांकि, objects decrypt नहीं किए जा सकते हैं।
 
-attacker किसी target **S3 bucket and gains write-level access** को विभिन्न तरीकों से पहचानता/प्राप्त करता है। यह खराब bucket configuration के कारण सार्वजनिक रूप से उजागर होने से हो सकता है या attacker के AWS environment तक पहुँचने से भी। attacker आमतौर पर उन buckets को निशाना बनाते हैं जिनमें personally identifiable information (PII), protected health information (PHI), logs, backups, आदि जैसी संवेदनशील जानकारी होती है।
+हमलावर एक target **S3 bucket की पहचान करता है और उस पर write-level access हासिल कर लेता है** विभिन्न तरीकों से। यह खराब bucket configuration के कारण हो सकता है जो इसे public रूप से expose करता है, या हमलावर AWS environment तक पहुँच बना लेता है। हमलावर आम तौर पर उन buckets को target करता है जिनमें PII, PHI, logs, backups जैसे संवेदनशील जानकारी होती है।
 
-यह निर्धारित करने के लिए कि क्या bucket को ransomware के लिए लक्षित किया जा सकता है, attacker इसकी configuration की जाँच करता है। इसमें यह सत्यापित करना शामिल है कि **S3 Object Versioning** सक्षम है या नहीं और क्या **multi-factor authentication delete (MFA delete) is enabled**। यदि Object Versioning सक्षम नहीं है, तो attacker आगे बढ़ सकता है। यदि Object Versioning सक्षम है लेकिन MFA delete disabled है, तो attacker **disable Object Versioning** कर सकता है। यदि दोनों Object Versioning और MFA delete enabled हैं, तो उस विशिष्ट bucket को ransomware करना अधिक कठिन हो जाता है।
+यह निर्धारित करने के लिए कि 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 करना मुश्किल हो जाता है।
 
-AWS API का उपयोग करके, attacker **replaces each object in the bucket with an encrypted copy using their KMS key**। यह प्रभावी रूप से bucket में मौजूद डेटा को encrypt कर देता है, जिससे बिना key के वह inaccessible हो जाता है।
+AWS API का उपयोग करके, हमलावर **bucket में प्रत्येक object को उनके KMS key का उपयोग करके एक encrypted copy से replace कर देता है**। यह प्रभावी रूप से bucket के डेटा को encrypt कर देता है, जिससे key के बिना वह डेटा inaccessible हो जाता है।
 
-अधिक दबाव डालने के लिए, attacker उस KMS key के deletion को शेड्यूल कर देता है जिसका उपयोग हमले में किया गया था। इससे target को अपनी डेटा recovery के लिए key delete होने से पहले 7-day फिराक मिलता है, अन्यथा डेटा स्थायी रूप से खो सकता है।
+अतिरिक्त दबाव बनाने के लिए, हमलावर उस KMS key को delete करने का schedule भी सेट कर सकता है जिसका उपयोग हमले में किया गया था। इससे target के पास अपनी data recover करने के लिए 7 दिनों की विंडो बन जाती है, उसके बाद key delete होकर डेटा स्थायी रूप से खो सकता है।
 
-अंत में, attacker एक अंतिम फ़ाइल अपलोड कर सकता है, आम तौर पर नाम "ransom-note.txt" होती है, जिसमें लक्ष्य को उनकी फ़ाइलें कैसे पुनः प्राप्त करनी हैं इसके निर्देश होते हैं। यह फ़ाइल बिना एन्क्रिप्शन के अपलोड की जाती है, संभवतः target का ध्यान आकर्षित करने और उन्हें ransomware हमले के बारे में सूचित करने के लिए।
+अंत में, हमलावर आम तौर पर एक final file upload कर सकता है, जिसका नाम अक्सर "ransom-note.txt" होता है, जिसमें target को उनकी files कैसे वापस पाएं इसकी instructions होती हैं। यह file बिना encryption के upload की जाती है, ताकि यह target का ध्यान आकर्षित करे और उन्हें ransomware हमले के बारे में बताए।
+
+#### 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 हो जाता है।
+
+- **Preconditions:** Compromised AWS credentials (or any principal with the right permissions) और objects को **rewrite** करने की क्षमता (उदा., `s3:PutObject` target keys/prefixes पर)। यह अक्सर destructive lifecycle policies सेट करने की क्षमता के साथ जुड़ा होता है (नीचे देखें), उदा., `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 बन जाए।
+
+Example (conceptual) CLI usage:
+```bash
+# Upload/overwrite an object encrypted with attacker-provided SSE-C key
+aws s3 cp ./file s3://<BUCKET>/<KEY> \
+--sse-c AES256 \
+--sse-c-key <BASE64_32_BYTES>
+
+# Download requires providing the same key again
+aws s3 cp s3://<BUCKET>/<KEY> ./file \
+--sse-c AES256 \
+--sse-c-key <BASE64_32_BYTES>
+```
+##### दबाव बढ़ाना: Lifecycle "Timer" का दुरुपयोग
+
+रिकवरी विकल्पों (जैसे old versions) को हटाने के लिए, attackers SSE-C rewrites को **lifecycle rules** के साथ जोड़ सकते हैं जो objects को expire कर देते हैं और/या short period के बाद noncurrent versions को delete कर देते हैं:
+
+- `s3:PutLifecycleConfiguration` on the bucket attackers को हर object/version के लिए explicit delete ऑपरेशन जारी किए बिना deletions शेड्यूल करने देता है।
+- यह खासकर तब प्रभावी होता है जब **versioning is enabled**, क्योंकि यह "previous good version" को हटा सकता है जो अन्यथा recovery की अनुमति देता।
+
+##### डिटेक्शन और निवारण
+
+- 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 के साथ सुरक्षित रखें।
 
 ### `s3:RestoreObject`
 
-एक attacker जिसके पास s3:RestoreObject permission है, वह Glacier या Deep Archive में archived objects को फिर से सक्रिय कर सकता है, जिससे वे अस्थायी रूप से सुलभ हो जाते हैं। यह ऐतिहासिक रूप से archived डेटा (बैकअप्स, snapshots, logs, certifications, पुराने secrets) की recovery और exfiltration को सक्षम बनाता है जो सामान्यतः पहुँच से बाहर होते हैं। यदि attacker इस permission को read permissions (e.g., s3:GetObject) के साथ मिलाता है, तो वे संवेदनशील डेटा की पूरी प्रतियाँ प्राप्त कर सकते हैं।
+एक 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) के साथ जोड़ता है, तो वे संवेदनशील डेटा की पूर्ण प्रतियाँ प्राप्त कर सकते हैं।
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -47,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`
 
-जिसके पास `s3:Delete*` permission है, वह objects, versions और पूरे buckets को हटा सकता है, backups को बाधित कर सकता है, और तुरंत व अपरिवर्तनीय डेटा हानि, साक्ष्य का नाश, तथा backup या recovery artifacts के समझौते का कारण बन सकता है।
+जिस हमलावर के पास s3:Delete* permission है, वह objects, versions और पूरे buckets को हटा सकता है, backups को बाधित कर सकता है, और तात्कालिक व अपरिवर्तनीय डेटा हानि, साक्ष्य के नाश, तथा backup या recovery artifacts का समझौता कर सकता है।
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -64,6 +103,6 @@ aws s3api delete-object \
 aws s3api delete-bucket \
 --bucket <BUCKET_NAME>
 ```
-**और अधिक जानकारी के लिए** [**मूल रिसर्च देखें**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+**अधिक जानकारी के लिए** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}