AWS - S3 Post Exploitation

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

S3

For more information check:

AWS - S3, Athena & Glacier Enum

संवेदनशील जानकारी

कभी-कभी आप buckets में पठनीय रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets।

Pivoting

विभिन्न प्लेटफ़ॉर्म S3 का उपयोग संवेदनशील assets स्टोर करने के लिए कर सकते हैं।
उदाहरण के लिए, airflow वहाँ DAGs code स्टोर कर सकता है, या web pages सीधे S3 से serve की जा सकती हैं। write permissions वाला एक हमलावर बकेट के code को modify करके अन्य प्लेटफ़ॉर्म पर 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 नहीं किए जा सकते हैं।

हमलावर एक target S3 bucket की पहचान करता है और उस पर write-level access हासिल कर लेता है विभिन्न तरीकों से। यह खराब bucket configuration के कारण हो सकता है जो इसे public रूप से expose करता है, या हमलावर AWS environment तक पहुँच बना लेता है। हमलावर आम तौर पर उन buckets को target करता है जिनमें PII, PHI, logs, backups जैसे संवेदनशील जानकारी होती है।

यह निर्धारित करने के लिए कि 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 का उपयोग करके, हमलावर bucket में प्रत्येक object को उनके KMS key का उपयोग करके एक encrypted copy से replace कर देता है। यह प्रभावी रूप से bucket के डेटा को encrypt कर देता है, जिससे key के बिना वह डेटा inaccessible हो जाता है।

अतिरिक्त दबाव बनाने के लिए, हमलावर उस KMS key को delete करने का schedule भी सेट कर सकता है जिसका उपयोग हमले में किया गया था। इससे target के पास अपनी data recover करने के लिए 7 दिनों की विंडो बन जाती है, उसके बाद key delete होकर डेटा स्थायी रूप से खो सकता है।

अंत में, हमलावर आम तौर पर एक 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:

# 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 को re‑activate कर सकता है, जिससे वे अस्थायी रूप से accessible हो जाते हैं। इससे historically archived data (backups, snapshots, logs, certifications, old secrets) की recovery और exfiltration संभव हो जाती है जो सामान्यतः पहुँच से बाहर होती। यदि attacker इस permission को read permissions (उदा., s3:GetObject) के साथ जोड़ता है, तो वे संवेदनशील डेटा की पूर्ण प्रतियाँ प्राप्त कर सकते हैं।

aws s3api restore-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--restore-request '{
"Days": <NUMBER_OF_DAYS>,
"GlacierJobParameters": { "Tier": "Standard" }
}'

s3:Delete*

जिस हमलावर के पास s3:Delete* permission है, वह objects, versions और पूरे buckets को हटा सकता है, backups को बाधित कर सकता है, और तात्कालिक व अपरिवर्तनीय डेटा हानि, साक्ष्य के नाश, तथा backup या recovery artifacts का समझौता कर सकता है।

# Delete an object from a bucket
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY>

# Delete a specific version
aws s3api delete-object \
--bucket <BUCKET_NAME> \
--key <OBJECT_KEY> \
--version-id <VERSION_ID>

# Delete a bucket
aws s3api delete-bucket \
--bucket <BUCKET_NAME>

अधिक जानकारी के लिए check the original research.

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें